[systemd-devel] [ANNOUNCE] systemd 216

[Dave Reisner]

On Wed, Aug 20, 2014 at 01:52:51PM +0200, Lennart Poettering wrote:
> 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.
> 

Ok, I see that now. Digging into the logic of how this works, sysusers
will probably never run after an online update. Is the expectation that
distros just run systemd-sysusers in their post_upgrade scripts?

> > >         * 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.

SGTM -- this fixes an older bug:

http://lists.freedesktop.org/archives/systemd-devel/2014-April/018934.html

> Lennart
> 
> -- 
> Lennart Poettering, Red Hat
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel