From Fedora Project Wiki

< User:Adamwill
Revision as of 21:33, 26 June 2014 by Adamwill (talk | contribs) (add a criterion requiring kickstart user creation to work)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Scripted user creation

The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account.

References
  • Part of Server release criteria drafts, added after initial proposal
  • Test case: TODO

Remote authentication

It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain.

Non-interactive only OK

The install-time capability is not required to be interactive (i.e. it is acceptable for it to be possible by kickstart only).

No local account requirement

This criterion is understood to mandate that there must be no requirement for a local user account to be created during install or first boot of a Server system.

References

Post-install requirements

Expected installed system boot behavior

  • A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system.
  • Assuming no graphical desktop is installed, the installed system must boot to a state where it is possible to log in through at least one of the default virtual consoles.
Encrypted partitions

In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s).

User intervention

In all of the above cases, the boot should proceed without any unexpected user intervention being required.

System-specific bugs

System-specific bugs don't necessarily constitute an infringement of this criterion - for instance, if the system fails to boot because of a bug in the support some specific system's hardware, that is unlikely to constitute a violation unless the system is an extremely popular one. See Blocker_Bug_FAQ for more discussion of this.

Use for severe issues in applying updates

These criteria can be used to cover known severe issues in applying post-release updates. For instance, if there was a bug that meant the system would install and boot fine but would break as soon as the user ran 'yum update', that may well be covered by these criteria.

First boot utilities

On the first boot after installation, a utility for creating user accounts and other configuration may (may, not must) run prior to a log in screen appearing.

References

System log forwarding

It must be possible to forward system logs between two systems running the release, using rsyslog.

Details

This criterion assumes a working network connection between the machines, appropriate firewall configuration, and a fairly straightforward rsyslog configuration. A more exotic configuration failing is unlikely to be considered a violation of this criterion.

References

Firewall configuration

After system installation without explicit firewall configuration, the system firewall must be active on all non-loopback interfaces. The only ports which may be open to incoming traffic are port 22 (ssh), port XX (Cockpit web interface), and any ports associated with server Roles selected during installation. Supported install-time firewall configuration options must work correctly.

Install time configuration

To explain the last part of this criterion - it is possible to include firewall configuration options in a kickstart-driven installation, and the criterion requires that those options work as expected. The options considered to be 'supported' are those documented at Anaconda/Kickstart#firewall. The case of a conflict between role-specified and manually-specified firewall configuration is not considered to be covered by these criteria.

References

SELinux configuration

Unless explicitly specified otherwise, after system installation SELinux must be enabled and in enforcing mode.

References

Cockpit management interface

Unless explicitly specified otherwise, after system installation the Cockpit web management interface must be running and accessible on its default port (XX).

References

Server Role requirements

The requirements in this section are understood to cover the behaviour of both supported roles themselves and the server role framework they use. Supported roles are defined as the roles promoted as supported in the Fedora Server release under test.

Role deployment

It must be possible to deploy supported roles successfully both at initial deployment time (during installation, or via a tool running on first boot after install, or both) and post-install.

Successful deployment

"Successful" deployment consists of installing the correct set of default packages for the role, and performing initial configuration of the role, including appropriate firewall configuration for network-accessible roles.

References

Role service query

It must be possible to query supported roles for a list of services provided by the role, including information as to which are running and/or enabled.

References

Role firewall configuration

It must be possible to query supported roles for a list of network ports the role operates on, and whether those ports are firewalled. It must be possible to open and close these ports using the server role interface.

References

Role functional requirements

Supported roles must meet their functional requirements, as defined in their role specification documents.

References
Retrieved from "https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_server_release_criteria&oldid=380622"