20.01.2017 17:51, Patrick Schleizer пишет:
> Hi,
>
> I've learned about the kernel parameter and symlink ways to disable
> predictable network interface names. However, as a Debian derivative, it
> would be much cleaner using a drop-in to disable it.
>
> Is there some drop-in directory foo.servic
How about /etc/default/grub.d/ for the kernel parameter drop in file.
That's how I do it at least.
I don't think it's super well documented tho and I forget the suffix it
expects offhand (*.cfg?). Follow the chain of the update-grub scripts and
you should find it.
Cheers,
Brian
On Fri, Jan 20, 2
Am 20.01.2017 um 20:54 schrieb Bryan Quigley:
But what information is it carrying that is private?
none - a UUID is by defintion UNIQUE but random stuff generated once and
that's it
https://en.wikipedia.org/wiki/Universally_unique_identifier
___
On Fri, Jan 20, 2017 at 9:54 PM, Bryan Quigley
wrote:
> But what information is it carrying that is private? If it's just the
> best way to identify a machine, that's really what I'm after.
>
It is, and the fact that it's a machine identifier exactly what makes it
somewhat private – similar to
On Fri, Jan 20, 2017 at 02:54:30PM -0500, Bryan Quigley wrote:
> But what information is it carrying that is private? If it's just the
> best way to identify a machine, that's really what I'm after.
machine-id is used to seed the identification of the machine in
different contexts (by hashing the
But what information is it carrying that is private? If it's just the
best way to identify a machine, that's really what I'm after.
Here are two of my uses (all in debugging/troubleshooting purposes):
* Sosreport captures logs/other information and currently captures the
dbus machine-id (which th
On Fri, Jan 20, 2017 at 02:02:07PM -0500, Bryan Quigley wrote:
> Hi there,
>
> I see that there is a concern that we need to keep machine-id private
> (and local?). I haven't been able to determine exactly why though*.
> In most cases it's randomly generated afaict.
It's a unique identifier for
Hi there,
I see that there is a concern that we need to keep machine-id private
(and local?). I haven't been able to determine exactly why though*.
In most cases it's randomly generated afaict.
I'd consider using it to replace whoopsie-id which is generated from
the machines BIOS information now
Hi,
I've learned about the kernel parameter and symlink ways to disable
predictable network interface names. However, as a Debian derivative, it
would be much cleaner using a drop-in to disable it.
Is there some drop-in directory foo.service.d that can be used to
disable it?
Best regards,
Patric
On Fri, Jan 20, 2017 at 01:18:12PM +0100, Lars Knudsen wrote:
> > The full device should be fine if it has a WebUSB interface (even in a
> > composite scenario)
>
> Really? You want to allow someone "raw" access to a composite device
> just because of one specific interface?
>
>
On Fri, Jan 20, 2017 at 1:11 PM, Greg KH wrote:
> On Fri, Jan 20, 2017 at 12:55:20PM +0100, Lars Knudsen wrote:
> > On Fri, Jan 20, 2017 at 12:05 PM, Greg KH
> wrote:
> > > - so if we can make a rule that consistently detects USB devices
> with a
> > WebUSB
> > > interface defined,
On Fri, Jan 20, 2017 at 12:20 PM, Raghavendra. H. R
wrote:
> Hi All,
>
> I have a scenario in which I have 2 processes and both acts as Server &
> Client.
> Process A starts it server & tries to connect as client with Process B.
> Process B starts it server & tries to connect as client with Proce
On Fri, Jan 20, 2017 at 12:55:20PM +0100, Lars Knudsen wrote:
> On Fri, Jan 20, 2017 at 12:05 PM, Greg KH wrote:
> > - so if we can make a rule that consistently detects USB devices with a
> WebUSB
> > interface defined, we should get this in as a standard rule.
>
> Sure, feel fr
On Fri, Jan 20, 2017 at 12:05 PM, Greg KH
wrote:
> On Fri, Jan 20, 2017 at 11:43:24AM +0100, Lars Knudsen wrote:
> >
> >
> > On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <
> [email protected]
> > > wrote:
> >
> > On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> >
On Fri, Jan 20, 2017 at 11:43:24AM +0100, Lars Knudsen wrote:
>
>
> On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie
> > wrote:
>
> On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> > 2. make sure that webusb devices will be somehow accessible to be used
> by
> a
> >
On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <
[email protected]> wrote:
> On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> > 2. make sure that webusb devices will be somehow accessible to be used
> by a
> > browser running with user permissions (current temp solution l
Am 20.01.2017 um 11:20 schrieb Raghavendra. H. R:
I have a scenario in which I have 2 processes and both acts as Server &
Client.
Process A starts it server & tries to connect as client with Process B.
Process B starts it server & tries to connect as client with Process A.
We want handle this
Hi All,
I have a scenario in which I have 2 processes and both acts as Server &
Client.
Process A starts it server & tries to connect as client with Process B.
Process B starts it server & tries to connect as client with Process A.
We want handle this kind of scenario with the help of systemd sd_
18 matches
Mail list logo
