Le 21/11/2014 12:08, Colin Guthrie a écrit :
Hello again!
Hey, trying to revive the topic :)
Didier Roche wrote on 18/11/14 15:40:
Le 18/11/2014 15:59, Colin Guthrie a écrit :
Hiya,
Hey,
Didier Roche wrote on 18/11/14 13:58:
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).
For the avoidance of doubt, I believe that running systemctl preset
should only ever happen on *first* install, never on upgrade or such
like.
This also avoids any problems here.
(Of course if /etc is nuked, then reapplying the defaults from *.preset
should be done!)
See my Michael's answer (and my previous one) on the fact that maybe the
preset files would be part of multiple packages (to disable certain
units), and some being only part of packages not installed by default.
Michael's case as well of a unit changing its target on a package
upgrade (as a packaging fix, maybe) is valid as well.
I think the distro-wide preset usage would be in a very core package
that is likely installed very early on (perhaps even the package is
required by the one that ships systemctl and thus has to be installed
first).
If you end up shipping random .preset files with the actual packages
containing the units they affect (which isn't recommend as previously
noted, but perhaps you still want to do it that way for some special
cases) then this too will be fine.
I can see some complications here but nothing that isn't manageable.
This is a good news.
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?
Yeah, but that's assuming there *is* a next one. Once things are
installed, the user should *not* be surprised by any action being taken
without their consent on upgrade.
FWIW, it's probably worth considering how you'd handle not changing
users current preferences with regards to enabling/disabling things on
upgrade. I can see this being quite hard for you roll out with your
current suggestions, but you may have this covered already.
Actually, this reminds me some issues we had with gconf in the past in
changing distribution's default and deciphering what was users current
preference or what was distro default behavior.
Gnome-panel was copying its whole distro defaults in ~/.gconf.
Adding/removing some default layouts and settings from the panel was
then unnecessary difficult. Some changes was part of new default
behaviors we wanted that the user never interacted with and was desired
to be changed (because of some applets getting low maintenance,
incompatible with newer technology or duplicates…)
As everything was at the same place, it was difficult to know if the
current value was set because of the previous default, or if the user
explicitly tweaked and then selected it.
I see the same issue with the shared /etc: is this unit enabled for that
target because of one the preset config, or did the admin run "systemctl
enable <unit>" explicitly and want to keep it? I think it's ok to change
distro defaults on upgrade (will be potentially in major version upgrade
of course), not user (admin here) preferences, of course.
I would personally disagree with this statement that it's OK to change
the distro defaults on upgrade. As an admin, whether I observe some
behaviour but do not actively reinforce it (e.g. I see that installing
httpd enables it by default and thus my server is working fine, so I
don't need to do "systemctl enable httpd" manually) I now rely on the
distro default. If that was to be changed on upgrade (whether package or
whole distro), I'd personally be really annoyed!
With the goal of being able to reset things (i.e. trashing /etc) if
desired, the admin has a pretty good choice to start again with a clean
slate after a distro upgrade if they so wish. Otherwise I'd very much
expect my system to retain as much state as possible (whether that may
have come from a preset or an active choice is, IMO, irrelevant - it's
how the system was ultimately configured and what the admin now relies
on) over the distro upgrade process.
That's what we did in multiple cases in ubuntu in particular. I gave in
previous emails some desktop-related email. Another one I didn't mention
is when we changed from gdm to lightdm as the default dm, or gnome-panel
-> unity. If the user selected another dm or another desktop session, we
keep user's preference, if they switched and then switched back, we keep
user's preference as well. We migrate to our new defaults if there was
trace of new user settings.
I guess different settings and policy from different distro, but it's
clearly something that was always not easy to managed and having a clean
/etc will go into that direction in my opinon.
But we do have
no way to know for sure which is which in the current system.
Yeah, I accept this is a limitation of the current system. I guess I'm
just making the argument that, IMO, this detail doesn't matter as I
don't see the need to use this information for anything automated anyway.
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.
Not sure what you mean by "stick it for good" here, but my previous
suggestion was to say "enabled [preset: enabled]" or "enabled [preset:
disabled]" accordingly which might be clearer (if a bit longer).
Same than in previous case:
I have a preset with
enable docker.socket
systemctl status docker.socket
-> "enabled [preset: enabled]"
systectl enable docker.socket
systemctl status docker.socket
-> "enabled [preset: enabled]"
I guess, it should then just be "enabled". Maybe that will then ask for
a systemctl reset <unit> command or something like that…
Oh right, so you're very specifically wanting to differentiate from a
systemctl preset call vs a systemctl enable command and somehow
recording that state somewhere. I guess that makes sense with some of
your previous comments. Sorry for not seeing that properly!
FWIW, all I was suggesting with adding the preset information into the
systemctl status would be to report based on current *.preset files as
to what the preset state would be if it were run now, as if the package
was freshly installed. I wasn't suggesting the usage of systemctl enable
be tracked somehow. So the output you simulated above is what I was
expecting to see anyway :)
As noted previously I think it's very wrong to push the enablement
policy into the individual packages (thus I think using /usr is not an
option), so I think it would be very hard to actually track this detail
anyway if both preset info and normal admin info is both stored in /etc
(that being the alternative to using /usr).
Yeah, in debian/ubuntu, we would mostly have enable * (which is the same
as having no pragma in the preset file from what I understood) + some
specific disablement anyway.
However, I was thinking recently about unit alias and how that would
work. Let's take display managers as an example.
The distribution comes preinstalled with one dm, enable * -> enable it,
have the Alias=display-manager.service picking the right one.
However, let's say the user installed then another dm, what happens?
Both will be enabled if we systemctl preset <new_service> (as the
discussion was to remove our debian enable <service> that was
conditioned on the postinst). I don't think we should have systemctl
preset <new_service> running under any condition as a wipe of /etc and
then "systemctl preset-all" would give a potential different result (I'm
not even sure how this will work with those alias, the first matching
the alias wins and get the symlinks?)
We can of course have an ubuntu-desktop.preset which disables all dms by
lightdm, and an ubuntu-gnome.preset which disables all dms but gdm (and
having those settings conflicting with each other), but it's seems that
for every aliases, we need to maintain such a list (as we enable * by
default)?
Shipping distro defaults enablement symlinks in /usr would enable
avoiding that (we need to have package conflicts for lightdm-default and
gdm-default of course), knowing that we will shadow the alias with a new
symlink in /etc if the admin changes his name for instance.
Without regarding the /etc vs /usr discussion, I really want to
experiment with presets instead of our systemctl enable package postinst
snippets (we don't really run that for the record but make manual
symlinks and store default symlinks in another directory). However, I
would appreciate some guidance on a smart way to achieve this in those
kind of complex cases.
It's too late for that change for debian jessie (getting more and more
frozen), but we can pilot that in ubuntu vivid before pushing it to
jessie+1).
But overall, as is the case I'm trying to make, I really don't see much
value in differentiating the manually enabled vs enabled by preset
cases. IMO, that information cannot (or rather should not) be used in
any automated way, although I do concede that it would be "interesting"
to know this detail as an administrator.
I agree if that was the only one aspect of the problem, the other one
(where we started this discussion) was a readable /etc/systemd/ and
really keeping /etc for machine-specific and admin derivations from
distro. Keeping /usr for the distro, and /etc for the admin (as Lennart
told in multiple conferences).
This is an interesting discussion, and I'm looking forward to see what
others think too :)
Same from me, I hope we can see other people jumping from there and
giving their opinions. :)
Cheers,
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
