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 the
* 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 de
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. This
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 spe
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 even
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.
> >
> > Unfor
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
> make
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)
> > https://www.freedesktop.org/software/sys
* 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 installa
* 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 loop
* 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, Debia
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 g
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" infor
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
Dng@lists.
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
th
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 offe
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 everythin
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 no
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 firefo
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 wh
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 "fix
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 an
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 out
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 machi
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();
> >
> > pri
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 travels
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 o
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 change
> 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
> plain
> > 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 to
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 pro
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 &&date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \
> > >/dev/null 2>&1 " to keep this lightweight
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 cle
> 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 suppose
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 &&date |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, C
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 need
> 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
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 ac
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 f
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 mail
Le 09/03/2019 à 00:28, Arnt Karlsen a écrit :
I might go: " * * * * * root \
fortune &&date |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 p
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 sol
> 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 thin
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.
Refractains
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 /e
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 it
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.
Appa
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 (see
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 when
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 things
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 /etc/mac
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 (
> > d41d8cd98
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 /et
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 (
>> d41d8cd98
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 double
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
> > mach
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
> >> time
> 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-i
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 pat
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
installatio
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 /v
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,
> > li
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 doubl
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)
>> https:
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 is
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 I
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 at
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)
> https://www.freedesktop.org/software/systemd
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)
> https://www.freedesktop.org/software/systemd/man/m
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
