For me the short answer is that I very much dislike this and would prefer not
to have it.
There was an open issue in my git repo about performance issues relating to
'machine id' and pulse when dbus is not available. The person reporting it
provided a hackish work around and I later asked
* On 2019 18 Mar 06:35 -0500, Olaf Meeuwissen wrote:
> I wrote "the IP address is in /etc/hosts", but I think that should have
> been "the IP address what your hostname resolves to" :-/
>
> In many common scenarios that is likely to be the same as what is in
> your /etc/hosts file, but really
Hi Nate,
Apologies for the belated follow-up.
Nate Bargmann writes:
> * On 2019 09 Mar 18:09 -0600, Olaf Meeuwissen wrote:
>> All the info I have seen on this topic in the thread is consistent with
>> hostid returning the "mangled" IP address belonging to the machine's
>> current hostname.
On 08.03.19 14:23, KatolaZ wrote:
> this is currently managed by eudev in devuan and, IIRC, it is simply
> regenerated as a random ID at each boot. I guess it's still there
> because it is used by several things, including
> session-management-related stuff. We had a discussion on IRC with Mark
I used to and still do hot mount all my drives using autofs.
Am 10. März 2019 20:24:20 MEZ schrieb Steve Litt :
>On Sat, 09 Mar 2019 10:25:39 -0600
>goli...@dyne.org wrote:
>
>
>> I certainly did not write that! (I'm not even sure what inotify
>> is!) LOL!
>>
>> golinux
>
>inotify is a Linux
On Sat, 09 Mar 2019 10:25:39 -0600
goli...@dyne.org wrote:
> I certainly did not write that! (I'm not even sure what inotify
> is!) LOL!
>
> golinux
inotify is a Linux specific kernel API that detects changes in the
filesystem. It can be set to discover changes in a specific directory,
or
On Sat, 9 Mar 2019 10:28:50 +0100
Didier Kryn wrote:
> Le 09/03/2019 à 10:03, Didier Kryn a écrit :
> > Le 09/03/2019 à 09:34, goli...@dyne.org a écrit :
> >> I'd recommend adding an inotify rule to record which processes
> >> look at these files, and publishing this - here.
> >
> >
On Sun, 10 Mar 2019 14:58:52 +0100, Martin wrote in message
<1790105.p7Nha06Ba6@merkaba>:
> Jaromil - 10.03.19, 14:03:
> > > > but first things first: do we want /etc/machine-id? and how?
> > >
> > > In my view it falls in the completely unnessesary or the
> > > potentially dangerous group.
>
Jaromil - 10.03.19, 14:03:
> > > but first things first: do we want /etc/machine-id? and how?
> >
> > In my view it falls in the completely unnessesary or the potentially
> > dangerous group.
> >
> > I don't want it.
>
> while I'm still catching up with reading all the thread, I think you
>
dear Karl,
On Fri, 08 Mar 2019, k...@aspodata.se wrote:
> Jaromil:
> > any thoughts about this new systemd-made thing that freedesktop
> > immediately "standardized" (whatever is their procedure for that,
> > likely smoking cigars among old-boys or so)
> >
* On 2019 09 Mar 18:09 -0600, Olaf Meeuwissen wrote:
> All the info I have seen on this topic in the thread is consistent with
> hostid returning the "mangled" IP address belonging to the machine's
> current hostname. This is normally set from /etc/hostname. That file
> is created during
* On 2019 09 Mar 17:01 -0600, Antoine via Dng wrote:
> It looks to me as if this is indeed the computer's IP address... just the
> loopback one, slightly mangled:
>
> - 127.0.0.1 => 0.127.1.0 i.e. 007f0100
> or
> - 127.0.1.1 => 0.127.1.1 i.e. 007f0101
>
> I tried changing the IPaddress on my
* On 2019 09 Mar 07:05 -0600, al3xu5 / dotcommon wrote:
> using the `hostid` command, I have (Devuan ASCII):
>
> $ hostid
> 007f0101
>
> which is the same value!!!
>
> I wonder... is it a "fixed" id for all Devuan installation as it seems to be?
I get the same value on Debian Jessie i686,
On Sun, Mar 10, 2019 at 09:06:50AM +0900, Olaf Meeuwissen wrote:
[cut]
> > I get 007f0100 on one jessie, 007f0101 on another jessie and 007f0101
> > on ascii. (Three different computers)
> >
> > The ascii install is on a laptop that has several installations. When I
> > reboot it into jessie, I
Hendrik Boom writes:
> On Sat, Mar 09, 2019 at 02:34:28AM -0600, goli...@dyne.org wrote:
>>
>> Oh, my . . . how fast and how hard Debian has fallen . . I am all for
>> shining light into dark, dank places. What a terrific idea to track
>> down all the offending packages that are "leaking"
fsmithred via Dng writes:
> On Sat, 9 Mar 2019 16:27:10 +0100
> Arnt Karlsen wrote:
>
>> On Sat, 9 Mar 2019 14:04:13 +0100, al3xu5 wrote in message
>> <20190309130422.386f8f60...@vm6.ganeti.dyne.org>:
>> >
>> > I wonder... is it a "fixed" id for all Devuan installation as it
>> > seems to be?
Antoine via Dng wrote on 10/3/19 10:00 am:
> I tried changing the IPaddress on my loopback interface, but the
> returned hostid didn't change.
Try editing /etc/hosts and move your hostname entry to something else
Ralph.
___
Dng mailing list
On Sat, Mar 09, 2019 at 10:38:57AM -0600, goli...@dyne.org wrote:
On 2019-03-09 07:21, Alessandro Selli wrote:
> On 09/03/19 at 14:04, al3xu5 / dotcommon wrote:
> >
> > > my id is 0x007f0101
> > >
> > > [...]
> > >
> > > my id is 0x007f0101
> > >
> > > [...]
> > >
> > > my id is 0x007f0101
Le 09/03/2019 à 21:48, Arnt Karlsen a écrit :
On Sat, 9 Mar 2019 18:12:55 +0100, Didier wrote in message
<42982bbd-6ccc-6ed4-2bcc-4d969319c...@in2p3.fr>:
I find it comic that dbus, which is a middleware restricted to a
single host, builds a unique id to identify this host. We know that
On Sat, Mar 09, 2019 at 11:01:43AM -0500, Hendrik Boom wrote:
> On Sat, Mar 09, 2019 at 02:34:28AM -0600, goli...@dyne.org wrote:
> > Oh, my . . . how fast and how hard Debian has fallen . . I am all for
> > shining light into dark, dank places. What a terrific idea to track
> > down all the
On Sat, 9 Mar 2019 18:12:55 +0100, Didier wrote in message
<42982bbd-6ccc-6ed4-2bcc-4d969319c...@in2p3.fr>:
> I find it comic that dbus, which is a middleware restricted to a
> single host, builds a unique id to identify this host. We know that
> the systemd team likes to catch up
I find it comic that dbus, which is a middleware restricted to a
single host, builds a unique id to identify this host. We know that the
systemd team likes to catch up everything to control it from their blob,
even if it looks like pure crap. This makes me think the intention is
probably
Hello
> > B) I am more concerned about the other part, where code is
> > known to phone home, but the developers or packagers
> > have decided that this is fine. The examples range from popcon
> > to systemd's resolver (which I am told falls back on to google
> > at 8.8.8.8) to chromium or
Le 09/03/2019 à 17:25, goli...@dyne.org a écrit :
On 2019-03-09 03:03, Didier Kryn wrote:
Le 09/03/2019 à 09:34, goli...@dyne.org a écrit :
I'd recommend adding an inotify rule to record which processes
look at these files, and publishing this - here.
Unfortunately inotify doesn't tell
On 2019-03-09 07:21, Alessandro Selli wrote:
On 09/03/19 at 14:04, al3xu5 / dotcommon wrote:
my id is 0x007f0101
[...]
my id is 0x007f0101
[...]
my id is 0x007f0101
using the `hostid` command, I have (Devuan ASCII):
$ hostid
007f0101
which is the same value!!!
I wonder... is it a
On Sat, 9 Mar 2019 16:27:10 +0100
Arnt Karlsen wrote:
> On Sat, 9 Mar 2019 14:04:13 +0100, al3xu5 wrote in message
> <20190309130422.386f8f60...@vm6.ganeti.dyne.org>:
> >
> > I wonder... is it a "fixed" id for all Devuan installation as it
> > seems to be?
>
> ..yes and no and no etc, I have:
On 2019-03-09 03:03, Didier Kryn wrote:
Le 09/03/2019 à 09:34, goli...@dyne.org a écrit :
I'd recommend adding an inotify rule to record which processes
look at these files, and publishing this - here.
Unfortunately inotify doesn't tell which process accessed the file
)~:
On Sat, Mar 09, 2019 at 02:34:28AM -0600, goli...@dyne.org wrote:
>
> Oh, my . . . how fast and how hard Debian has fallen . . I am all for
> shining light into dark, dank places. What a terrific idea to track
> down all the offending packages that are "leaking" information and then
> publish
On Sat, 9 Mar 2019 14:04:13 +0100, al3xu5 wrote in message
<20190309130422.386f8f60...@vm6.ganeti.dyne.org>:
> Il giorno sabato 09/03/2019 13:25:29 +0100
> Alessandro Selli ha scritto:
>
> > [cut]
>
> > > Maybe your system is different to mine, but try compiling the
> > > below and find
On Sat, Mar 09, 2019 at 02:28:10PM +0100, Antony Stone wrote:
[cut]
> > >
> > > I wonder... is it a "fixed" id for all Devuan installation as it seems to
> > > be?
> > >
> > > And if it is so,is it correct that it is?
> >
> > How intriguing!
>
> I get the same value on a Debian Wheezy
On Saturday 09 March 2019 at 14:21:30, Alessandro Selli wrote:
> On 09/03/19 at 14:04, al3xu5 / dotcommon wrote:
> >> my id is 0x007f0101
> >>
> >> [...]
> >>
> >> my id is 0x007f0101
> >>
> >> [...]
> >>
> >> my id is 0x007f0101
> >
> > using the `hostid` command, I have (Devuan ASCII):
> >
On 09/03/19 at 14:04, al3xu5 / dotcommon wrote:
>
>> my id is 0x007f0101
>>
>> [...]
>>
>> my id is 0x007f0101
>>
>> [...]
>>
>> my id is 0x007f0101
>>
> using the `hostid` command, I have (Devuan ASCII):
>
> $ hostid
> 007f0101
>
> which is the same value!!!
>
> I wonder... is it a "fixed" id for
Il giorno sabato 09/03/2019 13:25:29 +0100
Alessandro Selli ha scritto:
> [cut]
> > Maybe your system is different to mine, but try compiling the below
> > and find out for yourself:
> >
> > #include
> > #include
> >
> > int main()
> > {
> > int id;
> >
> > id = gethostid();
> >
> >
Il giorno sabato 09/03/2019 10:54:08 +0100
KatolaZ ha scritto:
> On Sat, Mar 09, 2019 at 09:05:20AM +0100, marc wrote:
>
> [cut]
>
> > [cut]
>
> [cut]
>
> In any case, there are dozens of ways to identify a host and a user
> with very good accuracy, even across reboots and even when it
On Sat, Mar 09, 2019 at 01:11:31PM +0100, marc wrote:
[cut]
>
> B) I am more concerned about the other part, where code is
> known to phone home, but the developers or packagers
> have decided that this is fine. The examples range from popcon
> to systemd's resolver (which I am told falls back
On 09/03/19 at 12:46, marc wrote:
>>> So you are correct that gethostid has been around for a while,
>>> but this call returns a 32bit number, typically the IP.
>> ?? No, it returns a value that's unique to the local machine even if it
>> was not configured on any network.?? Plus, the IP can
> Dear marc,
>
> unwanted "calls-home" are normally found and disclosed if the software
> is free, so I really don't think this is a problem. Asking the
> development team of a distribution with 50k+ packages to guarantee
> that nothing ever uses user information for unwanted means is just
>
> > So you are correct that gethostid has been around for a while,
> > but this call returns a 32bit number, typically the IP.
>
> ?? No, it returns a value that's unique to the local machine even if it
> was not configured on any network.?? Plus, the IP can change, but the
> hostid is supposed
On Sat, 9 Mar 2019 09:05:20 +0100, marc wrote in message
<20190309080520.GA32402@localhost.localdomain>:
> So instead of adding crontab rules to obfuscate the ids,
...er, say "to flood them with useless IDs," if you want
my agreement.
> I'd recommend adding an inotify rule to record which
On Sat, 9 Mar 2019 08:21:18 +0100, Alessandro wrote in message
:
> On 09/03/19 at 00:28, Arnt Karlsen wrote:
>
> > ..both valid improvements, me, I might go: " * * * * * root \
> > fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \
> > >/dev/null 2>&1 " to keep this lightweight in
Il 09/03/19 11:16, marc ha scritto:
>> Mark, I think you are probably shooting the wrong bird here. Host ids
>> have been around for the best part of the last 40 years in the unix
>> world. And I am not talking about proprietary unix. The syscalls
>> gethostid/sethostid were introduced in 4.2BSD
On Sat, Mar 09, 2019 at 11:16:51AM +0100, marc wrote:
[cut]
>
> I also agree with your sentiment that free and open source
> software is necessary to track down information leakage. But it
> seems it may be necessary but not sufficient - what one also
> needs is a distribution which makes it
> Mark, I think you are probably shooting the wrong bird here. Host ids
> have been around for the best part of the last 40 years in the unix
> world. And I am not talking about proprietary unix. The syscalls
> gethostid/sethostid were introduced in 4.2BSD (ca. 1983), at Berkeley,
> and are
Il 09/03/19 09:53, Didier Kryn ha scritto:
> Le 09/03/2019 à 00:28, Arnt Karlsen a écrit :
>> I might go: " * * * * * root \
>> fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \
>> >/dev/null 2>&1 " to keep this lightweight in my end and not
>> in the other end. :o)
>
> Arnt, Could
On Sat, Mar 09, 2019 at 09:05:20AM +0100, marc wrote:
[cut]
>
> But what really blows me away is that these ids exist on
> Debian to begin with. I had been under the assumption that
> free systems are built according to the needs and desires
> of their users, and few users go "what I really
> Le 09/03/2019 ?? 10:03, Didier Kryn a ??crit??:
> >Le 09/03/2019 ?? 09:34, goli...@dyne.org a ??crit??:
> >>I'd recommend adding an inotify rule to record which processes
> >>look at these files, and publishing this - here.
> >
> >Unfortunately inotify doesn't tell which process accessed the
Anno domini 2019 Sat, 9 Mar 10:03:59 +0100
Didier Kryn scripsit:
> Le 09/03/2019 à 09:34, goli...@dyne.org a écrit :
> > I'd recommend adding an inotify rule to record which processes
> > look at these files, and publishing this - here.
>
> Unfortunately inotify doesn't tell which process
Le 09/03/2019 à 10:03, Didier Kryn a écrit :
Le 09/03/2019 à 09:34, goli...@dyne.org a écrit :
I'd recommend adding an inotify rule to record which processes
look at these files, and publishing this - here.
Unfortunately inotify doesn't tell which process accessed the file
)~:
But
Le 09/03/2019 à 09:34, goli...@dyne.org a écrit :
I'd recommend adding an inotify rule to record which processes
look at these files, and publishing this - here.
Unfortunately inotify doesn't tell which process accessed the file )~:
___
Dng
Le 09/03/2019 à 00:28, Arnt Karlsen a écrit :
I might go: " * * * * * root \
fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \
>/dev/null 2>&1 " to keep this lightweight in my end and not
in the other end. :o)
Arnt, Could you be less cryptic please?
I found fortune in
On 2019-03-09 02:05, marc wrote:
Quoting Arnt Karlsen (a...@iaksess.no):
> ..my /etc/cron.d/machine-id:
> PATH=/bin:/usr/bin:/sbin:/usr/sbin
>
> # ..a new /etc/machine-id every minute... ;o)
> * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee
> >/dev/null 2>&1
_Very_ nice
> Quoting Arnt Karlsen (a...@iaksess.no):
>
> > ..my /etc/cron.d/machine-id:
> > PATH=/bin:/usr/bin:/sbin:/usr/sbin
> >
> > # ..a new /etc/machine-id every minute... ;o)
> > * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee
> > >/dev/null 2>&1
>
> _Very_ nice solution. I
Hi,
On 8/3/19 18:31, . fsmithred via Dng wrote:
There's no /etc/machine-id in my beowulf that was an upgrade from
refracta ascii or in the beowulf live iso that I just made with
live-sdk.
Refractasnapshot excludes /var/lib/dbus/machine-id and blanks
/etc/machine-id if it's present.
On 09/03/19 at 00:28, Arnt Karlsen wrote:
> On Fri, 8 Mar 2019 22:56:36 +0100, Alessandro wrote in message
> <93850f1a-3feb-adc9-1cd0-8ca8736fc...@linux.com>:
>
>> On 08/03/19 at 18:38, Arnt Karlsen wrote:
>>> ..my /etc/cron.d/machine-id:
>>> PATH=/bin:/usr/bin:/sbin:/usr/sbin
>>>
>>> # ..a new
On Fri, 8 Mar 2019 22:56:36 +0100, Alessandro wrote in message
<93850f1a-3feb-adc9-1cd0-8ca8736fc...@linux.com>:
> On 08/03/19 at 18:38, Arnt Karlsen wrote:
> >
> > ..my /etc/cron.d/machine-id:
> > PATH=/bin:/usr/bin:/sbin:/usr/sbin
> >
> > # ..a new /etc/machine-id every minute... ;o)
> > * * *
On 08/03/19 at 18:38, Arnt Karlsen wrote:
>
> ..my /etc/cron.d/machine-id:
> PATH=/bin:/usr/bin:/sbin:/usr/sbin
>
> # ..a new /etc/machine-id every minute... ;o)
> * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee
> >/dev/null 2>&1
What is tee doing there?
It duplicates
KatolaZ wrote on 9/3/19 1:00 am:
> On Fri, Mar 08, 2019 at 01:49:20PM +, Mark Hindley wrote:
>> On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote:
>>> Jaromil,
>>>
>>> this is currently managed by eudev in devuan and, IIRC, it is simply
>>> regenerated as a random ID at each boot.
On Fri, 8 Mar 2019 19:18:10 +0100, KatolaZ wrote in message
<20190308181810.7wnfugnqmqtie...@katolaz.homeunix.net>:
> anyway:
>
> - /etc/hostid is defined in POSIX 2001 and POSIX 2008 (man gethostid)
>
> - /proc/sys/kernel/random/boot_id is randomly generated by the kernel
> at each boot
Quoting Arnt Karlsen (a...@iaksess.no):
> ..my /etc/cron.d/machine-id:
> PATH=/bin:/usr/bin:/sbin:/usr/sbin
>
> # ..a new /etc/machine-id every minute... ;o)
> * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee
> >/dev/null 2>&1
_Very_ nice solution. I think I'll steal it
Am Freitag, 8. März 2019 schrieb KatolaZ:
> On the other hand, it looks like /etc/machine-id mighr come from
> Debian installations "converted" to Devuan, but we should check
> whether any of the installer components might have put it there. We
> should collect as many reports as possible of
On 2019-03-08 11:50, KatolaZ wrote:
On Fri, Mar 08, 2019 at 12:31:55PM -0500, . fsmithred via Dng wrote:
On 3/8/19, KatolaZ wrote:
>
> Then we could probably just ignore it, right? It turns out I was
> making confusion between /etc/machine-id and
> /car/lib/dbus/machine-id. There is no
Rowland:
> On Fri, 8 Mar 2019 11:44:49 -0600
> "Jamey Fletcher" wrote:
...
> > I have it here on my Gentoo install - and /var/lib/dbus/machine-id is
> > a symlink to it. It's basically the same length as a MD5SUM - why
> > not just standardize on the MD5SUM of an empty 0-byte file (
> >
On Fri, Mar 08, 2019 at 06:38:32PM +0100, Arnt Karlsen wrote:
[cut]
>
> > > I don't seem to have it and everything works without it.
> >
> > It's on my beowulf installations, and I didn't even know that it was
> > there :-/
>
> ..quick starting point:
> ll /proc/sys/kernel/random/boot_id
Rowland wrote:
> On Fri, 8 Mar 2019 11:44:49 -0600
> "Jamey Fletcher" wrote:
>> I have it here on my Gentoo install - and /var/lib/dbus/machine-id is
>> a symlink to it. It's basically the same length as a MD5SUM - why
>> not just standardize on the MD5SUM of an empty 0-byte file (
>>
On Fri, 8 Mar 2019 11:44:49 -0600
"Jamey Fletcher" wrote:
> > Anno domini 2019 Fri, 8 Mar 10:45:04 -0600
>
> > Nate Bargmann scripsit:
>
> >> * On 2019 08 Mar 08:00 -0600, KatolaZ wrote:
>
> >>> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> >>> time. But we need to
On Fri, Mar 08, 2019 at 12:31:55PM -0500, . fsmithred via Dng wrote:
> On 3/8/19, KatolaZ wrote:
> >
> > Then we could probably just ignore it, right? It turns out I was
> > making confusion between /etc/machine-id and
> > /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my
> >
On Fri, Mar 08, 2019 at 11:44:49AM -0600, Jamey Fletcher wrote:
> >> Not on this Debian Buster machine. Both /var/lib/dbus/machine-id and
> >> /etc/machine-id have a date/time consistent with the initial system
> >> installation back in October. The machine has been rebooted a number of
> >>
> Anno domini 2019 Fri, 8 Mar 10:45:04 -0600
> Nate Bargmann scripsit:
>> * On 2019 08 Mar 08:00 -0600, KatolaZ wrote:
>>> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
>>> time. But we need to double-check.
>> Not on this Debian Buster machine. Both
On Fri, 8 Mar 2019 15:46:26 +0100, Dr. wrote in message
<201903081546.27040.dr.kl...@gmx.at>:
> Anno domini 2019 Fri, 8 Mar 13:15:48 +
> Rowland Penny via Dng scripsit:
> > On Fri, 8 Mar 2019 13:47:40 +0100
> > Jaromil wrote:
> >
> > >
> > > re all,
> > >
> > > any thoughts about this
On 3/8/19, KatolaZ wrote:
>
> Then we could probably just ignore it, right? It turns out I was
> making confusion between /etc/machine-id and
> /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my
> machines, either on ascii or on beowulf, and I had forgotten you had
> pushed the
Anno domini 2019 Fri, 8 Mar 10:45:04 -0600
Nate Bargmann scripsit:
> * On 2019 08 Mar 08:00 -0600, KatolaZ wrote:
> > and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> > time. But we need to double-check.
>
> Not on this Debian Buster machine. Both /var/lib/dbus/machine-id and
* On 2019 08 Mar 08:00 -0600, KatolaZ wrote:
> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> time. But we need to double-check.
Not on this Debian Buster machine. Both /var/lib/dbus/machine-id and
/etc/machine-id have a date/time consistent with the initial system
On Fri, Mar 08, 2019 at 02:08:39PM +, Mark Hindley wrote:
> On Fri, Mar 08, 2019 at 03:00:31PM +0100, KatolaZ wrote:
> > > Yes, elogind uses it. But I got upstream to take a patch which uses
> > > /var/lib/dbus/machine-id as an alternative to /etc/machine-id.
> > >
> >
> > and, IIRC, also
Anno domini 2019 Fri, 8 Mar 13:15:48 +
Rowland Penny via Dng scripsit:
> On Fri, 8 Mar 2019 13:47:40 +0100
> Jaromil wrote:
>
> >
> > re all,
> >
> > any thoughts about this new systemd-made thing that freedesktop
> > immediately "standardized" (whatever is their procedure for that,
> >
On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote:
> Jaromil,
>
> this is currently managed by eudev in devuan and, IIRC, it is simply
> regenerated as a random ID at each boot. I guess it's still there
> because it is used by several things, including
> session-management-related stuff. We
On Fri, Mar 08, 2019 at 03:00:31PM +0100, KatolaZ wrote:
> > Yes, elogind uses it. But I got upstream to take a patch which uses
> > /var/lib/dbus/machine-id as an alternative to /etc/machine-id.
> >
>
> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> time. But we need to
On 08-03-19 14:23, KatolaZ wrote:
> On Fri, Mar 08, 2019 at 01:47:40PM +0100, Jaromil wrote:
>> re all,
>>
>> any thoughts about this new systemd-made thing that freedesktop
>> immediately "standardized" (whatever is their procedure for that,
>> likely smoking cigars among old-boys or so)
>>
On Fri, Mar 08, 2019 at 01:49:20PM +, Mark Hindley wrote:
> On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote:
> > Jaromil,
> >
> > this is currently managed by eudev in devuan and, IIRC, it is simply
> > regenerated as a random ID at each boot. I guess it's still there
> > because it
Jaromil:
> any thoughts about this new systemd-made thing that freedesktop
> immediately "standardized" (whatever is their procedure for that,
> likely smoking cigars among old-boys or so)
> https://www.freedesktop.org/software/systemd/man/machine-id.html
...
. It doesn't say "why".
Why should
On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote:
> > but first things first: do we want /etc/machine-id? and how?
> this is currently managed by eudev in devuan and, IIRC, it is simply
> regenerated as a random ID at each boot.
> we concluded that keeping it around but re-generating it
On Fri, Mar 08, 2019 at 01:47:40PM +0100, Jaromil wrote:
>
> re all,
>
> any thoughts about this new systemd-made thing that freedesktop
> immediately "standardized" (whatever is their procedure for that,
> likely smoking cigars among old-boys or so)
>
On Fri, 8 Mar 2019 13:47:40 +0100
Jaromil wrote:
>
> re all,
>
> any thoughts about this new systemd-made thing that freedesktop
> immediately "standardized" (whatever is their procedure for that,
> likely smoking cigars among old-boys or so)
>
re all,
any thoughts about this new systemd-made thing that freedesktop
immediately "standardized" (whatever is their procedure for that,
likely smoking cigars among old-boys or so)
https://www.freedesktop.org/software/systemd/man/machine-id.html
its easy to replace by a script of course that's
83 matches
Mail list logo
