systemd acceptance, packaging guidelines (was Re: systemd and changes)
Daniel J Walsh
dwalsh at redhat.com
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-----
More information about the devel
mailing list