Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-18 Thread Simon McVittie
On Sun, 18 Aug 2019 at 13:57:58 +0200, Marc Haber wrote:
> On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie 
> >bubblewrap and other container-runners often use this when setting
> >up containers - for example if you have a Flatpak app installed, try
> >something like
> >
> >flatpak run --command=mount org.gnome.Recipes
> >
> >and you'll see that the container's /etc is a mixture of read-only
> >bind-mounts from the host system and read-only bind-mounts from the
> >runtime, some of which are individual files.
> 
> That must be a horrible clutter in mtab though.

There are a lot of lines in /proc/$pid/mounts for $pid inside
the container, yes. However, bubblewrap and other unprivileged
container-runners do not (cannot!) alter the mount table outside the
container (they operate in a private mount namespace owned by a private
user namespace), so /proc/$pid/mounts for $pid outside the container
remains uncluttered.

/etc/mtab is recommended to be a symlink to /proc/self/mounts, so
it reflects the mount table that is active for the process reading
it. In older installations where it was still a regular file, it was
updated by mount(8), so in practice it will reflect the mount table
that is active for the "init namespace" (the namespaces to which pid 1
belongs). bubblewrap uses mount(2) directly, not mount(8), so it will
not alter /etc/mtab if that is a regular file.

In any case, I think avoiding "clutter" in the mount table is quite a
long way down the list of the most important properties of a system.
I would prefer Flatpak to bind-mount in the correct mixture of the
runtime's /etc and the host system's /etc to make the app work correctly,
however much clutter that might result in.

If this clutter offends you, one good way to reduce it is to encourage
packages to work correctly with fewer "boilerplate" files in /etc
(the same category of changes that results in non-sysadmin-modified
D-Bus policy fragments migrating from /etc/dbus-1/system.d to
/usr/share/dbus-1/system.d, for example).

> We should also have a document containing what we want to have in the
> future, such as a comprehensive roadmap.

Sorry, I do not have enough Debian time available to write down a
comprehensive road map for the teams and packages I'm involved with,
never mind the whole project. Any time I spend on writing a road map
advocating good ideas is time that I am not spending on implementing
those good ideas.

For goals confined to a group of closely cooperating packages and
maintainers, the way to achieve changes is to just make them.

For goals with a wider scope, I think the closest tool we have is release
goals. If you want to propose release goals around new technologies in
Debian, please do!

Debian is mostly a do-ocracy - the people who do the work decide what
the work will be - so I don't think anyone really has the authority to
write down a road map for the project as a whole and expect developers to
follow it. The DPL, release team and technical committee are probably the
closest to the positions that could meaningfully define a road map, but
even those cannot assign or require developers to work on its contents.

smcv



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-18 Thread Marc Haber
On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie 
wrote:
>On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote:
>> On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie 
>> wrote:
>> >(systemd cannot create a mount point that doesn't exist yet on a read-only
>> >file system, which is why a zero-byte file is preferred.
>> 
>> but you can bind-mount over a file? I wasn't aware of that.
>
>Yes, you can bind-mount a directory over another directory, or a
>non-directory non-symlink over another non-directory non-symlink.

I wasn't aware of that. How neat.

>bubblewrap and other container-runners often use this when setting
>up containers - for example if you have a Flatpak app installed, try
>something like
>
>flatpak run --command=mount org.gnome.Recipes
>
>and you'll see that the container's /etc is a mixture of read-only
>bind-mounts from the host system and read-only bind-mounts from the
>runtime, some of which are individual files.

That must be a horrible clutter in mtab though.

>> >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in
>> >> >general (systemd or not)?
>> 
>> So /etc/machine-id should be in Policy?
>
>Probably yes, if that proposal has consensus, although a prerequisite
>for it being in Policy would be to have an implementation of making it
>exist even on systems with neither systemd nor dbus installed (Policy
>is meant to document what's true, not what we hope will become true).

We should also have a document containing what we want to have in the
future, such as a comprehensive roadmap. The absence of leadership in
this regard is probably one of the reasons why we have lost so much
momentum in adopting new technology.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834



Re: Generating new IDs for cloning

2019-08-16 Thread Dominik George
>Longer answer: it’s complicated, but I’m sure there’s
>a set of bind and non-bind mounts that will work for
>systemd as well.
>
>Back to topic now. Or I’m going pet the cat.

Well, it *is* on topic. I have been using the same strategy for sysvinit and 
systemd systems for many years with great success, and I would like to know 
what I did wrong.

-nik



Re: Generating new IDs for cloning

2019-08-15 Thread Thorsten Glaser
Dominik George dixit:

>>than you think, either bind-mount tons of filesystem from the host,
>>and this is only safe-ish if both run sysvinit

>Why should that not work on systemd?

I wrote safe-ish and deliberately didn’t focus on this
as it’s not relevant for the point I was trying to make.

Longer answer: it’s complicated, but I’m sure there’s
a set of bind and non-bind mounts that will work for
systemd as well.

Back to topic now. Or I’m going pet the cat.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy



Re: Generating new IDs for cloning

2019-08-15 Thread Dominik George
>than you think, either bind-mount tons of filesystem from the host,
>and this is only safe-ish if both run sysvinit

Like most of the time, your allegation is lacking any facts and sources.

Why should that not work on systemd?

-nik



Re: Generating new IDs for cloning

2019-08-15 Thread Thorsten Glaser
>At a glance, there are also unique LVM IDs in /boot/grub/grub.cfg,
>though whether those would need to be changed when cloning I don't know.

Normally, you mount the root filesystem, chroot into it (more complex
than you think, either bind-mount tons of filesystem from the host,
and this is only safe-ish if both run sysvinit, or use grml-chroot,
which does that for you and which I don’t know has been adapted for
the systemd case), then run update-grub there (or dpkg-reconfigure
-plow grub-pc which also takes care of reinstalling the stage1 loader).

Also, update-initramfs -u (or -uk all if you have old *buntu).

Now this rewrites a couple of configuration files…

… when your LVM is also encrypted, and you use the nice grml-crypt
tool to mount the storage, it WILL have a different name than during
normal system operation, and this name will be embedded into the new
configuration… making the next boot fail for different reasons.

Life is hard, don’t clone systems, don’t distribute system images.

(And… do not forget to consider lack of entropy.)

Meh,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-15 Thread Simon McVittie
On Thu, 15 Aug 2019 at 09:54:44 +0100, Ian Jackson wrote:
> Do we have a list of all the things this is (or might be) used for ?

As I said, I don't think a comprehensive list is feasible without
resorting to something like codesearch, because it's of similar scope to
a list of reasons to use the hostname (as in gethostname(2)), and indeed
some current uses of the hostname would probably be better to use the
machine ID (if that's possible to do without breaking compatibility,
which in some cases it won't be).

I believe the original reasoning for the D-Bus machine ID (from which
systemd took the idea) went something like this:

- I need to do $something per-machine
- but what if the user decides they don't like their current hostname
  (which after all is user-facing) and changes it to one that is more
  aesthetically appealing? then I won't be able to find the state that I
  previously stored in the home directory, X11 display or whatever is the
  shared resource
- conversely, what if the hostname is not unique among the machines sharing
  the X11 display/home directory/other shared resource, because they
  all think they are called "debian" or "localhost" or similar? then
  they will overwrite each other's state

so "like the hostname, but opaque" is quite a good mental model for it.

The second point (hostname sometimes changing) was exacerbated by the
tendency for some distros to pass a hostname received from DHCP to
sethostname(), although I think (I hope) everyone has now decided that
was a bad idea and stopped doing so.

The dbus commit that switched from hostnames to machine IDs in the X11
autolaunch protocol appears to have been in 2006, which was before
my first commit to dbus - I'm making an informed guess about former
maintainers' motivations here, not stating why I made a decision.
I cannot, now, change how dbus uses machine IDs without breaking backwards
compatibility.

Another precursor of the machine ID is gethostid(), but that's only
32 bits long, which is clearly not enough to be "unique among all UNIX
systems in existence" as its man page claims.

> I wonder if we should in Debian have a "sticky door" policy on the use
> of machine-id, like we do for virtual packages: "please come to -devel
> for a peer review".

I can see the reasoning for suggesting this, but we don't ask for peer
review for uses of other identifying properties like the hostname, MAC
address, chassis serial number, etc., and I don't think it's realistic
to expect the authors of upstream software to come to Debian seeking
permission to use an OS interface. (In some cases the machine ID forms
part of an upstream API or an interface between stored data and the
software, from which Debian maintainers cannot diverge without breaking
compatibility, so the upstream design is relevant here.)

Also, this suggestion appears to be closing (or at least applying glue
to) the door of a stable that has not contained horses for more than a
decade. The concept of a machine UUID is far from new or innovative at
this point.

systemd's machine-id(5) now recommends using a HMAC of the machine
ID with an application-specific key (reference implementation:
sd_id128_get_machine_app_specific()), which is not something that the
D-Bus maintainers thought of back in 2006, but with hindsight is an
improvement over just having one form of the machine ID; but again,
not everything can do this without it being an incompatible change.

(If machine-id(5) already existed, but D-Bus didn't, and I was designing
D-Bus now, then I'd probably be using sd_id128_get_machine_app_specific()
or equivalent for the "is this peer on the same machine as me?" APIs
in the D-Bus specification; but that isn't the order in which things
happened.)

smcv



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-15 Thread Ian Jackson
Simon McVittie writes ("Re: Generating new IDs for cloning (was Re: duplicate 
popularity-contest ID)"):
> Somehow describing which containers and chroots should have a machine ID,
> which ones should share the host's machine ID and which ones don't need
> either is a gap in my proposal.

Do we have a list of all the things this is (or might be) used for ?
I think that would help us think about these kind of questions, and
also decide how important it was to improve this area.  (Please
forgive me if someone already mentioned such a list which I overlooked
in this thread.)

We need to think about the privacy implications.  Certainly the
machine id should not normally go into network protocols.

Can we think of other uses of the machine id that might seem like a
good idea to some upstreams, but of which we would disapprove (whether
for technical or ethical reasons) ?

I wonder if we should in Debian have a "sticky door" policy on the use
of machine-id, like we do for virtual packages: "please come to -devel
for a peer review".  We could spot these issues with a lintian check
maybe.

Sorry that these considerationsn probably seem rather negative.  It's
in my nature to try to spot the downsides and problems with things;
please take this as an attempt at constructive foresight.

If we decide this machine-id is a good thing that should be in X and Y
and Z (containers, chroots, "pets" running sysvinit, or whatever
combination, etc.) then we could implement that in our own
arrangements even if upstream haven't taken those patches yet.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-14 Thread Simon McVittie
On Tue, 13 Aug 2019 at 22:01:34 -0400, Theodore Y. Ts'o wrote:
> That's just a matter of having sysvinit (and other non-systemd init
> systems) have an init script which runs as soon as the root file
> system is remounted read/write to initialize /etc/machine-id if it
> doesn't exist or if it is a zero-length file, right?

Yes ish, although it isn't *necessarily* an init system responsibility.
Somehow describing which containers and chroots should have a machine ID,
which ones should share the host's machine ID and which ones don't need
either is a gap in my proposal.

init is no longer Essential, so Debian chroots and containers will often
have neither systemd nor sysvinit (or any of the other alternatives),
but perhaps they should have a machine-id anyway - or perhaps container
managers that don't run a full init system, like schroot, should be
responsible for that? Or perhaps this requirement isn't necessary
for containers that don't provide either system services or user
logins? (The elephant in the room here is that Docker doesn't arrange to
have a machine-id, and also doesn't set the $container_uuid proposed in
.)

systemd-nspawn already sets up a machine ID for its containers, and lxc
(presumably also lxd) normally runs init, but schroot and Docker don't
normally run init and also don't take any particular steps to have a
machine ID.

Flatpak copies the machine ID from the host system into its containers,
and I would assume that other frameworks with "app containers" that are
conceptually part of the host machine rather than their own machine,
like Snap and AppImage, probably do the same.

An implementation of this should copy the dbus machine ID if it exists
(if the dbus machine ID differs from machine-id(5) then for historical
reasons various libraries will disagree on which is more important)
and the other subtleties described in systemd-machine-id-setup(1) are
probably also a good idea. On Linux systems dbus-uuidgen is not required,
because `tr -d - < /proc/sys/kernel/random/uuid` is suitable. I'm sure
kFreeBSD and Hurd have an equivalent, but I don't know what it is.

smcv



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-13 Thread Theodore Y. Ts'o
On Tue, Aug 13, 2019 at 06:30:51PM +0100, Simon McVittie wrote:
> > >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in
> > >> >general (systemd or not)?
> > 
> > So /etc/machine-id should be in Policy?
> 
> Probably yes, if that proposal has consensus, although a prerequisite
> for it being in Policy would be to have an implementation of making it
> exist even on systems with neither systemd nor dbus installed (Policy
> is meant to document what's true, not what we hope will become true).

That's just a matter of having sysvinit (and other non-systemd init
systems) have an init script which runs as soon as the root file
system is remounted read/write to initialize /etc/machine-id if it
doesn't exist or if it is a zero-length file, right?

  - Ted



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-13 Thread Simon McVittie
On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote:
> On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie 
> wrote:
> >(systemd cannot create a mount point that doesn't exist yet on a read-only
> >file system, which is why a zero-byte file is preferred.
> 
> but you can bind-mount over a file? I wasn't aware of that.

Yes, you can bind-mount a directory over another directory, or a
non-directory non-symlink over another non-directory non-symlink.
(Symlinks get dereferenced before they're used as the source or
destination of a bind-mount.)

bubblewrap and other container-runners often use this when setting
up containers - for example if you have a Flatpak app installed, try
something like

flatpak run --command=mount org.gnome.Recipes

and you'll see that the container's /etc is a mixture of read-only
bind-mounts from the host system and read-only bind-mounts from the
runtime, some of which are individual files.

> >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in
> >> >general (systemd or not)?
> 
> So /etc/machine-id should be in Policy?

Probably yes, if that proposal has consensus, although a prerequisite
for it being in Policy would be to have an implementation of making it
exist even on systems with neither systemd nor dbus installed (Policy
is meant to document what's true, not what we hope will become true).

smcv



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-13 Thread Marc Haber
On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie 
wrote:
>(systemd cannot create a mount point that doesn't exist yet on a read-only
>file system, which is why a zero-byte file is preferred.

but you can bind-mount over a file? I wasn't aware of that.

>If you use systemd as init, install dbus, delete or empty /etc/machine-id,
>delete /var/lib/dbus/machine-id and reboot, then systemd will recreate
>/etc/machine-id very early in the boot process. Less early but still early
>in the boot process (before units with DefaultDependencies=yes, analogous
>to rcS in sysvinit), systemd-tmpfiles will make /var/lib/dbus/machine-id
>a symlink as directed by /usr/lib/tmpfiles.d/dbus.conf. By the time
>ordinary system services start, it is already a symlink. Might this be
>what happened on your test systems?

Probably, yes.

>> >Maybe /etc/machine-id should be part of the "API" of a Debian system in
>> >general (systemd or not)?
>> 
>> please elaborate on that.
>
>There are some properties that we guarantee every Debian system will have,
>even though they cannot be guaranteed on every GNU or Linux system. For
>example, Policy guarantees that /var/run is always a symlink to /run on
>Debian systems (even though they are distinct directories on e.g.
>Slackware[1], and as a result upstream projects like dbus can't rely on
>/var/run being equivalent to /run). Similarly, we guarantee that all
>Debian systems will have the base-passwd users and groups, with their
>canonical numeric values.

So /etc/machine-id should be in Policy?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-13 Thread Sam Hartman
> "Simon" == Simon McVittie  writes:

Simon> If you use systemd as init, install dbus, delete or empty
Simon> /etc/machine-id, delete /var/lib/dbus/machine-id and reboot,

It is my experience that deleting /etc/machine-id doesn't actually work
(even if I delete the dbus machine id too).
It may well be that a zero-byte file works; I didn't know to try that.
But my experience parallels someone earlier on the list that deleting
machine-id does not actually work.



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-13 Thread Simon McVittie
On Tue, 13 Aug 2019 at 11:50:27 +0200, Marc Haber wrote:
> On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie 
> wrote:
> >Making /etc/machine-id a 0-byte file is considered to be the canonical
> >way to clear it, rather than actually deleting it, because if systemd is
> >running on a completely read-only root filesystem, it has code to create
> >a machine ID on a tmpfs and bind-mount it over the top of the empty file.
> 
> And what will systemd do when it encounters a zero-sized
> /etc/machine-id on a writable filesystem?

Replace it with a new machine ID, the same as if it didn't exist at all:

   After the machine ID is established, systemd(1) will attempt to save it
   to /etc/machine-id. If this fails, it will attempt to bind-mount a
   temporary file over /etc/machine-id. It is an error if the file system
   is read-only and does not contain a (possibly empty) /etc/machine-id
   file.
   — machine-id(5)

(systemd cannot create a mount point that doesn't exist yet on a read-only
file system, which is why a zero-byte file is preferred.)

> >If you are doing cloning, stateless systems or similar activities,
> >and you know you will have a valid /etc/machine-id (you either use
> >systemd or have taken other steps to have one), then you can make
> >/var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a
> >systemd-tmpfiles file to do this). This is not done by default in Debian,
> >or by `dbus-uuidgen --ensure`, for historical reasons
> 
> Interesting, I see this on a number of my test systems without having
> been active in this regard myself.

If you use systemd as init, install dbus, delete or empty /etc/machine-id,
delete /var/lib/dbus/machine-id and reboot, then systemd will recreate
/etc/machine-id very early in the boot process. Less early but still early
in the boot process (before units with DefaultDependencies=yes, analogous
to rcS in sysvinit), systemd-tmpfiles will make /var/lib/dbus/machine-id
a symlink as directed by /usr/lib/tmpfiles.d/dbus.conf. By the time
ordinary system services start, it is already a symlink. Might this be
what happened on your test systems?

I'm fairly sure that dbus-uuidgen (which is run in dbus.postinst,
and from /etc/init.d/dbus on non-systemd systems) always makes
/var/lib/dbus/machine-id a regular file rather than a symlink, but if
you already had dbus installed before you reset the machine ID, and you
did not subsequently boot with a non-systemd init, then dbus-uuidgen
wouldn't have been run. If /var/lib/dbus/machine-id is already a symlink
to a file with contents in the right format, dbus-uuidgen won't replace it.

> >Maybe /etc/machine-id should be part of the "API" of a Debian system in
> >general (systemd or not)?
> 
> please elaborate on that.

There are some properties that we guarantee every Debian system will have,
even though they cannot be guaranteed on every GNU or Linux system. For
example, Policy guarantees that /var/run is always a symlink to /run on
Debian systems (even though they are distinct directories on e.g.
Slackware[1], and as a result upstream projects like dbus can't rely on
/var/run being equivalent to /run). Similarly, we guarantee that all
Debian systems will have the base-passwd users and groups, with their
canonical numeric values.

Some of those properties either originated in systemd and were adopted in
Debian for even non-systemd systems (for example /usr/lib/os-release in
base-files, which originated in systemd as a replacement for lsb_release
and distro-specific facilities like /etc/debian_version), or originated in
Debian or some other distro and have been adopted by systemd as one of its
"API" guarantees on all distros that use it (for example systemd picked
up Debian's /etc/hostname, /etc/timezone and /etc/sysctl.d). In both
cases this is done on the basis that regardless of origin, they are good
ideas that should be spread further, and giving application and library
maintainers more "API" guarantees from the OS makes their jobs easier.

What I'm suggesting is that maybe a systemd-style /etc/machine-id should
be one of those properties that we guarantee, instead of relying on dbus
(which is an IPC system that has very little to do with uniquely
identifying a machine) to provide the closest thing that is guaranteed on
non-systemd-booted machines.

Because systemd does not delete /etc/machine-id even when purged (that
would be counterproductive for its intended purpose, and would break
stored state that refers to it), it is present on all systems that either
boot with systemd or have switched from systemd to sysvinit. The only
Debian systems that will not already have /etc/machine-id are those that
were installed before systemd became the default (wheezy or older) or
as a minimal debootstrap with no init system at all (jessie or newer),
may have subsequently been upgraded to newer suites, but have never run
systemd.postinst or booted with systemd.

smcv

[1] I think this is an 

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-13 Thread Marc Haber
On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie 
wrote:
>Making /etc/machine-id a 0-byte file is considered to be the canonical
>way to clear it, rather than actually deleting it, because if systemd is
>running on a completely read-only root filesystem, it has code to create
>a machine ID on a tmpfs and bind-mount it over the top of the empty file.

And what will systemd do when it encounters a zero-sized
/etc/machine-id on a writable filesystem?

>If you are doing cloning, stateless systems or similar activities,
>and you know you will have a valid /etc/machine-id (you either use
>systemd or have taken other steps to have one), then you can make
>/var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a
>systemd-tmpfiles file to do this). This is not done by default in Debian,
>or by `dbus-uuidgen --ensure`, for historical reasons; maybe it should be,
>but to be confident that it was a correct change I'd have to think about
>the ways in which it might go wrong on non-systemd systems (with either
>a non-systemd init like sysvinit, or no init at all like minimal chroots).

Interesting, I see this on a number of my test systems without having
been active in this regard myself.

>Maybe /etc/machine-id should be part of the "API" of a Debian system in
>general (systemd or not)?

please elaborate on that.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834



Re: Generating new IDs for cloning

2019-08-13 Thread Marc Haber
On Thu, 8 Aug 2019 22:59:05 +0100, Simon McVittie 
wrote:
>On Thu, 08 Aug 2019 at 08:37:16 -0400, Marvin Renich wrote:
>> Does anyone know what applications use this file for what purpose?  Is
>> this a systemd-ism?
>
>It originated as /var/lib/dbus/machine-id in D-Bus, and systemd picked it
>up and generalized it into something non-D-Bus-specific. It isn't really
>particularly specific to either D-Bus or systemd: they both provide it
>as a piece of generically useful functionality for anything else that
>wants it. Asking which applications use it is a bit like asking which
>applications use gethostname(2): you are not going to get an exhaustive
>list unless you use something like codesearch.
>
>It's intended as an opaque, non-human-meaningful, persistent unique
>identifier for a machine (or more precisely an OS installation), used as
>a lookup key in state/configuration storage in the same sorts of places
>you might be tempted to use a hostname.
>
>Being opaque and non-human-meaningful is important for some of the
>places where it's useful, because if a string is human-meaningful (like a
>hostname), then people will sometimes want to change it, and when they do,
>anything that was recording machine-specific state with the hostname as
>unique identifer will no longer be able to associate the machine-specific
>state with the machine, effectively resulting in data loss.
>
>One example of the machine ID being used to identify hardware devices
>is that GNOME stores screen layout configuration keyed by machine ID,
>so that if you have an NFS-shared home directory or similar, it won't try
>to use your laptop's monitor layout on your desktop (or keep overwriting
>one layout with the other).
>
>One example of the machine ID being used to identify an OS installation is
>that if you use the systemd-boot EFI bootloader on a dual- or multi-boot
>Linux system (e.g. Debian and Fedora sharing a disk), systemd-boot stores
>each OS installation's kernel(s) in a directory named after the machine
>ID, so that they won't collide.

I have worked that information into the wiki page
https://wiki.debian.org/MachineId and appreciate your input.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834



Re: Generating new IDs for cloning

2019-08-08 Thread Simon McVittie
On Thu, 08 Aug 2019 at 08:37:16 -0400, Marvin Renich wrote:
> Does anyone know what applications use this file for what purpose?  Is
> this a systemd-ism?

It originated as /var/lib/dbus/machine-id in D-Bus, and systemd picked it
up and generalized it into something non-D-Bus-specific. It isn't really
particularly specific to either D-Bus or systemd: they both provide it
as a piece of generically useful functionality for anything else that
wants it. Asking which applications use it is a bit like asking which
applications use gethostname(2): you are not going to get an exhaustive
list unless you use something like codesearch.

It's intended as an opaque, non-human-meaningful, persistent unique
identifier for a machine (or more precisely an OS installation), used as
a lookup key in state/configuration storage in the same sorts of places
you might be tempted to use a hostname.

Being opaque and non-human-meaningful is important for some of the
places where it's useful, because if a string is human-meaningful (like a
hostname), then people will sometimes want to change it, and when they do,
anything that was recording machine-specific state with the hostname as
unique identifer will no longer be able to associate the machine-specific
state with the machine, effectively resulting in data loss.

One example of the machine ID being used to identify hardware devices
is that GNOME stores screen layout configuration keyed by machine ID,
so that if you have an NFS-shared home directory or similar, it won't try
to use your laptop's monitor layout on your desktop (or keep overwriting
one layout with the other).

One example of the machine ID being used to identify an OS installation is
that if you use the systemd-boot EFI bootloader on a dual- or multi-boot
Linux system (e.g. Debian and Fedora sharing a disk), systemd-boot stores
each OS installation's kernel(s) in a directory named after the machine
ID, so that they won't collide.

smcv



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-08 Thread Simon McVittie
On Thu, 08 Aug 2019 at 13:39:54 +0200, Marc Haber wrote:
> Generating a new machine-id doesn't seem as easy as generating a new
> ssh key: Removing /etc/machine-id doesn't do it as
> systemd-machine-id-setup seems to pull the machine-id from dbus.

For historical reasons (dbus originated the concept and
systemd generalized it into a non-D-Bus-specific "API"), each of
systemd-machine-id-setup and dbus-uuidgen tries to copy the other's
machine ID, to avoid problems where processes that read the two files
in opposite orders disagree on what the machine's unique ID is.
If you delete or empty /etc/machine-id you should also delete
/var/lib/dbus/machine-id.

Making /etc/machine-id a 0-byte file is considered to be the canonical
way to clear it, rather than actually deleting it, because if systemd is
running on a completely read-only root filesystem, it has code to create
a machine ID on a tmpfs and bind-mount it over the top of the empty file.

If you are doing cloning, stateless systems or similar activities,
and you know you will have a valid /etc/machine-id (you either use
systemd or have taken other steps to have one), then you can make
/var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a
systemd-tmpfiles file to do this). This is not done by default in Debian,
or by `dbus-uuidgen --ensure`, for historical reasons; maybe it should be,
but to be confident that it was a correct change I'd have to think about
the ways in which it might go wrong on non-systemd systems (with either
a non-systemd init like sysvinit, or no init at all like minimal chroots).

Maybe /etc/machine-id should be part of the "API" of a Debian system in
general (systemd or not)?

smcv



Re: Generating new IDs for cloning

2019-08-08 Thread Marvin Renich
* Michael Stone  [190808 12:34]:
> I guess I need you to say what's confusing. It's an ID that doesn't change.
> You can look up gethostid to get a little more background. If you need an ID

First, let me say that I am not trying to be intentionally obtuse.  I am
really interested to know what programs, more specifically, what
services in a "typical" installation, actually use machine-id (for one
or more definitions of "typical", e.g. desktop or server).

What prompted my question was that someone earlier in this thread stated
that when he removed this file the system became unbootable (I think it
was a banana pi).  What part of the boot process fails?  What other
things that are commonly installed on some large class of machines are
going to fail if this is either missing or identical to ten other
machines on the same network that I cloned from the same image?

Marc's comment that systemd-networkd fails is a good partial answer.
The fact that the man page belongs to the systemd package is another
good clue, but not an answer.  Was this file added as part of systemd
because it was believed that gethostid(3) was insufficient?  If so, what
parts of systemd use it?

...Marvin



Re: Generating new IDs for cloning

2019-08-08 Thread Russ Allbery
Michael Stone  writes:

> So to find out what applications use the file you'd have to look for
> references to the various APIs (such as
> sd_id128_get_machine_app_specific or dbus-uuidgen) which themselves use
> /etc/machine-id

I believe the point of the question was to see if anyone had already done
this and knew the results, to save the effort of a research project if the
information is already documented somewhere or known to someone.

-- 
Russ Allbery (r...@debian.org)   



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-08 Thread Marc Haber
On Wed, 7 Aug 2019 11:15:22 -0400, Marvin Renich 
wrote:
>I think this is a good idea, but will require work and coordination to
>accomplish.  A wiki.debian.org page with your ideas and (perhaps on a
>separate page) a place to list things that need updating after the
>physical copying is complete would be wonderful, if you feel motivated
>to get it started.  :-)  Hostname, machine-id (new to me too!), and ssh
>host keys can start the list.

https://wiki.debian.org/MachineId

as a beginning.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834



Re: Generating new IDs for cloning

2019-08-08 Thread Michael Stone

On Thu, Aug 08, 2019 at 06:16:31PM +0200, Marc Haber wrote:

On Thu, 8 Aug 2019 11:50:07 -0400, Michael Stone 
wrote:

On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:

* Michael Stone  [190808 08:42]:

On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> Does anyone know what applications use this file for what purpose?  Is
> this a systemd-ism?

man machine-id


The man page says what it is (a unique, random ID for the machine) and
how to initialize it, but says nothing about why it exists. What
applications expect it to be there?



From the man page:


  The machine ID does not change based on local or network configuration
  or when hardware is replaced. Due to this and its greater length, it
  is a more useful replacement for the gethostid(3) call that POSIX
  specifies.
[...]
  When a machine is booted with systemd(1) the ID of the machine will be
  established. If systemd.machine_id= or --machine-id= options (see
  first section) are specified, this value will be used. Otherwise, the
  value in /etc/machine-id will be used. If this file is empty or
  missing, systemd will attempt to use the D-Bus machine ID from
  /var/lib/dbus/machine-id, the value of the kernel command line option
  container_uuid, the KVM DMI product_uuid (on KVM systems), and finally
  a randomly generated UUID.


What Marvin says: That doesn't explain anything.


I guess I need you to say what's confusing. It's an ID that doesn't 
change. You can look up gethostid to get a little more background. If 
you need an ID for a host it's useful. If you don't need an ID for a 
host, then it's not so useful. Once upon a time (gethostid(3) alludes to 
this) it was thought that an IPv4 would be a good unique ID, but with 
the rise of NAT it quickly became useless and hence the search for an 
alternative. The second paragraph is pretty clear that machine-id is one 
of a number of possible seeds for systemd to set the machine's ID. The 
rest of the file talks about how applications can use an API to get a 
constant ID based on the machine ID and that applications should 
generally not use the contents of the machine-id file directly. So to 
find out what applications use the file you'd have to look for 
references to the various APIs (such as 
sd_id128_get_machine_app_specific or dbus-uuidgen) which themselves use 
/etc/machine-id




Re: Generating new IDs for cloning

2019-08-08 Thread Marc Haber
On Thu, 8 Aug 2019 11:50:07 -0400, Michael Stone 
wrote:
>On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:
>>* Michael Stone  [190808 08:42]:
>>> On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
>>> > Does anyone know what applications use this file for what purpose?  Is
>>> > this a systemd-ism?
>>>
>>> man machine-id
>>
>>The man page says what it is (a unique, random ID for the machine) and
>>how to initialize it, but says nothing about why it exists. What
>>applications expect it to be there?
>
>>From the man page:
>
>   The machine ID does not change based on local or network configuration
>   or when hardware is replaced. Due to this and its greater length, it
>   is a more useful replacement for the gethostid(3) call that POSIX
>   specifies.
>[...]
>   When a machine is booted with systemd(1) the ID of the machine will be
>   established. If systemd.machine_id= or --machine-id= options (see
>   first section) are specified, this value will be used. Otherwise, the
>   value in /etc/machine-id will be used. If this file is empty or
>   missing, systemd will attempt to use the D-Bus machine ID from
>   /var/lib/dbus/machine-id, the value of the kernel command line option
>   container_uuid, the KVM DMI product_uuid (on KVM systems), and finally
>   a randomly generated UUID.

What Marvin says: That doesn't explain anything.

I have, btw, just learned that systemd-networkd won't even attempt to
bring up your network if /etc/machine-id doesn't exist. duh.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834



Re: Generating new IDs for cloning

2019-08-08 Thread Michael Stone

On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:

* Michael Stone  [190808 08:42]:

On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> Does anyone know what applications use this file for what purpose?  Is
> this a systemd-ism?

man machine-id


The man page says what it is (a unique, random ID for the machine) and
how to initialize it, but says nothing about why it exists. What
applications expect it to be there?



From the man page:


  The machine ID does not change based on local or network configuration
  or when hardware is replaced. Due to this and its greater length, it
  is a more useful replacement for the gethostid(3) call that POSIX
  specifies.
[...]
  When a machine is booted with systemd(1) the ID of the machine will be
  established. If systemd.machine_id= or --machine-id= options (see
  first section) are specified, this value will be used. Otherwise, the
  value in /etc/machine-id will be used. If this file is empty or
  missing, systemd will attempt to use the D-Bus machine ID from
  /var/lib/dbus/machine-id, the value of the kernel command line option
  container_uuid, the KVM DMI product_uuid (on KVM systems), and finally
  a randomly generated UUID.



Re: Generating new IDs for cloning

2019-08-08 Thread Marvin Renich
* Michael Stone  [190808 08:42]:
> On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> > Does anyone know what applications use this file for what purpose?  Is
> > this a systemd-ism?
> 
> man machine-id

The man page says what it is (a unique, random ID for the machine) and
how to initialize it, but says nothing about why it exists.  What
applications expect it to be there?

...Marvin



Re: Generating new IDs for cloning

2019-08-08 Thread Michael Stone

On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:

Does anyone know what applications use this file for what purpose?  Is
this a systemd-ism?


man machine-id



Re: Generating new IDs for cloning

2019-08-08 Thread Marvin Renich
* Bernhard Schmidt  [190808 07:48]:
> Am 08.08.19 um 13:39 schrieb Marc Haber:
> > How do I generate a new one?
> 
> I followed
> https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id
> last time which means

Hmm.  The advice in that link doesn't match what man machine-id says,
which is to replace /etc/machine-id with an empty file rather than
remove it, and then reboot.

I have no idea which is the "correct" solution, but if the man page is
correct, that seems to be the simpler solution.

Does anyone know what applications use this file for what purpose?  Is
this a systemd-ism?

...Marvin



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-08 Thread Bernhard Schmidt
Am 08.08.19 um 13:39 schrieb Marc Haber:
> On Wed, 07 Aug 2019 09:28:12 -0400, The Wanderer
>  wrote:
>> On 2019-08-07 at 04:26, Russell Stuart wrote:
>>
>>> On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote:
>>>
 I am using Debian for two decades now, and I realized that
 necessity two days ago.
>>>
>>> Ditto - except for me it was a few seconds ago.
>>
>> In my case, it was when I read this thread last night. (After more like
>> ~1.5 decades of Debian, for what that's worth.)
> 
> Generating a new machine-id doesn't seem as easy as generating a new
> ssh key: Removing /etc/machine-id doesn't do it as
> systemd-machine-id-setup seems to pull the machine-id from dbus.
> 
> I have four Banana Pis with identical machine IDs because they were
> cloned from a common image. Since that one originates from a Debian
> Wiki Page about the Banana Pi I guess that the vast majority of Banana
> Pis running Debian has this machine id.
> 
> How do I generate a new one?

I followed
https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id
last time which means

rm -f /etc/machine-id
dbus-uuidgen --ensure=/etc/machine-id
rm /var/lib/dbus/machine-id
dbus-uuidgen --ensure

Last time I only removed /etc/machine-id (hoping it would be regenerated
on Reboot) rendered the machine unbootable.

FTR, I have also only recently learned about this. Duplicate machine-ids
can have very nasty consequences. We recently had a weird networking
issue at one department where clients got assigned the same address from
the dynamic DHCP pool and kicked each other out of the network.

It took us a while to figure out the admin had cloned Kubuntu 18.04
workstations that use systemd-networkd for network configuration.
systemd-networkd DHCP by default sends the machine-id as
client-identifier, and isc-dhcp by default uses the client-identifier
(if present) instead of the MAC address to track leases.

Bernhard



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-08 Thread Marc Haber
On Wed, 07 Aug 2019 09:28:12 -0400, The Wanderer
 wrote:
>On 2019-08-07 at 04:26, Russell Stuart wrote:
>
>> On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote:
>> 
>>> I am using Debian for two decades now, and I realized that
>>> necessity two days ago.
>> 
>> Ditto - except for me it was a few seconds ago.
>
>In my case, it was when I read this thread last night. (After more like
>~1.5 decades of Debian, for what that's worth.)

Generating a new machine-id doesn't seem as easy as generating a new
ssh key: Removing /etc/machine-id doesn't do it as
systemd-machine-id-setup seems to pull the machine-id from dbus.

I have four Banana Pis with identical machine IDs because they were
cloned from a common image. Since that one originates from a Debian
Wiki Page about the Banana Pi I guess that the vast majority of Banana
Pis running Debian has this machine id.

How do I generate a new one?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-07 Thread The Wanderer
On 2019-08-07 at 16:59, Andrei POPESCU wrote:

> On Mi, 07 aug 19, 09:28:12, The Wanderer wrote:
> 
>> I've begun to wonder whether it might be worth the overhead to set up
>> some type of mechanism to let packages which define such
>> machine-specific IDs A: declare the fact, in a central location which
> 
> Do you mean /etc? :)

It would probably go under /etc/, but that's not what you seem to mean.

>> the sysadmin of a machine where that package is installed can easily
>> check, and B: define an automated way of performing the appropriate
>> update / regenerate step in a way which covers all known places where
>> the ID needs to be updated.
> 
> 1. Delete the contents of /etc (all of it)
> 2. If a package doesn't find its "stuff" in /etc it regenerates it from 
> defaults.
> 
> http://0pointer.net/blog/projects/stateless.html

Maybe I'm missing something, but I don't think that seems to cover all
cases.

For example, in the case where defining (I think it was) an mdadm array
embeds the then-existing hostname into the array definition, such that
the array will only be auto-assembled when it is detected on a machine
with that same hostname, it's not enough to simply wipe /etc/hostname;
you also need to arrange for the new hostname, once generated, to be
inserted into the definition of the existing array.

That's probably more relevant to the case of changing the hostname of a
single machine than of cloning a machine, since I'm hard pressed to
think of a plausible case for using RAID on a machine which is to be
cloned (and also since I think it's possible to explicitly omit the
hostname when creating the array, such that the array will auto-assemble
on any system), but there's no guarantee it's the only example of
something which needs to be updated outside of /etc/ in order for things
to keep working.

At a glance, there are also unique LVM IDs in /boot/grub/grub.cfg,
though whether those would need to be changed when cloning I don't know.
I also vaguely recall having once run into issues related to filesystems
being by default configured to mount by unique ID rather than by device
path, which thus didn't mount anymore once the filesystem had been
cloned from its original drive onto a different drive which had a
different ID, but it's been too long for me to dredge up any specifics.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-07 Thread Paul Wise
On Thu, Aug 8, 2019 at 4:59 AM Andrei POPESCU wrote:

> 1. Delete the contents of /etc (all of it)
> 2. If a package doesn't find its "stuff" in /etc it regenerates it from
> defaults.

There is still way too much stuff that defaults to installing
important files in /etc (default config settings, init scripts etc).

It would be nice to have a way to tell all postinsts to not generate
system-specific files (like machine-id or SSH keys) but do generate
caches. Cleaning up after postinsts seems like a hack to me.

There are some notes on reproducible installs here, IIRC Tails and
Webconverger have achieved that for their live images:

https://wiki.debian.org/ReproducibleInstalls

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-07 Thread Andrei POPESCU
On Mi, 07 aug 19, 09:28:12, The Wanderer wrote:
> 
> I've begun to wonder whether it might be worth the overhead to set up
> some type of mechanism to let packages which define such
> machine-specific IDs A: declare the fact, in a central location which

Do you mean /etc? :)

> the sysadmin of a machine where that package is installed can easily
> check, and B: define an automated way of performing the appropriate
> update / regenerate step in a way which covers all known places where
> the ID needs to be updated.

1. Delete the contents of /etc (all of it)
2. If a package doesn't find its "stuff" in /etc it regenerates it from 
defaults.

http://0pointer.net/blog/projects/stateless.html


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-07 Thread Russ Allbery
The Wanderer  writes:

> This isn't the first time I've discovered that some aspect of a Debian
> system would actually need to be cleared and re-generated when that
> system is cloned, well after the point where it would have been easy for
> me to address that need. (Fortunately, although I've moved in the
> direction of cloned Debian systems multiple times in the past, so far
> all of those have petered out before reaching production. I still want
> to change that at some point, however.)

I'm only vaguely aware of this package and how it works, but doesn't
cloud-init have some support for customizing things that need to change
when cloning an image?  Does it already handle machine-id?  Maybe we just
need to popularize it and explain better how to add additional hooks for
the needs of other packages?

-- 
Russ Allbery (r...@debian.org)   



Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

2019-08-07 Thread Marvin Renich
* The Wanderer  [190807 09:28]:
> Cloning isn't the only example of a case where some machine-specific
> configuration detail may need to be updated, without that being obvious
> in advance.
> 
> I've begun to wonder whether it might be worth the overhead to set up
> some type of mechanism to let packages which define such
> machine-specific IDs A: declare the fact, in a central location which
> the sysadmin of a machine where that package is installed can easily
> check, and B: define an automated way of performing the appropriate
> update / regenerate step in a way which covers all known places where
> the ID needs to be updated.

I think this is a good idea, but will require work and coordination to
accomplish.  A wiki.debian.org page with your ideas and (perhaps on a
separate page) a place to list things that need updating after the
physical copying is complete would be wonderful, if you feel motivated
to get it started.  :-)  Hostname, machine-id (new to me too!), and ssh
host keys can start the list.

...Marvin