[opensuse-packaging] Fwd: [systemd-devel] [RFC] Preset Files
I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers, Andreas ---------- Forwarded Message ---------- Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering <lennart@poettering.net> To: systemd Mailing List <systemd-devel@lists.freedesktop.org> Heya, many of you probably saw Frederic's rpm macros suggested here. This got Kay and me thinking about implementing something like "presets" in systemd, and before we go and implement that we'd like to hear your opinions on it. This would go hand in hand with Frederic's macros, and both would be included in the upstream systemd package. So what's a "preset" supposed to be? Distributions have different policies on enabling services by default. On Fedora services should default to off, with a small number of exceptions. On Debian OTOH all services are enabled by default. Fedora spins in turn are based on the default Fedora settings but might end up enabling a few services not enabled on the unflavoured Fedora. In general, on desktop systems (i.e. without an educated admin) a default of "enable what is installed" probably makes sense, while many seasoned admins will probably opt more towards the other extreme: "I, the admin am king, and I am the only one enabling services here!". Both approaches of course are valid approaches. Now, traditionally whether a service was enabled or not on most distros was encoded in the packages themselves (i.e. in chkconfig in lines in the scriptlets, or something equivalent), which makes it very difficult to apply spin-specific or admin-specific rules on top. This is information that should not be encoded in the packages, but in some external database. And this is what "presets" are supposed to be. Something like a long list that tells systemd which services to enable by default and which ones not to enable. It's a bit like a SUSE pattern or a Fedora comps, except that it lists services that shall be enabled instead of package that shall be installed. More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this: <snip> disable avahi-daemon.service enable cups.service disable * </snip> Then, we'd add a new command to "systemctl" called "systemctl preset". It would be equivalent to a "systemctl enable" if the unit file passed is listed in any of the preset files on lines prefixed with "enable", or be like a "systemctl disable" if it is listed with a prefix of "disable". Simple globbing would be supported. If no entry is found "systemctl preset" would be synonymous with "systemctl enable". If "systemctl preset" is passed with unit names, those units would be enable/disabled as listed in the preset file. If no argument is passed all units would be reset to the preset defaults. (another long-sought feature...) A few more things to note: - systemd would not ship any preset file by default (and probably not even the directory), this is left to distributions. Most likely the distributions would ship a preset file in some spin-specific RPM, which would conflict with the the RPMs for other spins. - The RPM post macro would always call "systemctl preset" for the units passed, and never anything else. - If an admin wants to manually change "enable-by-default" to "disable-by-default" (or vice versa) he could just drop his own file with "disable *" (or "enable *") into /etc/systemd/system.preset/ and override the vendor/spin settings. - One nice thing is that this would be dead simple to implement (just 10 lines of code or so), and would practically not be visible on systems who don't need any distro spin crack... ;-) - This would kinda bring back the ability that some SysV implementations had with encoding the default enable/disable state for a service somewhere. Some distros had that in the SysV header. With this we now have it independently of the init scripts. - The reason why we'd implement "enable-by-default" instead of "disable-by-default" if no preset file is around is simply the idea that having to install stuff that is not needed is already a failure in itself, and ideally people who want to disable a service would just "rpm -e" it. Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas? Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ----------------------------------------- -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Andreas Jaeger <aj@suse.de> [07-06-11 03:03]:
I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers,
Andreas
---------- Forwarded Message ----------
Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering <lennart@poettering.net> To: systemd Mailing List <systemd-devel@lists.freedesktop.org>
...
Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas?
Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own.
sounds like a plan since it will be default-enabled, a provision should exist to include a preset default-disabled so it is not necessary to singularly disable every unwanted service that is installed. disable all enable 1, 2, 3 -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday, July 06, 2011 13:27:16 Patrick Shanahan wrote:
* Andreas Jaeger <aj@suse.de> [07-06-11 03:03]:
I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers,
Andreas
---------- Forwarded Message ----------
Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering <lennart@poettering.net> To: systemd Mailing List <systemd-devel@lists.freedesktop.org>
...
Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas?
Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own.
sounds like a plan
since it will be default-enabled, a provision should exist to include a preset default-disabled so it is not necessary to singularly disable every unwanted service that is installed.
disable all enable 1, 2, 3
Yeah, that works (with a different syntax ;). I expect that openSUSE to ship a default that reflects what we do today: - by default disable everything - enable a few services The proposal supports this. The nice thing is that it also allows different profiles, e.g. a server or a desktop profile - or a paranoia one ;) - that can be implemented via separate packages without touching the service packages itself, Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mercredi 06 juillet 2011 à 07:27 -0400, Patrick Shanahan a écrit :
* Andreas Jaeger <aj@suse.de> [07-06-11 03:03]:
I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers,
Andreas
---------- Forwarded Message ----------
Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering <lennart@poettering.net> To: systemd Mailing List <systemd-devel@lists.freedesktop.org>
...
Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas?
Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own.
sounds like a plan
since it will be default-enabled, a provision should exist to include a preset default-disabled so it is not necessary to singularly disable every unwanted service that is installed.
disable all enable 1, 2, 3
Well, we should include a "default-disabled" file as our distro policy. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Comments below. On Wed, 6 Jul 2011 09:00, Andreas Jaeger <aj@...> wrote:
I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers,
Andreas
---------- Forwarded Message ----------
Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering <lennart@poettering.net> To: systemd Mailing List <systemd-devel@lists.freedesktop.org>
<snip>
More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this: <snip> A few more things to note:
- systemd would not ship any preset file by default (and probably not even the directory), this is left to distributions. Most likely the distributions would ship a preset file in some spin-specific RPM, which would conflict with the the RPMs for other spins.
To NOT include the preset dir (/lib/systemd/system.preset/) in the systemd-package is not a good decision in terms of foresight. If you include the dir in systemd, you make it clear where it belongs to, and make sure it has the needed ownership and rights. In rpm-terms: mark it as config-dir. That way package-management can check for existence, ownership, rights. AND close a potential security hole (symlink-dir), before it even exists. Those that do not learn from the errors past are damned to repeat them. (original in Latin, spoken in early Rome, wrt the Greek, still true) Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Mittwoch, 6. Juli 2011, Yamaban wrote:
On Wed, 6 Jul 2011 09:00, Andreas Jaeger <aj@...> wrote:
- systemd would not ship any preset file by default (and probably not even the directory), this is left to distributions.
To NOT include the preset dir (/lib/systemd/system.preset/) in the systemd-package is not a good decision in terms of foresight.
If you include the dir in systemd, you make it clear where it belongs to, and make sure it has the needed ownership and rights.
ACK, but...
In rpm-terms: mark it as config-dir.
NACK on marking it as config dir. /lib/systemd/system.preset is only filled by rpms, nothing should be manually changed there. For manual changes/overrides, there will be /etc/systemd/system.preset/ (this directory should also be created by the systemd package). Regards, Christian Boltz --
You only read the second paragraph, didn't you? Why do you write emails where one has to read the stuff between the first and the last word? [> Stephan Kulow and Dirk Mueller in opensuse-packaging] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, 6 Jul 2011 20:09, Christian Boltz <opensuse@...> wrote:
Hello,
on Mittwoch, 6. Juli 2011, Yamaban wrote:
On Wed, 6 Jul 2011 09:00, Andreas Jaeger <aj@...> wrote:
- systemd would not ship any preset file by default (and probably not even the directory), this is left to distributions.
To NOT include the preset dir (/lib/systemd/system.preset/) in the systemd-package is not a good decision in terms of foresight.
If you include the dir in systemd, you make it clear where it belongs to, and make sure it has the needed ownership and rights.
ACK, but...
In rpm-terms: mark it as config-dir.
NACK on marking it as config dir. /lib/systemd/system.preset is only filled by rpms, nothing should be manually changed there.
For manual changes/overrides, there will be /etc/systemd/system.preset/ (this directory should also be created by the systemd package).
Regards,
Christian Boltz
Thanks for the insight. What I (really) meant was to include BOTH dirs in the systemd package, the /lib/... as 'normal' dir and the /etc/... as 'config' dir. That way a service / daemon can include 'just' the /lib/systemd/system.preset/<name> file without the no-owner-for-directory hassle in the package management (see thread on this group this month). The thought behind is: How can we make the systemd package as usefull and easy to handle, use, and maintain as possible. Let's spare us all the hassle / security issues we've already had with the System5-init as much as possible. The clearer we define systemd now, the easier will be the next 20 years of maintenance of systemd itself and the files a service / daemon needs. Thanks, Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mercredi 06 juillet 2011 à 20:40 +0200, Yamaban a écrit :
On Wed, 6 Jul 2011 20:09, Christian Boltz <opensuse@...> wrote:
Hello,
on Mittwoch, 6. Juli 2011, Yamaban wrote:
On Wed, 6 Jul 2011 09:00, Andreas Jaeger <aj@...> wrote:
- systemd would not ship any preset file by default (and probably not even the directory), this is left to distributions.
To NOT include the preset dir (/lib/systemd/system.preset/) in the systemd-package is not a good decision in terms of foresight.
If you include the dir in systemd, you make it clear where it belongs to, and make sure it has the needed ownership and rights.
ACK, but...
In rpm-terms: mark it as config-dir.
NACK on marking it as config dir. /lib/systemd/system.preset is only filled by rpms, nothing should be manually changed there.
For manual changes/overrides, there will be /etc/systemd/system.preset/ (this directory should also be created by the systemd package).
Regards,
Christian Boltz
Thanks for the insight.
What I (really) meant was to include BOTH dirs in the systemd package, the /lib/... as 'normal' dir and the /etc/... as 'config' dir.
Well, a directory is never flagged as "config dir", its content is (flagging a dir as %config is just telling rpm to own the directory and flag all files in it as %config). Anyway, I agree we should package both directories by default in our systemd package. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
<snip>
More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this:
<snip> disable avahi-daemon.service enable cups.service disable * </snip>
Then, we'd add a new command to "systemctl" called "systemctl preset". It would be equivalent to a "systemctl enable" if the unit file passed is listed in any of the preset files on lines prefixed with "enable", or be like a "systemctl disable" if it is listed with a prefix of "disable". Simple globbing would be supported. If no entry is found "systemctl preset" would be synonymous with "systemctl enable".
Generally I think this is a good idea, although the approach appears a bit simplistic and stuffing everything into one directory is probably not so great either. In another response there was mention of /etc/systemd to separate configurations, that's a step in the right direction. Still there would need to be some precedence rules if there are multiple files. For example if I have 3 files, a.preset, b.preset, and c.preset as follows: a.preset enable cups.service b.preset disable cups.service c.preset enable cups.service Is the service now enabled or disabled, probably depends on the processing order. But alpha sorting would not be a good choice as that is obviously locale specific and then has the potential of changing the behavior of the system as far as running services is concerned just based on the locale, that's just not correct. It appears that maybe having files named for services would be more intuitive to users, therefore one would have a cups.preset file as follows: cups.preset enable to enable or cups.preset disable to disable the service. Yes, from an implementation point of view this is more cumbersome and potentially requires the reading of many more files. Also this would make implementation of a default rule such as "disable all" more difficult. Another option would be to consider only two files, enable.preset and disable.preset. Enabled services are listed in enable.preset, disabled services are listed in disable.preset. The default rule can then be that enable wins, i.e. if a service is listed in both files it is enabled. Using the approach with only 2 files would allow easy implementation of default rules such as "disable all" an precedence is easy to explain. One could also consider making the precedence configurable, but then we'll get back into one distributions precedence is this and another's is that, which is not desirable. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert@suse.com rschweikert@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Robert Schweikert <rschweikert@suse.com> [07-06-11 15:29]:
Another option would be to consider only two files, enable.preset and disable.preset. Enabled services are listed in enable.preset, disabled services are listed in disable.preset. The default rule can then be that enable wins, i.e. if a service is listed in both files it is enabled. Using the approach with only 2 files would allow easy implementation of default rules such as "disable all" an precedence is easy to explain. One could also consider making the precedence configurable, but then we'll get back into one distributions precedence is this and another's is that, which is not desirable.
I would prefer precedence by order in a single file rather than multiple files, ie: disable-all enable cups.service enable ssh.service enable pop.service ... and also the reverse: enable-all disable cups.service ... -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday, July 06, 2011 21:28:21 Robert Schweikert wrote:
<snip>
More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this:
<snip> disable avahi-daemon.service enable cups.service disable * </snip>
Then, we'd add a new command to "systemctl" called "systemctl preset". It would be equivalent to a "systemctl enable" if the unit file passed is listed in any of the preset files on lines prefixed with "enable", or be like a "systemctl disable" if it is listed with a prefix of "disable". Simple globbing would be supported. If no entry is found "systemctl preset" would be synonymous with "systemctl enable".
Generally I think this is a good idea, although the approach appears a bit simplistic and stuffing everything into one directory is probably not so great either.
In another response there was mention of /etc/systemd to separate configurations, that's a step in the right direction. Still there would need to be some precedence rules if there are multiple files. For example if I have 3 files, a.preset, b.preset, and c.preset as follows:
The order is alphabetically if there are several files, like udev does it today. So, I guess we add a 99.openSUSE rule that does "disable *" as the last one.
a.preset enable cups.service
b.preset disable cups.service
c.preset enable cups.service
Is the service now enabled or disabled, probably depends on the processing order. But alpha sorting would not be a good choice as that is obviously locale specific and then has the potential of changing the behavior of the system as far as running services is concerned just based on the locale, that's just not correct.
The locale systemd runs under is the C locale - and if you use numbers, everything is fine.
It appears that maybe having files named for services would be more intuitive to users, therefore one would have a cups.preset file as follows:
cups.preset enable
to enable or
cups.preset disable
to disable the service. Yes, from an implementation point of view this is more cumbersome and potentially requires the reading of many more files. Also this would make implementation of a default rule such as "disable all" more difficult.
I don't understand what you're getting at.
Another option would be to consider only two files, enable.preset and disable.preset. Enabled services are listed in enable.preset, disabled services are listed in disable.preset. The default rule can then be that enable wins, i.e. if a service is listed in both files it is enabled. Using the approach with only 2 files would allow easy implementation of default rules such as "disable all" an precedence is easy to explain. One could also consider making the precedence configurable, but then we'll get back into one distributions precedence is this and another's is that, which is not desirable.
This is exactly distribution specific files. This will allow a vendor to ship different preset rpm packges (that might conflict with each other), e.g. a server one, a desktop one, a paranoia one... The precedence is defined, Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 07/07/2011 03:33 AM, Andreas Jaeger wrote:
On Wednesday, July 06, 2011 21:28:21 Robert Schweikert wrote:
<snip>
More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this:
<snip> disable avahi-daemon.service enable cups.service disable * </snip>
Then, we'd add a new command to "systemctl" called "systemctl preset". It would be equivalent to a "systemctl enable" if the unit file passed is listed in any of the preset files on lines prefixed with "enable", or be like a "systemctl disable" if it is listed with a prefix of "disable". Simple globbing would be supported. If no entry is found "systemctl preset" would be synonymous with "systemctl enable".
Generally I think this is a good idea, although the approach appears a bit simplistic and stuffing everything into one directory is probably not so great either.
In another response there was mention of /etc/systemd to separate configurations, that's a step in the right direction. Still there would need to be some precedence rules if there are multiple files. For example if I have 3 files, a.preset, b.preset, and c.preset as follows:
The order is alphabetically if there are several files, like udev does it today.
But for udev the order is less critical
So, I guess we add a 99.openSUSE rule that does "disable *" as the last one.
a.preset enable cups.service
b.preset disable cups.service
c.preset enable cups.service
Is the service now enabled or disabled, probably depends on the processing order. But alpha sorting would not be a good choice as that is obviously locale specific and then has the potential of changing the behavior of the system as far as running services is concerned just based on the locale, that's just not correct.
The locale systemd runs under is the C locale - and if you use numbers, everything is fine.
OK, did not know that and was not part of the original message. Well, using numbers works, still leaves one parsing all files for a specific service and then figuring out which one is processed last and wins. Allowing only one file or enable/disable pair of files makes that task a lot easier. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Freitag, 8. Juli 2011, Robert Schweikert wrote:
OK, did not know that and was not part of the original message. Well, using numbers works, still leaves one parsing all files for a specific service and then figuring out which one is processed last and wins. Allowing only one file or enable/disable pair of files makes that task a lot easier.
There is another way that can even avoid reading file contents ;-) I propose to use two subdirectories "enabled" and "disabled", and then just put empty files there, with filename = service name. In other words: "touch disabled/cupsd.service" would mean cupsd is disabled by default, and "touch enabled/sshd.service" would enable sshd by default. The default behaviour (if there is no service-specific default set) could also stored with this method - just "touch enabled/DEFAULT". Advantages of this method: - you know exactly which files you have to check for a service - just check for disabled/$service_name and enabled/$service_name. - getting a full list for all services should be fast because you only have to read the content of two directories, not any file content. - easy to handle in packaging - you'll never have any problems with invalid syntax inside the config files ;-)) - you'll never get headache with file ordering The only thing my proposal doesn't solve is if enabled or disabled should win if both exist - but this issue exists in all proposals I've seen until now. It's probably something that should be (or already is) hardcoded in systemd. Regards, Christian Boltz -- What are you doing?!? The message is over, GO AWAY! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 8 July 2011 18:31, Christian Boltz <opensuse@cboltz.de> wrote:
on Freitag, 8. Juli 2011, Robert Schweikert wrote:
OK, did not know that and was not part of the original message. Well, using numbers works, still leaves one parsing all files for a specific service and then figuring out which one is processed last and wins. Allowing only one file or enable/disable pair of files makes that task a lot easier.
There is another way that can even avoid reading file contents ;-)
I propose to use two subdirectories "enabled" and "disabled", and then just put empty files there, with filename = service name.
In other words: "touch disabled/cupsd.service" would mean cupsd is disabled by default, and "touch enabled/sshd.service" would enable sshd by default.
The default behaviour (if there is no service-specific default set) could also stored with this method - just "touch enabled/DEFAULT".
Advantages of this method: - you know exactly which files you have to check for a service - just check for disabled/$service_name and enabled/$service_name.
That seems much neater! I prefer that suggestion to all the others so far. If it's a flag, then let's treat it like one, no parsing, no syntax errors etc
The only thing my proposal doesn't solve is if enabled or disabled should win if both exist
Outlaw it! Simply mv {en,dis}abled/foo.service and mv {dis,en}abled/foo.service, and rm a redundant option that agrees with the system default. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 8 July 2011 20:16, Rob OpenSuSE <rob.opensuse.linux@gmail.com> wrote:
On 8 July 2011 18:31, Christian Boltz <opensuse@cboltz.de> wrote:
on Freitag, 8. Juli 2011, Robert Schweikert wrote:
Advantages of this method: - you know exactly which files you have to check for a service - just check for disabled/$service_name and enabled/$service_name.
That seems much neater! I prefer that suggestion to all the others so far. If it's a flag, then let's treat it like one, no parsing, no syntax errors etc
The only thing my proposal doesn't solve is if enabled or disabled should win if both exist
Outlaw it! Simply mv {en,dis}abled/foo.service and mv {dis,en}abled/foo.service, and rm a redundant option that agrees with the system default.
Actually even simpler would be to say "everyone has a package manager", so we don't need to worry about configurable distro policy. The default is simply service disabled. The package management, is responsible to enable service with flag on a distro with that policy on install. As a courtesly to sysadmin, package management documents an installed but disabled service. If there's flags for both enabled & disabled, then disabled wins, rm the enabled flag by Lennarts laziness principal "if that's broken then evenutally someone will notice and come along to fix it for us". That allows global enabledment by the unwise, with mv "disabled/*.service enabled". The wise can, temporarily disable by "mv enabled off-maintenance", then re-enable later by "mv off-maintenace enabled" again. It's easy to undo the actions of the unwise, by "mv enabled/*.service disabled" and then re-enable the wanted services/ "echo *abled/*.service" documents what's on & off. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 07/08/2011 03:16 PM, Rob OpenSuSE wrote:
On 8 July 2011 18:31, Christian Boltz<opensuse@cboltz.de> wrote:
on Freitag, 8. Juli 2011, Robert Schweikert wrote:
OK, did not know that and was not part of the original message. Well, using numbers works, still leaves one parsing all files for a specific service and then figuring out which one is processed last and wins. Allowing only one file or enable/disable pair of files makes that task a lot easier.
There is another way that can even avoid reading file contents ;-)
I propose to use two subdirectories "enabled" and "disabled", and then just put empty files there, with filename = service name.
In other words: "touch disabled/cupsd.service" would mean cupsd is disabled by default, and "touch enabled/sshd.service" would enable sshd by default.
The default behaviour (if there is no service-specific default set) could also stored with this method - just "touch enabled/DEFAULT".
Advantages of this method: - you know exactly which files you have to check for a service - just check for disabled/$service_name and enabled/$service_name.
That seems much neater! I prefer that suggestion to all the others so far. If it's a flag, then let's treat it like one, no parsing, no syntax errors etc
The only thing my proposal doesn't solve is if enabled or disabled should win if both exist
Outlaw it! Simply mv {en,dis}abled/foo.service and mv {dis,en}abled/foo.service, and rm a redundant option that agrees with the system default.
Not sure how you would set a default of disable all or enable all, create a file "all" or "*" in the enable or disable directory? Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 8 July 2011 21:04, Robert Schweikert <rjschwei@suse.com> wrote:
Outlaw it! Simply mv {en,dis}abled/foo.service and mv {dis,en}abled/foo.service, and rm a redundant option that agrees with the system default.
Not sure how you would set a default of disable all or enable all, create a file "all" or "*" in the enable or disable directory?
Packages can simply look for a "install-defaults-on" flag which is at the directory level NOT at file *.service level. services/ enabled/ foo.service bar.service disabled/ boring.service tricky-to-configure.service install-defaults-on If you know disable is default, then removing (creating) that flag, allows local change to distro policy. With unlink & rename having filesystem guarantees, the only inconsistency is the configuration error of : enabled/foo.service disabled/foo.service Which one resolves by unlinking the enabled/foo.service on basis disabling is more principalled. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday, July 08, 2011 19:31:07 Christian Boltz wrote:
Hello,
on Freitag, 8. Juli 2011, Robert Schweikert wrote:
OK, did not know that and was not part of the original message. Well, using numbers works, still leaves one parsing all files for a specific service and then figuring out which one is processed last and wins. Allowing only one file or enable/disable pair of files makes that task a lot easier.
There is another way that can even avoid reading file contents ;-)
I propose to use two subdirectories "enabled" and "disabled", and then just put empty files there, with filename = service name.
SystemD has already the enabled directory. The proposal we're discussing here is the proposal on how to define which service to install at a new installation.
In other words: "touch disabled/cupsd.service" would mean cupsd is disabled by default, and "touch enabled/sshd.service" would enable sshd by default.
The default behaviour (if there is no service-specific default set) could also stored with this method - just "touch enabled/DEFAULT".
Advantages of this method: - you know exactly which files you have to check for a service - just check for disabled/$service_name and enabled/$service_name. - getting a full list for all services should be fast because you only have to read the content of two directories, not any file content. - easy to handle in packaging - you'll never have any problems with invalid syntax inside the config files ;-)) - you'll never get headache with file ordering
You could do exactly the same with the other proposal. Just have a single file for each service 01_ssh.service with enable/disable ssh in it - and the 99_default file.
The only thing my proposal doesn't solve is if enabled or disabled should win if both exist - but this issue exists in all proposals I've seen until now. It's probably something that should be (or already is) hardcoded in systemd.
Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11 July 2011 11:56, Andreas Jaeger <aj@suse.com> wrote:
On Friday, July 08, 2011 19:31:07 Christian Boltz wrote:
You could do exactly the same with the other proposal.
Just have a single file for each service 01_ssh.service with enable/disable ssh in it - and the 99_default file.
The only thing my proposal doesn't solve is if enabled or disabled should win if both exist - but this issue exists in all proposals I've seen until now. It's probably something that should be (or already is) hardcoded in systemd.
Much friendly to the sysadmin to work with list of files in directory, not look inside file. Means less code & more efficient GUI program to "echo */*.service | sort". Disabled is logical choice, it's far safer to have a "failed service" than one accidentally running, if something is broke it gets fixed; something running that should not be, or a service accidentally started can have disproportionately expensive consequences. Files have same issue as 2 directory flag solution, one can write enabled & disabled in the file, so it's same configuration error as having directory entries (zero byte files) in both enabled & disabled. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday, July 11, 2011 15:59:03 Rob OpenSuSE wrote:
On 11 July 2011 11:56, Andreas Jaeger <aj@suse.com> wrote:
On Friday, July 08, 2011 19:31:07 Christian Boltz wrote:
You could do exactly the same with the other proposal.
Just have a single file for each service 01_ssh.service with enable/disable ssh in it - and the 99_default file.
The only thing my proposal doesn't solve is if enabled or disabled should win if both exist - but this issue exists in all proposals I've seen until now. It's probably something that should be (or already is) hardcoded in systemd.
Much friendly to the sysadmin to work with list of files in directory, not look inside file. Means less code & more efficient GUI program to "echo */*.service | sort".
We're not talking about the sysadmin in the proposal (at least not directly)! The proposal is for distributors how they will configure the system - to define which services are run by default and which not. The sysadmin will configure the system starting from the preconfiguration with systemctl. No need for the admin to learn about all this magic ;) Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 07/11/2011 10:09 AM, Andreas Jaeger wrote:
On Monday, July 11, 2011 15:59:03 Rob OpenSuSE wrote:
On 11 July 2011 11:56, Andreas Jaeger<aj@suse.com> wrote:
On Friday, July 08, 2011 19:31:07 Christian Boltz wrote:
You could do exactly the same with the other proposal.
Just have a single file for each service 01_ssh.service with enable/disable ssh in it - and the 99_default file.
The only thing my proposal doesn't solve is if enabled or disabled should win if both exist - but this issue exists in all proposals I've seen until now. It's probably something that should be (or already is) hardcoded in systemd.
Much friendly to the sysadmin to work with list of files in directory, not look inside file. Means less code& more efficient GUI program to "echo */*.service | sort".
We're not talking about the sysadmin in the proposal (at least not directly)!
The proposal is for distributors how they will configure the system - to define which services are run by default and which not.
Understood, but I think at least some of the things that were proposed in this thread (although I am not sure we reached agreement on the preferred way) are not possible with the upstream proposal/implementation. Therefore, we should get a consensus on what we would prefer for openSUSE, if that preferred method is not possible in the current systemd implementation someone (possibly AJ) should take our concerns back upstream and get feedback. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday, July 11, 2011 16:50:57 Robert Schweikert wrote:
Understood, but I think at least some of the things that were proposed in this thread (although I am not sure we reached agreement on the preferred way) are not possible with the upstream proposal/implementation. Therefore, we should get a consensus on what we would prefer for openSUSE, if that preferred method is not possible in the current systemd implementation someone (possibly AJ) should take our concerns back upstream and get feedback.
Robert, in this case I missed something. I haven't seen anything that could not be done with the proposal from upstream - what I noticed were some open questions on how things get done and some alternative proposals where I did not see any advantages to the proposal. So, this I missed a bit, could you point out, what I missed, please (a URL to the archive with a comment would be fine)? I'm happily talking with upstream. So, please help me to clear the different perception. Thanks, Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11 July 2011 16:00, Andreas Jaeger <aj@suse.com> wrote:
On Monday, July 11, 2011 16:50:57 Robert Schweikert wrote:
Understood, but I think at least some of the things that were proposed in this thread (although I am not sure we reached agreement on the preferred way) are not possible with the upstream proposal/implementation. Therefore, we should get a consensus on what we would prefer for openSUSE, if that preferred method is not possible in the current systemd implementation someone (possibly AJ) should take our concerns back upstream and get feedback.
Robert, in this case I missed something. I haven't seen anything that could not be done with the proposal from upstream - what I noticed were some open questions on how things get done and some alternative proposals where I did not see any advantages to the proposal.
So, this I missed a bit, could you point out, what I missed, please (a URL to the archive with a comment would be fine)?
Sure earlier on in this thread... On 6 July 2011 12:38, Andreas Jaeger <aj@suse.com> wrote:
On Wednesday, July 06, 2011 13:27:16 Patrick Shanahan wrote:
* Andreas Jaeger <aj@suse.de> [07-06-11 03:03]:
I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers,
Andreas
---------- Forwarded Message ----------
Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering <lennart@poettering.net> To: systemd Mailing List <systemd-devel@lists.freedesktop.org>
...
Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas?
Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own.
sounds like a plan
since it will be default-enabled, a provision should exist to include a preset default-disabled so it is not necessary to singularly disable every unwanted service that is installed.
disable all enable 1, 2, 3
Yeah, that works (with a different syntax ;).
I expect that openSUSE to ship a default that reflects what we do today: - by default disable everything - enable a few services
The proposal supports this. The nice thing is that it also allows different profiles, e.g. a server or a desktop profile - or a paranoia one ;) - that can be implemented via separate packages without touching the service packages itself,
That's messages previous in thread. 1) Feedback is asked for 2) Suggestion about text file contents with lines like "enable, disable" which create ordering problems. Avoiding that file parsing is neater and simpler, and rules out the questions asked. The "preset directory" concept is a good one. Hope that answers the question, you just asked me. I saw a simple but powerful suggestion that was better than the others. May be they prefer global enable default, but so long as it's easy to ship with disable default, no problem. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday, July 11, 2011 17:15:20 Rob OpenSuSE wrote:
1) Feedback is asked for
Yeah, I know I did ;)
2) Suggestion about text file contents with lines like "enable, disable" which create ordering problems.
I don't see an ordering problem! Where do you see it?
Avoiding that file parsing is neater and simpler, and rules out the questions asked. The "preset directory" concept is a good one.
You mean the proposal by Christian Boltz? Ok, I can bring that upstream as alternative implementation - I don't see that it solves a technical problem that the proposal does not but it's indeed a different implementation of solving the problems.
Hope that answers the question, you just asked me. I saw a simple but powerful suggestion that was better than the others. May be they prefer global enable default, but so long as it's easy to ship with disable default, no problem.
Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11 July 2011 16:21, Andreas Jaeger <aj@suse.com> wrote:
On Monday, July 11, 2011 17:15:20 Rob OpenSuSE wrote:
2) Suggestion about text file contents with lines like "enable, disable" which create ordering problems.
I don't see an ordering problem! Where do you see it?
People were asking questions like, what supercedes what if in file it's both enabled & disabled etc etc. The discussion looked more and more compicated to me, with some intricate proposals with many levels, or involving file naming conventions; even character set was considered, hence the "numbering" rather reminscient (ironically) of S10*, S20* & K90*, K80* examples in current /etc/init.d script links.. Either single file to check, or simple flags in 2 directories are both workable solutions. I realise if it were formal proposal, that a better presented worked out alternative would have been better. It was simply that I saw "beauty" in minimalist simplicity of making flags flags and the useability of such is very obvious to me. What would be horrible is many files, with flags in them like "enable", "disable". The inherent disadvantage with flags in packages is they then own their defaults, where they differ from distro "global" policy for some good reason. It may not matter, but there's not some central point with overview of which package does what, unless it's collated. They can however respect the site global policy by checking for prescence of local "global" over-ride flag, which could for example in openSUSE, SLE & Fedora be set by default to enforce the "all off" on install policy quite neatly. I just hope the final solution, has simpler rules easy to understand that are simple to remember, to avoid confusion or mandate use of GUI for overview. Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday, July 11, 2011 19:39:40 Rob OpenSuSE wrote:
On 11 July 2011 16:21, Andreas Jaeger <aj@suse.com> wrote:
On Monday, July 11, 2011 17:15:20 Rob OpenSuSE wrote:
2) Suggestion about text file contents with lines like "enable, disable" which create ordering problems.
I don't see an ordering problem! Where do you see it?
People were asking questions like, what supercedes what if in file it's both enabled & disabled etc etc. The discussion looked more and more compicated to me, with some intricate proposals with many levels, or involving file naming conventions; even character set was considered, hence the "numbering" rather reminscient (ironically) of S10*, S20* & K90*, K80* examples in current /etc/init.d script links..
I expect that the default openSUSE installation will have just two or three files: 01_enable_openSUSE that contains something like enable nscd.service enable unscd.service enable avahi.service ... 02_enable_ssh (if configured at startup) enable ssh.service 99_default_openSUSE disable * So, that's really not that complicated in actual usage.
Either single file to check, or simple flags in 2 directories are both workable solutions.
I brought it upstream and here's their answer: http://lists.freedesktop.org/archives/systemd-devel/2011-July/002907.html
I realise if it were formal proposal, that a better presented worked out alternative would have been better. It was simply that I saw "beauty" in minimalist simplicity of making flags flags and the useability of such is very obvious to me.
Read the response above, they have thought of this. If you feel strongly about this, then please continue discussing it on the systemd-devel mailing list.
What would be horrible is many files, with flags in them like "enable", "disable".
We won't have that.
The inherent disadvantage with flags in packages is they then own their defaults, where they differ from distro "global" policy for some good reason. It may not matter, but there's not some central point with overview of which package does what, unless it's collated. They can however respect the site global policy by checking for prescence of local "global" over-ride flag, which could for example in openSUSE, SLE & Fedora be set by default to enforce the "all off" on install policy quite neatly.
We don't want flags in packages - we want a single "openSUSE-default-services" package or perhaps one package for desktop usage, one for server usage. The beauty of this is that it's not in the package itself but in a meta package!
I just hope the final solution, has simpler rules easy to understand that are simple to remember, to avoid confusion or mandate use of GUI for overview.
See above, it's easy enough in practice IMO, Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 07/11/2011 11:00 AM, Andreas Jaeger wrote:
On Monday, July 11, 2011 16:50:57 Robert Schweikert wrote:
Understood, but I think at least some of the things that were proposed in this thread (although I am not sure we reached agreement on the preferred way) are not possible with the upstream proposal/implementation. Therefore, we should get a consensus on what we would prefer for openSUSE, if that preferred method is not possible in the current systemd implementation someone (possibly AJ) should take our concerns back upstream and get feedback.
Robert, in this case I missed something. I haven't seen anything that could not be done with the proposal from upstream - what I noticed were some open questions on how things get done and some alternative proposals where I did not see any advantages to the proposal.
My understanding is that the current upstream proposal/implementation handles the following case: Multiple files in /etc/systemd/system.preset and /lib/systemd/system.preset each file would be parsed and the expected content is: <snip> disable avahi-daemon.service enable cups.service disable * </snip> From original post: http://lists.opensuse.org/opensuse-packaging/2011-07/msg00030.html Then I made two proposal, although I more or less talked myself out of one of them in: http://lists.opensuse.org/opensuse-packaging/2011-07/msg00041.html Proposal 1: Have one file per service with the content of enable/disable as appropriate, this makes a "disable all by default" policy tedious to implement. Proposal 2: Allow only 2 files, enable.preset and disable.preset each file would list the service that is being enabled or disabled. In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00043.html Patrick proposed that there would only be one file that lists all services and enables/disables them. Proposal 3: Only one file (decide on name) is supported to enable/disable services In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00053.html Christian proposed to have subdirectories named enable and disable and have empty files for each service in the enable or disable subdirectories. Proposal 4: Create subdirectories enable/disable and have empty files as indicators whether a service should be enabled or disabled. In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00055.html, Rob proposed a modified version of proposal 4. In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00063.html you AJ mention that systemd already has an enable directory, something that was not part of the original message posted. Based on the original message posted it appears to me that upstream modifications would be necessary for proposals 2, 3, 4, and 4a. However, the upstream implementation my be more flexible than is obvious from the original post. IMHO we should find consensus for the preferred approach for openSUSE, (1, 2, 3, 4, or 4a) and then double check with the capabilities of the upstream proposal/implementation. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday, July 11, 2011 17:43:41 Robert Schweikert wrote:
On 07/11/2011 11:00 AM, Andreas Jaeger wrote:
On Monday, July 11, 2011 16:50:57 Robert Schweikert wrote:
Understood, but I think at least some of the things that were proposed in this thread (although I am not sure we reached agreement on the preferred way) are not possible with the upstream proposal/implementation. Therefore, we should get a consensus on what we would prefer for openSUSE, if that preferred method is not possible in the current systemd implementation someone (possibly AJ) should take our concerns back upstream and get feedback.
Robert, in this case I missed something. I haven't seen anything that could not be done with the proposal from upstream - what I noticed were some open questions on how things get done and some alternative proposals where I did not see any advantages to the proposal.
My understanding is that the current upstream proposal/implementation handles the following case:
Multiple files in /etc/systemd/system.preset and /lib/systemd/system.preset each file would be parsed and the expected content is:
<snip> disable avahi-daemon.service enable cups.service disable * </snip>
From original post: http://lists.opensuse.org/opensuse-packaging/2011-07/msg00030.html
Then I made two proposal, although I more or less talked myself out of one of them in: http://lists.opensuse.org/opensuse-packaging/2011-07/msg00041.html
Proposal 1: Have one file per service with the content of enable/disable as appropriate, this makes a "disable all by default" policy tedious to implement.
You could do this with the proposal, no problem at all.
Proposal 2: Allow only 2 files, enable.preset and disable.preset each file would list the service that is being enabled or disabled.
That's how we could do it for openSUSE.
In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00043.html Patrick proposed that there would only be one file that lists all services and enables/disables them.
Proposal 3: Only one file (decide on name) is supported to enable/disable services
In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00053.html Christian proposed to have subdirectories named enable and disable and have empty files for each service in the enable or disable subdirectories.
I've forwarded this upstream and here's the reply: http://lists.freedesktop.org/archives/systemd-devel/2011-July/002907.html
Proposal 4: Create subdirectories enable/disable and have empty files as indicators whether a service should be enabled or disabled.
In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00055.html, Rob proposed a modified version of proposal 4.
In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00063.html you AJ mention that systemd already has an enable directory, something that was not part of the original message posted. Based on the original message posted it appears to me that upstream modifications would be necessary for proposals 2, 3, 4, and 4a. However, the upstream implementation my be more flexible than is obvious from the original post.
IMHO we should find consensus for the preferred approach for openSUSE, (1, 2, 3, 4, or 4a) and then double check with the capabilities of the upstream proposal/implementation.
The upstream proposal is capable of doing everything we have discussed here, it's our choice how we use the framework they give us (proposals 1-3). Just 4 will not work - and those are proposals of a different implementation. It's a matter of taste which to prefer but the most important part why the upstream proposal is better is the following: If we have a file 02_enable_ssh, then an admin could just place a link to /dev/zero into the /etc/ preset directory and thus disable the 02_enable_ssh. Or override it with another content. This won't work with proposals 3 and 4. Robert, thanks for summarizing. My confusion might come from the fact that your proposals 1-3 are ways how to implement the upstream proposal and all work and 4 is an alternative proposal. I haven't seen a single use case - and that's what I had in mind - where the upstream proposal did not work at all, Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11 July 2011 15:09, Andreas Jaeger <aj@suse.com> wrote:
We're not talking about the sysadmin in the proposal (at least not directly)!
The proposal is for distributors how they will configure the system - to define which services are run by default and which not.
The sysadmin will configure the system starting from the preconfiguration with systemctl. No need for the admin to learn about all this magic ;)
Fine but why complicate things, does someone really want to write a file parser? If you just have Disable as default policy, and then have flag set by distro to make "enable" a global default, that's it done. It DOES matter to the sysadmin, because if it's : service-default-install-policy enabled disabled Once at a large installation, will going to want to change the policy most likely; for example if the admin have 2 distro's they'll want the SAME defaults! So the simpler you make it the better alround. What can be more efficient than 0 byte files for a flag in 2 directories? A runninug system does indeed have systctl etc, but I thought the was Distro policy, package polocy with some over-ride. It may seem different, to the running system, but it'd be likely quite easy to write scripts to do the systemctl to match the site policy, when one desired, if you define it nicely. Filesystem state has advantages, because there's good tools to replicate it. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday, July 11, 2011 16:56:39 Rob OpenSuSE wrote:
On 11 July 2011 15:09, Andreas Jaeger <aj@suse.com> wrote:
We're not talking about the sysadmin in the proposal (at least not directly)!
The proposal is for distributors how they will configure the system - to define which services are run by default and which not.
The sysadmin will configure the system starting from the preconfiguration with systemctl. No need for the admin to learn about all this magic ;)
Fine but why complicate things, does someone really want to write a file parser? If you just have Disable as default policy, and then have flag set by distro to make "enable" a global default, that's it done.
I assume that openSUSE will have "disable" as default. Debian might have "Enable" as default.
It DOES matter to the sysadmin, because if it's :
service-default-install-policy enabled disabled
Once at a large installation, will going to want to change the policy most likely; for example if the admin have 2 distro's they'll want the SAME defaults! So the simpler you make it the better alround.
From the original post: If an admin wants to manually change "enable-by-default" to "disable-by-default" (or vice versa) he could just drop his own file with "disable *" (or "enable *") into /etc/systemd/system.preset/ and override the vendor/spin settings. So, this is possible - as easy as what you describe. The difference is treating all options the same and allow pattern matching - vs. having an explicit file for defaults. It also means that all settings will be in one directory.
What can be more efficient than 0 byte files for a flag in 2 directories?
A runninug system does indeed have systctl etc, but I thought the was Distro policy, package polocy with some over-ride. It may seem different, to the running system, but it'd be likely quite easy to write scripts to do the systemctl to match the site policy, when one desired, if you define it nicely.
I don't understand what you're saying in the above paragraph, could you rephrase it, please?
Filesystem state has advantages, because there's good tools to replicate it.
The original proposal does it as well - doesn't it? Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, 11 Jul 2011 17:10, Andreas Jaeger <aj@...> wrote:
On Monday, July 11, 2011 16:56:39 Rob OpenSuSE wrote:
On 11 July 2011 15:09, Andreas Jaeger <aj@suse.com> wrote:
We're not talking about the sysadmin in the proposal (at least not directly)!
The proposal is for distributors how they will configure the system - to define which services are run by default and which not.
The sysadmin will configure the system starting from the preconfiguration with systemctl. No need for the admin to learn about all this magic ;)
Fine but why complicate things, does someone really want to write a file parser? If you just have Disable as default policy, and then have flag set by distro to make "enable" a global default, that's it done.
I assume that openSUSE will have "disable" as default. Debian might have "Enable" as default.
It DOES matter to the sysadmin, because if it's :
service-default-install-policy enabled disabled
Once at a large installation, will going to want to change the policy most likely; for example if the admin have 2 distro's they'll want the SAME defaults! So the simpler you make it the better alround.
From the original post: If an admin wants to manually change "enable-by-default" to "disable-by-default" (or vice versa) he could just drop his own file with "disable *" (or "enable *") into /etc/systemd/system.preset/ and override the vendor/spin settings.
So, this is possible - as easy as what you describe.
The difference is treating all options the same and allow pattern matching - vs. having an explicit file for defaults. It also means that all settings will be in one directory.
What can be more efficient than 0 byte files for a flag in 2 directories?
A runninug system does indeed have systctl etc, but I thought the was Distro policy, package polocy with some over-ride. It may seem different, to the running system, but it'd be likely quite easy to write scripts to do the systemctl to match the site policy, when one desired, if you define it nicely.
I don't understand what you're saying in the above paragraph, could you rephrase it, please?
Filesystem state has advantages, because there's good tools to replicate it.
The original proposal does it as well - doesn't it?
Not that easily. - A file with content has a syntax, charset, parsing. - A 'file' (zero-length) in a directory is just that. No syntax, parsing, charset (fixed to utf8 of the fs). Also do not underestimate trouble shooting of crashed systems. How does a Fedora user held his Debian friend without having a running reference system, or extened knowlege? In the case of zero-length-file-in-directory with added (en|dis)abled/DEFAULT - file the learning curve is nearly flat. Maybe the acceptance for systemd will get a rise with a "Oh, it's simple!" system of en- and disableing services, even without deeper knowledge of the 'new' init-system. For me at least a simple, easy to check config is a convincing argument for the change to systemd as 'my' init-system. Just as a two digit number plus a underscore before the name and you get even a simple and easy method of start order. Well, that's ust me, but I'm sure, for the user that seldom (only in cases of trouble) look under the hood/bonnet of his system a distro-independend, uniform, with just a glance understandable system of configuration is gold, and a argument for a system / distro. Ask yourself: would your grandmother/mother understood this system? Is it intuitive? How does it handle a filesystem-crash? Yes, AJ, you are under the hood daily. But most users not. This isn't meant personally, but it is a case of perspective. User versus Admin. A flat learning curve is a benefit for both, yes, but is esential for the user and thus the distro acceptance. A tip beyond: Would a simple README file in the level of the enable and disable directory to much to ask for, at least during the change-over from System-V to systemd. As content just a few lines about systemctl and it's most basic usage. To spare our self some support questions and give adopters a little extra help on the way. Cheers, Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11 July 2011 18:26, Yamaban <foerster@lisas.de> wrote:
Just as a two digit number plus a underscore before the name and you get even a simple and easy method of start order.
There's no daemon start order in systemd. systemd opens sockets, then starts the real daemon on demand when they're connected to. The whole advantage of systemd, is to avoid the inefficieciency and blocking inherent in defined ordering. The discussion likely confused, but it was enable or disable defaults per daemon, globally and how to override them, that was at issue. As each daemon likely has it's own config, the information seemed to be flags for on/off by default on an install, where some sane defaults (or simple configuration can be done during package install like Debian/Ubuntu try to). Sorry if I helped confuse you regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Yamaban, if you as an admin like to enable or disable a service, just run systemctl enable some.service or systemct disable some.service And I expect we will teach chkconfig about systemd as well. The proposal is for the initial configuration - which services will be enabled or not. Currently this happesn inside packages and you have *zero* influence on it - and now we move it from packages to a meta-package. Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday, July 08, 2011 14:55:04 Robert Schweikert wrote:
[...] OK, did not know that and was not part of the original message. Well, using numbers works, still leaves one parsing all files for a specific service and then figuring out which one is processed last and wins. Allowing only one file or enable/disable pair of files makes that task a lot easier.
With several files, it's easier to install files into the directory from different packages. Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (9)
-
Andreas Jaeger -
Andreas Jaeger -
Christian Boltz -
Frederic Crozat -
Patrick Shanahan -
Rob OpenSuSE -
Robert Schweikert -
Robert Schweikert -
Yamaban