Le 18/11/2014 15:55, Tom Gundersen a écrit :
I get where you are coming from, but presets will give you the same
result, no?
Apart from what we discussed on this thread with Martin about the "/etc"
clutterness having distro-specific information and not only system ones,
right.
However, this is kind of a complex case in D/U where we have the policy to
start most of the service on package installation. For instance, if you apt
install docker.io, people using those distros will expect to be then able to
do $ docker run <…> (which starts the docker service through socket
activation).
Hm, not following this last paragraph. Are you saying we are missing
something to do with start-on-install?
Not at all, I was just presenting the difference between Fedora and D/U
policy for instance, the result with preset will be, as Colin mentioned to:
enable *
disable unit1
The thing I'm afraid of that we won't have a single place to list all
disable units, and they will be in multiple packages, so (as I'll repeat
below), I'm unsure that we would able to only load the preset as once
shot, as we may add some preset files as part of packages later on with
the current structure (to disable more units by default).
This would be maybe a nice way for the admin to know what's coming from a
distribution default or not. However, let's say I want to ensure that ssh
will always be available on my server, I would (even if it's in my server
preset) then systemctl enable openssh, no matter whatever future preset
updates does (like disable it in the next batch upgrade).
With a shared distro/admin /etc, we have no way to take that fact into
account and the next one would follow distro policy, right?
Also, after running systemctl enable opensshn, systemctl status openssh will
still say "enabled (preset)" even if the admin wanted to "stick it for good"
as it's part of the preset.
This is up to the distro I guess, but I would have thought that
presets should only be applied on install-time, and not on upgrade.
You mean system install time, right? Having it one shot would be more
complex in our case I think as stated above (I guess, we'll have the
disable distributed in multiple packages, not all being installed by
default).
- systemctl enable <unit> will duplicate the symlink in /etc
I guess this should also be dropped (though the situation here is
weird as it anyway is a noop). Maybe a warning should be printed.
agreed as well, or, this would be a way for the sysadmin to "stick" this
unit/service whatever future distro will choose in the next upgrade.
Could be, yeah, but moving from static to opt-in during an upgrade
sounds like a packaging bug to me, so hopefully this situation would
never be encountered in production.
It should not happen in production, indeed, but packaging errors happen
and we should maybe be able to recover without having impacts on admins
who systemctl enable this unit in particular for their needs?
Well, the meaning we have been using so far is that statically enabled
units are things that does not really make sense to disable (which is
different from it being enabled by default), and for all other units
the way to enable/disable them (be it by default or manually) is by
installing symlinks in /etc. If the admin wants to insist to ignore
the "does not make sense to disable part" and really force something
to never start, then masking is the tool for that. Either way, the
admin should never (need to) go poking in /etc manually, but use
systemctl as the interface.
Indeed, I'm getting where you are coming from now and see the real
difference you mean with default symlinks in /usr. However, it would seem
weird to me to have to systemctl mask plymouth-quit.service for instance
without knowing the internals of systemd to be able to really "disable" (I
know the term is wrong, just trying to feel how they could interprete it) a
certain class of units.
Hm, I didn't follow this paragraph, could you rephrase?
I hope this will be a little bit more clear:
Let's say as an admin that I want to disable plymouth-quit.service
(which is a static unit file and symlinked in /usr/lib… on the
multi-user target). Without knowing the systemd internals, my natural
intent would be to use "systemctl disable plymouth-quit.service" which
is no-op in this case on a static unit enabled on the multi-user target
with the symlink shipped by the package. This may be perceived as
unnatural to him to have to use "systemctl mask" to disable it, or am I
just being too pessimistic?
My take on this is: make sure presets are applied on "firstboot"
(which I think they are), so empty /etc works just fine, and then
improve on systemctl to better show the distinction between 'enabled
by default' or 'enabled by choice' (and same for 'disabled').
Thanks again for your feedback. If the whole proposal is rejected, I think
we'll try to have debian following this as a first step.
Sounds good, but let's see if maybe Zbigniew or Lennart have any
comments on your proposal (if my memory serves me right they did most
of the work in this area).
Sure! Thanks again for your feedback :)
Cheers,
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
