[systemd-devel] [ANNOUNCE] systemd 216

[Lennart Poettering]

On Tue, 19.08.14 22:25, Dave Reisner (d at falconindy.com) wrote:

> The sysusers.d file shipped with this has:
> 
>   u systemd-journal-remote        -               "systemd Journal Remote"
> 
> But the tmpfiles.d fragment has:
> 
>   z /var/log/journal/remote 2755 root systemd-journal-remote - -
>   z /run/log/journal/remote 2755 root systemd-journal-remote - -
> 
> There's no "systemd-journal-remote" group created...

In sysusers, each system user will always implicitly get a group of the
same name too.

> >         * A new component "systemd-firstboot" has been added that
> >           queries the most basic systemd information (timezone,
> >           hostname, root password) interactively on first
> >           boot. Alternatively it may also be used to provision these
> >           things offline on OS images installed into directories.
> 
> This tool offers a --setup-machine-id flag, but it has very different
> semantics from systemd-machine-id-setup. Both will call sd128_randomize,
> but systemd-machine-id-setup will always prefer hardcoded UUIDs passed
> into the host. For example, launching a qemu kvm with the -uuid flag
> will cause the machine-id to mirror this -- though, this alone can be
> problematic[1]
> 
> Is this behavior intentional? Does firstboot need to learn the same
> rules? Do we just retire systemd-machine-id-setup?

The behaviour of s-f-b here is intentional. "systemd-first-boot"'s
--setup-machine-id flag is only available if you use it for
offline-provisioning of new machine images. But in that case you
definitely *don't* want any VM/container UUID of the host you do this on
to leak into the new image.

Note that if you bootup PID 1 and /etc/machine-id is missing it will
initialize things from the VM/container if there is one, and otherwise
randomize the ID and write it to disk, hence doing "online-provisioning"
in systemd-first-boot is unnecessary (and too late).

The old s-m-i-s tool (which is not too useful anymore, now that s-f-b
exists), should follow the same behaviour here. I have now changed it to
ignore the VM/container UUID if it operates on a root directory.

Lennart

-- 
Lennart Poettering, Red Hat