Mailinglist Archive: opensuse-factory (710 mails)

< Previous Next >
Re: [opensuse-factory] The road to systemd for openSUSE 12.1
  • From: Kay Sievers <kay.sievers@xxxxxxx>
  • Date: Thu, 16 Jun 2011 15:09:31 +0200
  • Message-id: <1308229773.1547.39.camel@mop>
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
are run by modifying /etc/sysconfig files only.

systemd service files support environment variable substitution for some
eg ExecStart, and the values are obtained from single config files specified
by absolute paths in EnvironmentFile keys. Is this sufficient to maintain
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
narrative for the socket activated design in the LP blog series, I hear that
it additionally replaces other parts of userland. Massive uncertainty rules
my head about what those are and the wider effects of those changes.

As an example, mentions that there are plans
to remove ConsoleKit and merge its functionality into a systemd helper
What changes of this type to the runtime platform are implied by systemd that
would affect eg a KDE session (other than , 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?
hear of things like encrypted LVM volumes not working being dismissed as

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):

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.


To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
This Thread