-----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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
