On Wed, Aug 20, 2014 at 01:52:51PM +0200, Lennart Poettering wrote: > On Tue, 19.08.14 22:25, Dave Reisner (d...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel