On Thu, 2011-06-16 at 14:04 +0200, Will Stephenson wrote:
On Friday 10 Jun 2011 19:04:14 Frederic Crozat wrote:
For discussing / helping with systemd integration for Factory, please use opensuse-factory mailing list or go to #opensuse-factory IRC channel on Freenode.
We need your help to make sure openSUSE 12.1 will use systemd at 200% ;)
Ok, I took the time to read and re-read all of the systemd blogs, some man pages, and our wiki articles, so here are my 2 cents on the matter:
To systemd maintainers, and maintainers of our init scripts: 1) Our sysvinit scripts are configured by sourcing variables from /etc/sysconfig. This allows us to keep common init scripts over several distribution versions and releases, and allows YaST to modify the way services are run by modifying /etc/sysconfig files only.
systemd service files support environment variable substitution for some keys, eg ExecStart, and the values are obtained from single config files specified by absolute paths in EnvironmentFile keys. Is this sufficient to maintain the same configurability as we use now in init scripts?
We expect 'proper' services to have their own config files, and not let every distro invent their own options on top in some additional file. Most services work that way, and it's just good enough. In short, 'foo' should have a native /etc/foo/config instead of /etc/sysconfig/foo. That will be the same on any system, any Linux, any distro. Yast should be able to edit this file, if needed, not bring its own files. Some of the sysconfig options can be imported into the environment with the systemd service file. Some services which still rely on weird sysconfig options SUSE invented will need to be started by a shell script wrapper. In the future we want /etc/defaults and /etc/sysconfig, and all the other friends distros invented to die. :)
To systemd maintainers: 2) While I agree with systemd's performance goals and recognise the persuasive narrative for the socket activated design in the LP blog series, I hear that it additionally replaces other parts of userland. Massive uncertainty rules in my head about what those are and the wider effects of those changes.
As an example, http://lwn.net/Articles/441328/ mentions that there are plans to remove ConsoleKit and merge its functionality into a systemd helper daemon. What changes of this type to the runtime platform are implied by systemd that would affect eg a KDE session (other than https://bugzilla.novell.com/show_bug.cgi?id=655141) , and who is planning to do the work to adapt to those?
It's all optional for now. The 'systemd --user' part will land in the next weeks. It already kind of works. The session tracking is also already part of systemd proper and will land in the next weeks. It will include out-of-the box multi-seat setup, where USB graphic+keyboard+mouse+sound adapter plugged in, will create a new seat with a login manager running on it. Existing users can still pull-in the current ConsoleKit and don't need to switch now. The stuff will just run in parallel. For GNOME it is planned to switch gnome-session over to systemd bit-by-bit, but it will take its time until 'systemd --user' will be any harder requirement. It might just happen by the fact that people doing the work don't run non-systemd systems anymore. But stuff that works today should not stop working. It might just be, that in the background systemd is doing some stuff for sessions (like ConsoleKit) that is not used by anything.
To systemd maintainers, and everyone else, since I suspect the systemd guys are not omniscient: 3) What are the big gaps that it doesn't currently do, compared to sysvinit? I hear of things like encrypted LVM volumes not working being dismissed as unimportant.
Systemd supports LUKS volumes natively. It does not and probably will not support 'fake block devices' like lvm + md natively. It (or udev) might natively support btrfs in the future. "Fake block devices' need to proved their own 'device assembly' logic with scripts or systemd services. The current SYSV stuff should still work, or needs minor adaption to work with systemd.
I'll start you off with "password agents to do interactive things during service startup, eg openvpn passwords" (bnc675406): http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents
Someone needs to provide a password plugin for openvpn to async query passwords. With systemd, there is no way for any service to take over the console and synchronously ask questions. The services all start in a clean environment and fully detached. Apache has a nice and dead-simple way to to run a program to ask for a password for the SSL certs. Systemd's async password facility is easily plugged into that, guess openvpn should get something similar.
4) Are non-NetworkManager network configurations supported?
Sure, just as they are with SYSV. They can (and mostly do) implement the $network target with the same scripts they used in SYSV. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org