[systemd-devel] preset enables everything by default

Lennart Poettering lennart at poettering.net
Fri Dec 5 05:06:52 PST 2014


On Thu, 04.12.14 18:58, Michael Marineau (michael.marineau at coreos.com) wrote:

> > We use the machine-id file as check whether /etc is populated or
> > not. If people pre-populate /etc, and don't wan't the full
> > "first-boot" logic of systemd to take action, then they should also
> > add machine-id file there (they can even just touch it if they want,
> > which will disable the first-boot logic, but still initialize the file
> > either directly if writable or overmounted if not).
> 
> So when assembling a machine image that will be used to create a bunch
> of pre-configured hosts the correct thing to do is 'echo >
> machine-id', not 'rm machine-id'?

Well, it's up to you:

a) install a "disable *" preset file in your /usr, and use "rm /etc/machine-id"

b) don't install any preset file and use "echo > /etc/machine-id"

If you opt for a, then this has the benefit that the first bootup is
still special, and ConditionFirstBoot= will still trigger for it,
which might be useful for a number of services.

If I were you I'd opt for a).

> >> This behavior is probably ok in the case of interactively using
> >> systemctl preset and preset-all when it is known that the user
> >> explicitly asked the system to do something and can see what it did.
> >> In the case of the system booting I would expect "do nothing" to be
> >> the default when no preset file explicitly sates otherwise.
> >
> > Then ship a "disable *" preset file in /sr. In this case, nothing will
> > be enabled by default. THis is what we do on Fedora.
> 
> And I've added this to CoreOS too. The gist of my rambling email was
> why is this not the default?

Well, for simplicity reasons, outside of the stateless machines
business it is kinda useful being able to ignore the entire complexity
of presets, enabling, disabling, and just consider the RPM scriptlets
as something that truns on what is being installed, end of story.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list