systemd acceptance, packaging guidelines (was Re: systemd and changes)

Tue Aug 24 13:44:25 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/24/2010 08:45 AM, Matthias Clasen wrote:
> On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote:
> 
> Hey Bill,
> 
> this is a very good initial list, this should make it very easy for QA
> to whip up a test plan for systemd. Some comments below.
> 
> 
>> BOOTUP
>> - System boots successfully to GUI, when configured.
>> - System boots successfully to text mode, when configured.
>> - System properly handles being passed [1-5], 'single', 'S', 's', '-s',
>>   booting to the appropriate 'runlevel' (0 and 6 can still work,
>>   but they're sort of pointless anyway) When booted in this manner,
>>   '5' will bring up a GUI, and '3' will not.
> 
> You mean 'being passed on the kernel cmdline', I assume ?
> Do we consider interactive boot essential (I think not) ?
> Should mention something about forced fsck, maybe.
> What about selinux relabeling ?
> 
>> SINGLE USER MODE
>> - Exiting single user mode properly returns to the default state.
>> - single-user mode output is correctly displayed on the console.
>>  
>> PLYMOUTH
>> - plymouth is shown on startup.
>> - plymouth is quit correctly.
>> - plymouth is shown on shutdown.
>> - 'esc' to show details still functions in plymouth.
>> - an equivalent to /var/log/boot.log still exists, and is populated
>>   (can be normal syslog)
>> - plymouth transition from grub -> boot -> X is seamless for KMS cards,
>>   similar to Fedora 13.
> 
> Note that this is currently broken (somewhere in X, not systemd's fault
> at all).
> 
>> RUNTIME TOOLS
>> - telinit [0123456] does the proper thing.
>> - the 'runlevel' command displays correct output if we are in a target
>>   that is aliased to a runlevel.
>> - 'halt' shuts down, but does not poweroff.
>> -- 'halt' supports -p, to power off.
>> - 'poweroff' shuts down, and powers off.
>> - 'reboot' shuts down and reboots.
>> - 'halt', 'poweroff', 'reboot' all support '-f', to force the action.
>> - 'halt', 'poweroff', 'reboot' all properly log to utmp, wtmp, and
>>   the audit layer.
>> - 'shutdown' shall support the following arguments in a compatible manner:
>>   'r', 'h', 'H', 'P', 'c', 'k', <time>.
>> - 'telinit' does not error when passed '[Qq]' (to reload its configuration)
>>   and '[Uu]' to re-exec itself. It can optionally make systemd do a similar
>>   action, if valid.
>> - init shall support a mechanism to re-exec itself to not cause dirty
>>   inodes on shutdown; initscripts will use this method on shutdown.
>> - the kbdrequest job currently in systemd will be disabled for final release.
>> - 'ctrl-alt-delete' will reboot the system.
> 
> Should include chkconfig here, probably ?
> 
>> PREFDM
>> - prefdm starts a configured display manager correctly.
>> - prefdm starts a installed display manager correctly without additional
>>   configuration.
>>
>> CONSOLEKIT
>> - ConsoleKit properly logs system start, stop, and restart.
>> - The ConsoleKit shutdown/reboot/halt methods work as expected.
>> SERIAL CONSOLES
>> - Booting with a primary serial console (via console=) automatically
>>   sets up a getty on the console, and sets up securetty to allow for root
>>   login.
>> - (optional) Booting with secondary serial consoles does the same.
>>
>> NON-SERIAL CONSOLES
>> - By default, 6 gettys will be started in text mode, on tty1-6. 5
>>   gettys will be started in GUI mode, on tty2-6.
>> - getty and X will not be started on the same tty.
>> - (optional) The number of ttys started can be configurable.
>>
>> ERROR HANDLING
>> - SELinux automatic relabelling will still function.
>> - fsck will still function.
>> - Dropping to an emergency shell in the case where either of these fails
>>   shall still function.
>>
>> SELINUX
>> - No AVCs from the init system in normal use.
>> - No AVCs when executing any of the cases specified here
>> - systemd shall still function if booted with selinux=0.
>>
>> PACKAGING
>> - Guidelines for packaging systemd units shall be formalized.
>> - The behavior when both systemd units and SysV services are present on
>>   the system shall be defined. This includes defined behavior when a
>>   service appears to be 'enabled' for SysV links while 'disabled' for
>>   systemd (and vice-versa).
>> - The syntax of systemd units shall be frozen for the release (all future
>>   releases? Some set number of releases?)
> 
> Can you clarify this a bit ? I assume what we want is that future
> systemd releases remain backwards compatible with systemd units of
> today.
> 
>> SERVICE HANDLING
>> - Running 'chkconfig <foo> <(null)|on|off>' on a service managed by systemd
>>   will return the correct code/perform an appropriate action.
>> - Running 'service <foo> <start|stop|...>' on a service managed by systemd
>>   will perform the appropriate action (via systemctl), and return 
>>   similar errors.
>> - Running '/etc/init.d/<foo> <start|stop|...>' will not break the systemd
>>   environment, while still performing the action specified, and shall return
>>   similar errors.
>>
>> GENERAL SANITY
>> - Booting a system shall achieve a similar result as booting in upstart:
>> -- The same set of services will be started.
> 
> I don't think this is a requirement on systemd, really. If we make
> changes to the default system configuration to not include a service in
> F14 that was included in F13, that is not a systemd problem. So, I think
> what you really mean here is: systemd will start all services that are
> configured to be included in the default install (and dependencies), but
> no others.
> 
>> -- The services shall function the same.
> 
> This is again not really much of a systemd requirement. At most, we
> should probably test that socket activation does not affect the
> functionality of services (ie that socket activation works as promised).
> Of course, this is only an issue if we actually have any
> socket-activated services in F14. 
> 
>> -- The same set of devices and filesystems shall be mounted.
>> -- The same set of devices and filesystems shall be fscked.
> 
> 'Same', compared to what ? I think this needs to be expanded to specify
> under what conditions filesystems were mounted/fscked in F13.
> 
>> ORDERING
>> - rc.local will run as the final service on bootup.
>> - gettys will not start until after rc.local.
> 
> These two seem contradictory, at first sight...
> 
>> - prefdm will start coincident to gettys (earlier?)
>>
>> ADMIN INTERFACE
>> - The files and paths used by systemd shall be frozen for future releases.
>> - The basic syntax of systemd commands shall be frozen for future releases.
>> - The syntax of systemd units shall be frozen for future releases.
> 
> Again, the best we can ask for is backwards compatibility, I think.
> 'Frozen' is entirely too strong for a 2 month old project.
> 
>> ASSORTED RANDOM CONFIGURATIONS
>> - The system shall properly function with:
>> -- encrypted /
>> -- encrypted non-/
>> -- nfs /
>> -- iSCSI /
>> -- LDAP user information
>> -- IPA/AD user information
>> -- NIS user information
>> -- ext* filesystems
>> -- btrfs filesystems
>> -- xfs filesystems
>>
>> ANY REMAINING UPSTART JOBS
>> - All packaged upstart jobs are modified to have some SysV or systemd-native
>>   equivalent.
>>
> 
> 

I would add security things.

Starting a service sends audit messages from the proper loginuid.
I am sure Steve Grub has lots of concerns here also.

Restarting or starting a service ends up transitioning to the proper
domain (Might be an SELinux domain.) directories, sock_files created by
systemd end up with the proper context and confined domains see the
remote socket as the proper label not, init_t.  For example if I setup
mysql to be autostarted by systemd then when apache connects to the
/var/run/mysql/socket it sees this socket labeled mysqld_var_run_t and
the remote end as mysqld_t.

I
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxzzLgACgkQrlYvE4MpobNWBgCaAqLDVqoHkviuVzJoReNHzqcB
fC0An2qpKppKGt/jIuoPL+Gmg0qK2huZ
=Yszw
-----END PGP SIGNATURE-----