From cee31aa399be7b45866d36992225a793d3cf0e92 Mon Sep 17 00:00:00 2001 From: pboy Date: Apr 26 2023 06:42:41 +0000 Subject: Continued migration from wiki to docs. --- diff --git a/wg/modules/ROOT/pages/archive/index.adoc b/wg/modules/ROOT/pages/archive/index.adoc index b93ef1d..55c2971 100644 --- a/wg/modules/ROOT/pages/archive/index.adoc +++ b/wg/modules/ROOT/pages/archive/index.adoc @@ -6,6 +6,24 @@ The Fedora Server Edition Working Group For reference and documentation of the Server Edition evolution process, we continue to provide older versions of various documents for review. -* xref:archive/product-requirements-document-2014.adoc[Initial version of the "Product Requirements Document" as of 2014] -* xref:archive/product-requirements-document-2021.adoc[Renwed 2021 version of the "Product Requirements Document"] + + +== Archived approved documents + +* xref:archive/product-requirements-document-2014.adoc["Product Requirements Document" (initial version 2014)] +* xref:archive/product-requirements-document-2021.adoc["Product Requirements Document" (renwed version 2021)] +* xref:archive/server-technical-specification-2014.adoc["Fedora Server Technical Specification" (initial version 2014)] + + +== Server related documents + + + +== Research + + +== Proposals + + +== Working group work plannings * WG work project xref:archive/initial-docs-plan.adoc[Buildup of a renewed documentation on Fedora Server specific topics] planning \ No newline at end of file diff --git a/wg/modules/ROOT/pages/archive/server-technical-specification-2014.adoc b/wg/modules/ROOT/pages/archive/server-technical-specification-2014.adoc new file mode 100644 index 0000000..248d117 --- /dev/null +++ b/wg/modules/ROOT/pages/archive/server-technical-specification-2014.adoc @@ -0,0 +1,174 @@ += Fedora Server Technical Specification +The Fedora Server Edition Working Group +:revdate: 2014-11-06 + +[NOTE] +==== +.*This is an approved document* +It was originally approved by the Server Working Group on January 17, 2014, and by FESCo on January 22, 2014. + +It is now *archived* and no longer valid. +==== + + +[abstract] +This document aims to describe the technical characteristics of the Fedora Server product in detail. This includes provided services and APIs, installed software, and the like. Some of the desired characteristics may not be entirely achievable in the first version of the Server product, and will be approximated. + +The content of this specification unavoidably overlaps with the work of the Base Working Group, and needs to be aligned with their deliverables. + +== Core Services and Features + +This section should describe the core services of the platform and their intended use. The items here should refer back to the xref:archive/product-requirements-document-2014.adoc[Product Requirements Document (2014)] for a functional justification. + +=== Supported Architectures and Install Media + +Fedora Server will run on and provide install media for i686, x86_64, and armv7hl servers. + +There will be two official install media for the Fedora Server + +* A network installation media (either a traditional netinst.iso or a boot.fedoraproject.org style) +* A local installation media providing the default package set as well as any featured roles that are meaningfully installed without a network connection. +** The local installation media will be allowed a maximum size to fit on a 4.0GB USB device. +** The local installation media can be pointed at network resources to make available a larger package set. + +=== File system + +The default file system type for Fedora Server installs will be XFS running atop LVM for all partitions except /boot. The /boot partition will remain a non-LVM partition due to technological limitations of the bootloader. + +File-system layout will be discussed with the Anaconda team and reasonable defaults will be selected based on a combination of the number of available, selected disks and the available memory on the system (for determining SWAP space). + +An option will be provided in the Fedora Server installer to enable disk encryption. + +=== Service management + +Systemd provides ways to control and monitor the activity and status of system services, resources they require, and the like. System services must provide systemd units to be included in the Fedora Server standard installation. See the link:++http://0pointer.de/public/systemd-man/systemd.unit.html++[systemd documentation]. + +=== Logging + +Fedora Server will store log files locally by default and will also support sending full log data to an external server to the maximum extent possible. For writing to logs, we recommend the syslog or journal APIs rather than managing application-specific log files. OpenLMI will provide an API for reading the logs. + +We will use rsyslog for forwarding data to a central server. The logs of programs using the recommended APIs will be locally stored in the journal database and automatically forwarded; other programs should include appropriate configuration for rsyslog such that their log output is included in the rsyslog-forwarded data stream. + +=== Networking + +Network devices and connections will be controlled by NetworkManager by default. Server Roles that may need to interact with the network configuration must do so through the public NetworkManager D-BUS API. + +=== Firewall + +A firewall in its default configuration may not interfere with the normal operation of programs installed by default. + +On a pristine system, the only open incoming ports are SSH and Cockpit. When Roles are deployed, they may elect to open one or more ports based on the most likely need. Roles *must* provide an interface that describes which ports they want open and which ones they currently have opened. The admin must be able to easily modify this configuration. + +Roles that open ports by default must have the set of ports approved by majority vote of the Server Working Group. + +If the user hasn't specified firewall status explicitly, interactive role deployment will inform the user whether the service's ports have been opened by default. It must be possible to query the API for the required state of the firewall to support the role, which can then be compared to the active firewalld state. + +The OpenLMI project will provide a public, external API to manage firewalld centrally. (This is not yet scheduled for a Fedora release, but is a medium-term plan.) + +=== SELinux + +SELinux will be enabled in enforcing mode, using the targeted policy. The Fedora Server standard install and all promoted Server Roles must operate in enforcing mode. + +=== Problem reporting + +Problems and error conditions (e.g. kernel oopses, Selinux AVCs, application crashes, OOM, disk errors) should all be reported in the systemd journal. + +Support for sending this information to a central place (like abrt does for crashes today) is mandatory. + +=== Account handling + +SSSD will provide the backing storage for identity management. The Fedora Server is expected to nearly always be configured for 'centrally-managed' user information; it must be possible to configure it to rely on a directory service for this information. Fedora Server will provide and support the realmd project for joining FreeIPA and Active Directory domains automatically. Interacting with other identity sources will remain a manual configuration effort. + +=== Software updates + +Software updates on the Fedora Server must be possible to perform either locally using command-line tools (e.g. yum/dnf) or centrally by common management systems (e.g. Puppet, Chef, Satellite, Spacewalk, OpenLMI). + +=== Miscellaneous system information + +System locale, timezone, hostname, etc. will be managed through the services provided by systemd for this purpose. +See developer documentation for +link:++http://www.freedesktop.org/wiki/Software/systemd/localed/++[localed], +link:++http://www.freedesktop.org/wiki/Software/systemd/timedated/++[timedated] and +link:++[http://www.freedesktop.org/wiki/Software/systemd/hostnamed/++[hostnamed]. + +=== Virtualization + +libvirt-daemon will be used to manage virtualization capabilities. + +=== Accessibility + +Accessibility support on the Fedora Server will be limited to devices supporting the vision-impaired on the console. + +Accessibility support in the optional graphical environment will be aligned with the Fedora Workstation offering. + +=== Input Methods + +The input method support for the Fedora Server console access will be limited to LOCALE support in the command shell. + +Input method support in the optional graphical console will be aligned with the Fedora Workstation offering. + +=== Graphics and Display Manager + +The Fedora Server does not mandate a graphical environment at this time. If the administrator elects to install a desktop, they should choose a display manager themselves at this time. + +=== Appearance + +The default user-experience for the Fedora Server will be the bash shell on the console and the Cockpit web management console. + +=== System Installer + +The desired installation experience for the Fedora Server product is to limit the pre-installation user interaction to the minimum. The storage configuration UI should provide a single sensible default and an alternative, fully customizable configuration UI. + +Package selection will be supplementary. There will be no option in the installer to install less than the Fedora Server standard installation. Options to install Fedora Server Roles will be provided, as well as a UI to install other software from the Fedora Project repositories. + +Fedora Server will expect to be the sole citizen on the system. Support for coexisting with other operating systems is not a goal. + +Fedora Server will use kickstart as implemented by pyKickstart and Anaconda as the unattended installation mechanism. + +== Server Roles + +The Server Roles listed below are approved to be worked on in the Fedora 21 timeframe. + +The public D-BUS API to support Server Roles will be provided from the Cockpit Project. + +=== Role Definition Requirements +Roles will be required to provide both a D-BUS API and a web management plugin for the Cockpit management console. During the development of the first few Fedora Server Roles, the Cockpit project will drive the effort of designing this interface. + +Roles will be required to support the following API: + +* A mechanism to install the packages necessary to deploy the role. This may include an API for specifying optional components at this time. +* A mechanism to deploy a role whose packages are installed on the system by providing the necessary information to provision it. +* A mechanism to install optional components of a role after deployment. +* A configuration interface to modify high-level configuration options. +* A query interface providing metadata information about the role (not all roles must implement all parts of this, bold lines are mandatory): +** *A list of system services provided by the role, as well as data about whether those services are currently running (or enabled, in the case of socket-activated services)* +** *A list of the ports that the role operates on, as well as data about whether those ports are currently firewalled.* +** *A mechanism to open and close ports that the role operates on for some or all interfaces.* +** *If the Role is designed to operate on the network, it should automatically open those ports (see firewall during deployment.* +** A list of files on the filesystem that should be included in a backup set. +** An interface to set processor affinity, memory limits, etc. where sensible. +** Whether the role is running in a container. + +=== Supported Roles === + +==== Domain Controller + +The Fedora Server Domain Controller Role will be provided by the FreeIPA project. + +This Server Role is a blocker for the release of Fedora Server in Fedora 21. + +==== Database Server + +The Fedora Server Database Server will be provided by the PostgreSQL project. + +This Server Role is a nice-to-have for the release of Fedora Server in Fedora 21. + + + +== Core Package list + +List the core packages of the product. This list includes all packages that will be shipping on the core media. This is the mandatory minimal list of packages that needs to be installed on a system at all times for it to qualify as a Fedora Server install. This package list will be the priority focus for QA and bug fixing. + +=== Package list + + \ No newline at end of file diff --git a/wg/modules/ROOT/pages/docs/key-services-ansible-support.adoc b/wg/modules/ROOT/pages/docs/key-services-ansible-support.adoc new file mode 100644 index 0000000..309ab31 --- /dev/null +++ b/wg/modules/ROOT/pages/docs/key-services-ansible-support.adoc @@ -0,0 +1,108 @@ += Facilitated deployment of key services by combining rpm and Ansible + +Goal is to explore *Ansible* to provide easy installation and pre-configuration for key services in Fedora Server Edition. It is all about improving, systematizing and simplifying its system management. + +This page is intended to organize and structure the discussion. It is work in progress, not documentation of finished procedures. + +It is intended to be uses as a kind of (simple) content federation tool. We specify items to discuss here, discuss on mailing list or IRC meetings and bring their results together here. + +== Use Cases – What do we want to achieve + +=== 1. Installation of (Java) Application Server - the Wildfly Example + +Specific stakeholders so far: pboy, jwhimpel + +==== Description + +Wildfly is an eminently important and widely used application on Fedora Server Edition. Unfortunately, experience has shown that building a wildfly rpm package is not feasible. This does not only apply to Fedora, but also to at least most, if not all other distributions. As a consequence, the system administrator not only has to perform the software configuration - which is already complex and extensive in itself - but also its installation, including the embedding into the server ''systemd'' runtime system. + +As a way out, many instructions for manual installation can be found, which follow different ways and installation systematics. Many are incomplete or even faulty and lead to system malfunctions. + +*Goal* is to ensure a systematic, reproduceable and smooth integration into the Fedora way of installing software. + +==== Tasks to Perform ==== + +* Installation of the appropriate Java version +* Installation of backend software, specifically a database (postgresql or an alternative) +* Deploying a systemd service configuration +* Download of Wildfly software from upstream +* Installation of Wildfly in an appropriate location +* Configure Wildfly as a standalone or domain service +* Managing updates +* Optionally connect Wildfly to a Web frontend (httpd) + +==== Implementation Notes + +* *Systemd Service*, could be a plain dedicated service created either via Ansible or as an rpm. Alternatively it could be a generic Java service addressable as jservice@wildfly, jservice@glassfish, etc. + +* *Software download*, one option is to provide a script that simple informs that an installation of the software is required to use it. it would be a similiar approach as the postgresql dbinit process. Another option is to provide a Ansible artifact that informs and asks for permission to download the software, alternatively to pick it up from a local storage, manually perpared by system administrator. + +* *Installation location*, generally _/opt_ would be appropriate. Another option to explore is to install wildfly as an unexpanded jar as a Java library file and inject links to /etc, /var/lib/webapps etc as java packages as tomcat would do. + +* An *Ansible role* for installing and configuring will be really ambitious. It has to ensure that all installations of this type follow the same principles and comply with the Fedora guidelines for installing Java software. + +* I would envision continuing using rpm packages (not coprs and not flatpacks) for basic software installation. I would envision a git-like repository maintained by the Fedora Server working group (along with other stakeholders) to provide the server-ansible-roles necessary to integrate all of the pieces together. The key to making all of this work is good, user-focused, up-to-date documentation on the wiki, web site and in the server-ansible-roles. + +==== Potential reasons for obstacles + +* Fedora policies (may) prohibit some steps or may require further adjustments + +==== Miscellaneous Notes + +* prebuilt containers as a stopgap option +** not everywhere a container is a good or even a feasible solution (administrative overhead, disposable strategy, additional workflow and build environment, etc.) + +=== 2. Installation of a complex service using different Fedora packages - the example Mail Service + +==== Description +A small site without an experienced Systems Administrator wishes to host their own email server. This would normally involve installing postfix, sendmail or some other Message Transfer Agent (MTA). It would also normally involve installing dovecot or some other Message Delivery Agent (MDA). While rpms exist for the above services, the rpms contain generic configuration files that require manual “tweaking” before the services will work together as one unit. + +One potential server-ansible-role might install the postfix rpm. Another server-ansible role might install the sendmail rpm. Yet another rpm might install the dovecot rpm. A yet-to-be-developed server-ansible-role might configure postfix and dovecot to work together. A second yet-to-be developed server-ansible-role might configure sendmail and dovecot to work together. + +The site may wish to only allow for secure transmissions between the MTA and the sending User Agent (UA) as well as between the MDA and the UA. That would involve installing the the certbot rpm, requesting the necessary certificates from the Letsencrypt CA, and configuring the MTA and MDA configuration files to provide secure transmissions. A server-ansible-role could do all of this assuming the MTA was postfix and another server-ansible-role could do all of this assuming the MTA was sendmail. + +The site may wish to implement Spamassassin, Clamav, DKIM, DMARC and SPF in a matter similar to that described above. + +Other possibilities include configuring the MTA and MDA to host multiple virtual domains and/or virtual users. This would require installing an RPM for a database of choice and making all the necessary configuration file changes required to integrate it into the sites MTA/MDA infrastructure. + +For a site considering migration from other OS’s to Fedora, completing this process could take days if not weeks. With all the old and outdated documentation on the web, it almost becomes a trial and error situation. With carefully crafted server-ansible-roles, it should be a matter of instructions on how to access the server-ansible-roles repository and providing well-documented defaults/main.yml and vars/main.yml files. The unfamiliar Systems Administrator then only needs to provide the site-specific values in the Ansible variables files. + +==== Miscellaneous Notes +* A mail service includes several different packages, e.g. Postfix, Dovecot, SpamAssassin, OpenDKIM, etc., which must be configured to work together. +* There are guides that often contain configuration instructions that do not apply to Fedora or packages for various reasons not available in Fedora +** *Goal* is to provide an easy way to a cross-package and coordinated configuration of a service. + +*Cons* + +* There are so many different possible Installation options +** We may need to develop different prototype use cases, each containing customization capabilities. + +== Linux System Roles + +There is a project that provides a collection of Ansible Playbooks for typical system administration tasks: +* https://linux-system-roles.github.io +* https://github.com/linux-system-roles +* https://ansible.github.io/workshops/exercises/ansible_rhel_90/6-system-roles/ + +Topics to discuss: + +. Do the scripts play well with Fedora Server? +. Do we want to encourage the use of those scripts and how? +. How can we make them (better) usable in Fedora Server? +. Can we use them as a kind of base library for more complex, cross-package services? +. What new system-roles can we provide? + +== Fedora Policy requirements + +Fedora policies impose requirements on artifacts that Fedora distributes. Obviously, some of the current rules are: + +* Helper rpms that only contain the systemd environment and an installation script do not comply with Fedora policy + +* Packaged Ansible roles, collections and things should be referencing packages and leverage Fedora content rather than external stuff +* Fedora containers as well should leverage Fedora content + +We need to investigate the regulations and analyze the possibilities they provide. + +== How to distribute / distribution options + +* downloadable from server-wg home page (??) \ No newline at end of file diff --git a/wg/modules/ROOT/pages/docs/server-technical-specification.adoc b/wg/modules/ROOT/pages/docs/server-technical-specification.adoc index 464c571..eb4a636 100644 --- a/wg/modules/ROOT/pages/docs/server-technical-specification.adoc +++ b/wg/modules/ROOT/pages/docs/server-technical-specification.adoc @@ -2,13 +2,13 @@ [NOTE] ==== -Updated document as finalized at the *Server Working Group IRC Meeting* on https://meetbot.fedoraproject.org/fedora-meeting/2022-08-17/fedora-server.2022-08-17-17.00.html[August 17, 2022] +.*This is an approved document* +Updated version as finalized at the *Server Working Group IRC Meeting* on https://meetbot.fedoraproject.org/fedora-meeting/2022-08-17/fedora-server.2022-08-17-17.00.html[August 17, 2022] ==== [abstract] -____ This document aims to describe the technical characteristics and properties of the Fedora Server Edition in detail. This includes provided services, installed software, and the like. It also defines characteristics and features that are not yet or not fully implemented in the current Fedora Server Edition release. -____ + == Preamble diff --git a/wg/modules/ROOT/pages/index.adoc b/wg/modules/ROOT/pages/index.adoc index 6455375..52047cb 100644 --- a/wg/modules/ROOT/pages/index.adoc +++ b/wg/modules/ROOT/pages/index.adoc @@ -34,9 +34,8 @@ Fedora Server Edition is an ecosystem ideal for creating and operating validated == Currently ongoing long term work projects -. https://fedoraproject.org/wiki/Server/Using_Ansible[Facilitated deployment of key services by combining rpm and Ansible] -≈ -. https://fedoraproject.org/wiki/Server/Off-Premise-Kickstart[Improved support for off-premise Kickstart and pxe installation] +. xref:docs/key-services-ansible-support.adoc[Facilitated deployment of key services by combining rpm and Ansible] +. Improved support for off-premise Kickstart and pxe installation . Revisiting defaults... filesystem/partitioning . Easy integration into multi-node environments with tools like Ansible diff --git a/wg/modules/ROOT/pages/wg-minutes-2023.adoc b/wg/modules/ROOT/pages/wg-minutes-2023.adoc index b79b6cd..f04bbf3 100644 --- a/wg/modules/ROOT/pages/wg-minutes-2023.adoc +++ b/wg/modules/ROOT/pages/wg-minutes-2023.adoc @@ -1,6 +1,6 @@ = Meeting Minutes 2023 -Stephen Daley, Peter Boy -:page-authors: {author} +Stephen Daley; Peter Boy +:page-authors: {author}, {author_2} :page-aliases: wg-minutes-current.adoc