--- title: Product Requirement Document comparison tags: Documentation, Fedora, Fedora server description: PRD current and proposal comparison for Fedora Server --- :::danger This document is outdated now and superseded by https://hackmd.io/@x3mboy/HyB92cVl_ This document is now for reference only. Don't edit or add any comments here! ::: # Product Requirement Document ## Fedora Server Update Proposal Current [Fedora Server Product Requirement Document](https://fedoraproject.org/wiki/Server/Product_Requirements_Document) / Sig: https://fedoraproject.org/wiki/SIGs/Server Current [IoT Product Requirement Document](https://docs.fedoraproject.org/en-US/iot/prd/) Current Cloud Sig: https://fedoraproject.org/wiki/Cloud_SIG **Editor's note in advance:** - The currend PRD obviously was created at a time when the differentiation into editions evolved. The consistent tenor is on what is to be achieved and intended. Now the consistent tenor must be proudly shifted to what is being offered and what it is useful for. - **Keep in mind and don’t be afraid:** as long as the current text is, the final version will not be longer than the current one. | Current Version | Update Proposal | | -------- | -------- | | **1. Document Purpose and Overview** </br> *1.1 What this document describes* | **1. Summary** | |This is the Product Requirements Document for the Fedora Server. It: </br></br> - Provides a high-level market overview of the infrastructure server market as it pertains to the Fedora Server; this includes items which may not be within our actual scope/ability to accomplish at the current time.</br></br> - Provides deeper understanding of the types of users who could use Fedora for their application and infrastructure needs. This includes describing their main day-to-day tasks, common problems, etc. The perspective here is not necessarily limited to system administrators, or developers, but a combination of many types of users and roles.</br></br> - Ties common issues and needs of potential users/consumers of the Fedora Server product to high-level product needs, from a "functional" standpoint.</br></br>This document does not dictate implementation details. The goals in this document will drive the continued implementation of this product.| This document provides an overview of what Fedora Server Edition is, the goals and objectives, and what it is designed for. It is written from a user’s point of view to allow people to understand what the Server Edition should do, what it is useful for, and what to expect in the future. | *1.2 Fedora Server Vision Statement* | **2. Fedora Server Vision**| |Fedora Server is the preferred [community] platform for system administrators and developers seeking to deploy applications and services that use the latest technology on a stable foundation with effective resource utilization. |Fedora Server is a real-world incarnation of the [Fedora Project's vision](https://docs.fedoraproject.org/en-US/project/) for organizations, individual users, and developers to get the deployment of applications and services done in reality – freely, autonomously, and under their own control.| | *1.3 Fedora Server Mission Statement* | **3. Fedora Server Mission** | | Fedora Server is a common base platform with "featured server roles" built on top of it. We commit to produce, test, and distribute these server roles. |**You gain an eye on the server of the future.** </br>Fedora Server is a platform for developers and system integrators, which provides an implementation of the latest server technology for further evaluation and practical appropriation. </br> **You gain the opportunity to use the server of the future right now.** </br> Fedora Server provides a stable, flexible and universally adaptable basis for the everyday provision of digital services and information of all kinds by organizations and individuals, based on the latest technology and makes them available at short notice. | | *1.4 Market Opportunity* | **4. Market Opportunity**| |The server operating system market is mature, but constantly evolving. Fedora Server has opportunity for adoption as people deploy new applications and services as well as migrate legacy applications to new platforms.</br></br> With the increased complexity of IT and software, system administrators find it more difficult to devote large amounts of time to dealing with individual technologies, specifically: </br></br> - Detailed understanding of the underlying technology, as has traditionally been required for Open Source server solutions, is often not feasible. </br></br> - The constant focus of Fedora to ship the latest upstream releases of software, combined with a short lifecycle and lack of tooling, require frequently spending significant amounts of time migrating from one Fedora release to another.</br></br>These impositions on system administrators are a significant barrier to further growth of Fedora, and we believe that by improving the product we can remove these requirements and barriers, opening Fedora up to a much larger user base that has so far been limited to non-Linux server solutions.</br></br>Fedora, being a leading-edge Linux distribution, is the ideal place to design such server improvements for the Linux ecosystem together with real-world users to make them available to early adopters.|The server operating system market is mature, but nevertheless constantly evolving. All the technologies currently in focus and under rapid development as e.g. cloud, containers, SAAS, etc. depends as a foundation for operation on servers running on bare metal and capable to handle those technologies‘ requirements. </br></br>Fedora Server provides the opportunity for adoption as people deploy new applications and services as well as migrate legacy applications to new platforms. Fedora, being a leading-edge Linux distribution, is the ideal place to design such server improvements for the Linux ecosystem together with real-world users to make them available to early adopters.</br></br>Fedora Server providing latest technology on a stable foundation with effective resource utilization provisions system administrators with tooling to keep their services on par with attractive ongoing technical evolution and opportunities and use new features an a everyday base as soon as possible.| ||*4.1 Why use Fedora Server?*| ||Under the given general circumstances: Why use Fedora Server?</br></br>1. For those using it for traditional server use cases, why? What about it do you find better than something like CentOS?</br></br>2. For the people who were using it as servers, it was split between getting ready for the next RHEL/CentOS they would be deploying, they needed packages which were not in EPEL, or things like python/nodejs/etc had versions older than what was needed for current task to run but wasn't in EL8.</br></br>3. Because that's what I use on my desktops.</br></br>4. Because latest software versions.</br></br>5. Because I don't have to maintain all the packages I'm interested in for EPEL, too.</br></br>6. Because it works so well.</br></br>7. Fedora provides a recent PHP (unlike RHEL 7) but also ships the full PHP stack required to run popular PHP applications like WordPress/NextCloud/… works like a breeze.</br></br>8. Fedora has advantages not only when RHELx / CentOSx is matured, but in some cases already at release time, when some important components are already „behind“, e.g. postfix / dovecot with CentOS 8 regarding SNI and submission (which are quite important features in a containerised world). And with the current rapid development, even small version differences can be important.</br></br>9. Advantages sui generis in Fedora Server over CentOS/RHEL (almost) all the positive features that make CentOS /RHEL stand out (well thought-out architecture and workflows, security, systematic tools, etc.) and additionally:</br></br>&nbsp;&nbsp; - more up-to-date application software, which often enables a better response to current developments and changing requirements</br></br>&nbsp;&nbsp; - easier administration due to a greater variety of available packages</br></br>&nbsp;&nbsp; - shorter release jumps, which are therefore less disruptive</br></br>&nbsp;&nbsp; - easier (quasi rolling) updates (dnf update), which save a lot of time</br></br>&nbsp;&nbsp; - Freedom from strict RH feature management (example BTRFS, XEN some years ago)</br></br>&nbsp;&nbsp; - greater backwards hardware compatibility (e.g. exclusion of drivers in el 8, which make some older hardware unusable or only very difficult to use)</br></br>10. I have found updates to Fedora server software to be less disruptive than the desktop updates. I also find many small updates easier to manage than a few big updates.</br></br>11. I do a snapshot and upgrade which has been really smooth. I actually find it easier than running the same release for 3 years, but then having to undergo a migration to a new major release. And I still get to enjoy the latest and greatest.</br></br>12. Fedora resolves most / many typical problems of Dev/Ops/DevOps & DevOps equally:</br></br>&nbsp;&nbsp; - many security tools out of the box (usbguard, SELinux, firewalld, auditd, aide, etc.)</br></br>&nbsp;&nbsp; - kernel is very new and therefore supports tons of hardware</br></br>&nbsp;&nbsp; - software is very new and supports tons of developer demand</br></br>&nbsp;&nbsp; - additional software like cockpit, pcp, tuned, etc. is very handy for small to larger environments (nobody wants to use cockpit to manage 100s of servers, but providing a UI for devs/unexperienced ops/hosting customers is quite nice)</br></br>&nbsp;&nbsp; - fedora-minimal is quite nice container base to build upon</br></br>&nbsp;&nbsp; - the awareness of EOL and mitigation plans are immediatly a thing, if the lifetime is 13 month only</br></br>&nbsp;&nbsp; - the awareness of single instance SLA is a thing, if you should patch at least every 90 days AND reboot</br></br>&nbsp;&nbsp; - developers are able to use the same tools on their notebook/workstation they can use on the servers/images</br></br>13. I still use Fedora because it has the latest stable version of most packages and modern sysadmin tools (i.e. cockpit, dnf, systemd were all "tested" with Fedora). What I mean by "stable" is that Fedora is not bleeding edge (like Rawhide), but stable enough to put in production and give it a try</br></br>*Another Numbering*</br></br>1. It’s up-to-date application software and great variety of available packages often enables a better response to current developments and changing requirements. It noticeably reduces the burden of system administration</br></br>2. It provides the latest stable version of most packages and modern sysadmin tools (i.e. cockpit, dnf, systemd) – an excellent balance between bleeding edge and maturity for productive use in mainstream deployments</br></br>3. Security in mind - carefully pre-configured and secure without prior extensive configuration work by system administrators</br></br>4. Very easy (quasi rolling) updates with shorter, less disruptive release jumps – many small updates are easier to manage than a few but big updates</br></br>5. Freedom from restrictive Enterprise feature management (example BTRFS, XEN etc)</br></br>6. Excellent backwards hardware compatibility (including complete standard kernel driver set without enterprise optimized selection which make some older hardware unusable or only very difficult to use)</br></br>7. Excellent development environment for the next generation server as well as application software with the latest software versions available| |*1.5 Product Objectives*|**6. Server Edition Objectives**| |Fedora Server consists of a release that can be used at various scales. For example, it could be used in the following example environments:</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• A single server that runs an application or service.</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• A platform for an entire data center.</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• The platform to deploy an Infrastructure-as-a-Service (IaaS) private cloud.</br></br>Fedora Server is meant to be used for the following purposes:</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• An operating platform for important infrastructure tasks (DNS, DHCP, etc.) and server applications (file/storage server, database server, user-developed web applications, etc.)</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• A platform for deploying Infrastructure-as-a-Service systems for best deployment of Fedora Cloud images.</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• Infrastructure to allow efficiently managing many servers as a single unit. The product only commits to producing basic tools, but the infrastructure will allow more advanced tools to be created.</br></br>The Fedora Server product will also provide one or more "roles" that can be used to easily spin up a service or application. Roles will be introduced gradually as development and testing allow, but it is a primary objective to offer useful roles built on top of the base server offering. More information about what roles are is provided elsewhere in this document.|Fedora Server Edition offers a highly flexible and adoptable multi purpose server platform, usable at various scales. It is meant to be used for the following purposes among others:</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• An operating platform for important infrastructure tasks (DNS, DHCP, etc.)</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• An operating platform for various important, dedicated server applications (file/storage server, database server, user-developed web applications, etc.)</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• A platform for deploying Infrastructure-as-a-Service systems for best deployment of Fedora Cloud images.</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• A platform for deploying containerised applications</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• Infrastructure to allow efficiently managing many servers as a single unit. The product only commits to producing basic tools, but the infrastructure will allow more advanced tools to be created.</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• An operating platform capable to run any combination of forementioned services all according to very different needs of users rsp system administrators (multipurpose feature).</br></br>Fedora Server can be used as a standalone server that runs an application or service as well as a platform in a server cluster in a data center. Due to the strict orientation to open standards, it is capable of cooperating with different server technologies and implementations.| |*1.5.1 Secondary Objectives*|*6.1 Additional Overall Objectives*| |Aside from the adoption and development of applications on top of the Fedora Server platform, we have a few secondary goals that should be helped by wider adoption:</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• More testing of Fedora images with additional bug reports.</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• Better feedback about product direction and potential improvements. This is separate from "bug reports" in that we hope to engage the audience and receive detailed feedback about use cases, desired features, developing trends in cloud management, etc.</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• More patches and contributions that will help improve the product, and Fedora in general. Assuming we're successful, some users should take an interest in helping to develop our product.|Aside from the adoption and development of the Fedora Server platform, we have additional goals that are fundamental to all variants:</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• **Security:** secure by design - extending into TPM support, disk encryption enablement</br></br>&nbsp;&nbsp;&nbsp;&nbsp;• **Community driven:** Intensified feedback about product direction and potential improvements. This is separate from "bug reports" in that we hope to engage the audience and receive detailed feedback about use cases, desired features, developing trends in cloud management, etc. WE encourage more patches and contributions that will help improve the Server Edition, and Fedora in general.| |**2. User Profiles, Primary Use Cases and Goals** </br> *2.1 Personas*|**7. User Profiles, Primary Use Cases, and most important Features** </br> *7.1 Personas*| |We will use a set of personas to describe our target users and their respective needs. This document will list the personas in their simplified forms, with detailed explanations of each one available on their respective wiki pages.</br> **System Administrator "Macgyver"**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Administrator with limited hardware and personnel resources to work with</br>&nbsp;&nbsp;&nbsp;&nbsp;• Needs to be able to do "a lot with a little".</br></br>**DevOps Engineer/Administrator**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Focus is on time-to-deploy and time-to-recover as opposed to uptime</br>&nbsp;&nbsp;&nbsp;&nbsp;• Value is achieved by delivering the latest capabilities fastest</br>&nbsp;&nbsp;&nbsp;&nbsp;• Needs to be able to deliver quickly to PaaS, SaaS and bare-metal servers</br></br>**Traditional Application Developer**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Needs a platform with API and ABI stability guarantees</br>&nbsp;&nbsp;&nbsp;&nbsp;• Focus will be on minimizing risk when making changes</br>&nbsp;&nbsp;&nbsp;&nbsp;• Cannot tolerate rapid changes in core functionality</br></br>**Junior Enterprise System Administrator**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Simplify automation to manage repetitive tasks</br>&nbsp;&nbsp;&nbsp;&nbsp;• Needs intuitive mechanisms to effect common changes</br></br>**Decision Maker**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Makes purchasing decisions and directs technology choices</br>&nbsp;&nbsp;&nbsp;&nbsp;• Interacts with upstream FOSS communities to identify potential value|We will use a set of personas to describe our target users and their respective needs. This document will list the personas in their simplified forms, with detailed explanations of each one available on their respective wiki pages.</br></br>**System Administrator "Macgyver"**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Administrator with limited hardware and personnel resources to work with</br>&nbsp;&nbsp;&nbsp;&nbsp;• Needs to be able to do "a lot with a little"</br></br>**DevOps Engineer/Administrator**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Focus is on time-to-deploy and time-to-recover as opposed to uptime</br>&nbsp;&nbsp;&nbsp;&nbsp;• Value is achieved by delivering the latest capabilities fastest</br>&nbsp;&nbsp;&nbsp;&nbsp;• Needs to be able to deliver quickly to PaaS, SaaS and bare-metal servers</br></br>**Traditional Application Developer**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Needs a platform with API and ABI stability guarantees</br>&nbsp;&nbsp;&nbsp;&nbsp;• Focus will be on minimizing risk when making changes</br>&nbsp;&nbsp;&nbsp;&nbsp;• Cannot tolerate rapid changes in core functionality</br></br>**Junior Enterprise System Administrator**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Simplify automation to manage repetitive tasks</br>&nbsp;&nbsp;&nbsp;&nbsp;• Needs intuitive mechanisms to effect common changes</br></br>**Decision Maker**</br>&nbsp;&nbsp;&nbsp;&nbsp;• Makes purchasing decisions and directs technology choices</br>&nbsp;&nbsp;&nbsp;&nbsp;• Interacts with upstream FOSS communities to identify potential value</br></br>**The Tinkerer**</br>&nbsp;&nbsp;&nbsp;&nbsp;• I have a raspberry/intel nuc/etc. and playing a bit with new stuff. I need a lot of "cool" packages. Newest nodejs, php8, GPIO support, build tools, containers, vms, name-it. Give me all of this, in BETA please. I want the newest shit and I want to break it.</br></br>**The Home Admin**</br>&nbsp;&nbsp;&nbsp;&nbsp;• I need a somewhat stable machine, with a graphical interface (cockpit) and just want to start a couple of containers and/or Vms to have nextcloud running on it.</br>&nbsp;&nbsp;&nbsp;&nbsp;• I need some gitea here, some gitlab there, some jenkins, some photoprism, minecraft, etc. Can I build a NAS easily?</br>&nbsp;&nbsp;&nbsp;&nbsp;• I am ok with updates and reboots over night, but it should work. It would be awesome to have mDNS and a Web UI.</br></br>**The Developer**</br>&nbsp;&nbsp;&nbsp;&nbsp;• I need to have a plattform, that feels like my workstation. I want to build containers, start them, test them and push them.</br>&nbsp;&nbsp;&nbsp;&nbsp;• If I can have nodejs, ruby, php in a decently current version, that would be awesome.</br>&nbsp;&nbsp;&nbsp;&nbsp;• I am ok pulling stuff from "the interwebs", as long as it works and does not bother me too much with: "This container will not run on RHEL, because it requires X or Y."</br>&nbsp;&nbsp;&nbsp;&nbsp;• Yesterday I read something about "remote podman", can I use it?</br>&nbsp;&nbsp;&nbsp;&nbsp;• Why isn't podman dnsname plugin working on the servers, but on my Fedora Workstation? What does the admin mean with "prepare the image for virtualization/cloning/templating"?</br></br>**The Hyperscaler**</br>&nbsp;&nbsp;&nbsp;&nbsp;• I treat servers as cattle, not pets. Fleet reliability is more important than individual uptimes<br />&nbsp;&nbsp;&nbsp;&nbsp;• I want to have a reliable platform for virtualization, core services and container. It should be out of my way, so I can focus on scaling, monitoring, implementation</br>&nbsp;&nbsp;&nbsp;&nbsp;• I want to automate configurations for hostname, timeserver, hardening, etc. In addition I want to deploy typical services like mariadb, httpd, nginx, redis, nodejs, java, etc. in a reproducible way. To see what the machines are doing, I need a well documented way to manage, monitor and backup them.</br>&nbsp;&nbsp;&nbsp;&nbsp;• My Security Team also wants me to disable unneeded services, disable legacy protocols, enable hardening on several levels.</br></br>**The "Let's make a distribution" / "Let's build upon it"**</br>&nbsp;&nbsp;&nbsp;&nbsp;• I love how Fedora works and I want to create something upon it.</br>&nbsp;&nbsp;&nbsp;&nbsp;• My new distro will feature all the cool fedora things and I want to</br>&nbsp;&nbsp;&nbsp;&nbsp;• some software on top of it. I need a very well documented build process and maybe tools to produce new install images and</br>&nbsp;&nbsp;&nbsp;&nbsp;• Removing the branding should be possible with some compiler flags or variables, so I don't need to mess with the code itself.</br>&nbsp;&nbsp;&nbsp;&nbsp;• This will allow me to build my new distribution which will be the perfect: NAX, CloudStorage, Media Server, Gamin Server, Home Server, SOHO Distribution, etc.| |*2.2 Use Cases*|*7.2 Use Cases*| |The Fedora Server will need to address the following use-cases:</br></br>&nbsp;&nbsp;&nbsp;&nbsp;1. The user must be able to easily deploy and configure any supported Fedora Server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server, iSCSI target, File/Storage server, OpenStack Hypervisor Node.)</br>&nbsp;&nbsp;&nbsp;&nbsp;2. The user must be able to query, monitor, configure and manage a Fedora Server remotely using stable and consistent public interfaces.</br>&nbsp;&nbsp;&nbsp;&nbsp;3. The user must be able to simply enroll the Fedora Server into a FreeIPA or Active Directory domain.</br>&nbsp;&nbsp;&nbsp;&nbsp;4. Users must be able to control and contain the resources consumed by services running on the system.</br>&nbsp;&nbsp;&nbsp;&nbsp;5. Users must be able to rapidly re-deploy services in accordance with their DevOps practices using Fedora Server.</br>&nbsp;&nbsp;&nbsp;&nbsp;6. Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface.</br>&nbsp;&nbsp;&nbsp;&nbsp;7. The user must be able to install and manage Fedora Server in a headless mode where the display framework is inactive.|The Fedora Server will need to address the following use-cases:</br></br>&nbsp;&nbsp;&nbsp;&nbsp;1. So for personal servers... well, I've never seen Fedora Server broken by automatic updates. I don't think I would use Fedora Server for critical business infrastructure, but it works well enough for my personal needs.</br>&nbsp;&nbsp;&nbsp;&nbsp;2. I use Fedora Server on all of the hosts in my home data center (~12 hosts).</br>&nbsp;&nbsp;&nbsp;&nbsp;3. I've been running Fedora Server ony my personal server with Nextcloud on LAMP and a couple of other services such as VPN, Wireguard, TUN and it's been really effortless.</br>&nbsp;&nbsp;&nbsp;&nbsp;4. Server should forcus on mostly headless services</br>&nbsp;&nbsp;&nbsp;&nbsp;5. single node deployments</br>&nbsp;&nbsp;&nbsp;&nbsp;6. multi node deployments </br>&nbsp;&nbsp;&nbsp;&nbsp;7. focus on soho rather than enterprise at this point</br>&nbsp;&nbsp;&nbsp;&nbsp;8. strong container support in "my basement" and in "soho".. including things like openshift</br>&nbsp;&nbsp;&nbsp;&nbsp;9. Development, developers require new software (php, node, ruby, java, name-it)</br>&nbsp;&nbsp;&nbsp;&nbsp;10. I don't think Fedora Server can compete in the hypervisor/hyperconvergence arena against Proxmox or Xen.</br>&nbsp;&nbsp;&nbsp;&nbsp;11. Home server. (Fedora server as main virthost + gateway +Fedora server vm's on it for various services. )</br>&nbsp;&nbsp;&nbsp;&nbsp;12. Fedora infrastructure: We run a lot of Fedora in fedora infrastructure. All the builders are Fedora, many of our application servers are Fedora when they need newer tools than RHEL, many of our applications in openshift run in Fedora containers, our proxy servers, etc.</br>&nbsp;&nbsp;&nbsp;&nbsp;13. I think we could pull in the cloud image (If the cloud sig agrees/joins us or we join them), but possibly we could target it for clouds + a vm raw image.</br></br>*Another Numbering*</br></br>&nbsp;&nbsp;&nbsp;&nbsp;1. Personal home server, located ‚on premise‘ in own flat / house and used as NAS, backup device, and for applications such as mail repository, contact database, calendar, ebook library, media server, etc.</br>&nbsp;&nbsp;&nbsp;&nbsp;2. On premise server for small and medium-sized enterprises hosting mail service, calendar, and branch specific (probably containerized) software – either single node deployment or multi node deployment with automatic fall back</br>&nbsp;&nbsp;&nbsp;&nbsp;3. Dedicated Soho Internet server, 'bare metal' rented from a remote provider and under its own full control, for offering various services and information. Public access is in VMs for security reasons.</br>&nbsp;&nbsp;&nbsp;&nbsp;4. Single node or multi node deployment in enterprise data center to provide up-to-date software versions according to domain specific requirements in a stable and secure OS, capable to provide different runtime environments – native, VM, different container systems – driven by domain specific demands.</br>&nbsp;&nbsp;&nbsp;&nbsp;5. Development box, providing developers with the latest software version and excellent developing tools| |*2.3 Featured Server Roles*|*7.3 Most Important Features*| |A Featured Server role is an installable component of Fedora Server that provides a well-integrated service on top of the Fedora Server platform. These prepared roles simplify deployment and management of a service compared to setting up an upstream server from scratch; their use is recommended but optional; existing users of upstream servers based on Fedora RPMs will not be impeded.</br>Initially, we will test and support only a single role per server; installing several non-conflicting roles is expected, but we will not be testing every combination.|1. The user can easily deploy and configure any supported Fedora Server application. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server, iSCSI target, File/Storage server, OpenStack Hypervisor Node.)</br>2. The user can query, monitor, configure and manage a Fedora Server remotely using stable and consistent public interfaces.</br>3. The user can simply enroll the Fedora Server into a FreeIPA or Active Directory domain.</br>4. Users is able to control and contain the resources consumed by services running on the system.</br>5. Users is able to rapidly re-deploy services in accordance with their DevOps practices using Fedora Server.</br>6. Users can create, manipulate and terminate large numbers of containers using a stable and consistent interface.</br>7. The user is enabled to install and manage Fedora Server in a headless mode where the display framework is inactive.</br>8. The user is provided the opportunity to use a light-weight graphical UI to facilitate daily administrative tasks (Cockpit).| ||*8. (Future) Goals / What is upcomming*| ||1. Server: pxe/netboot (better support in addition to dvd/netinstall)</br>2. Cloud: a runnable image (help market the Cloud image more to server admins that want a ready to run image, cooperation with / integration of vloud base image)</br>3. linux-system-roles (is it's own project, Help them, and help make it feel like a primary feature of Fedora Server. Right now, our marketing materials at https://getfedora.org/en/server/ highlight: modularity, cockpit, FreeIPA)</br>4. I would like to see some additional roles such as email-server, web-server, contact server, calendar server, etc. fleshed out and made available.</br>5. be pushing for text-only mechanisms for all relevant administrative functions (cf. the gpg-agent discussion), (nearly) everything managable by scripts and automation, ansible as the most important (and most mature) managing tool,</br>6. tools/app included supporting industry change (e.g. IPMI is deprecated, Redfish is the future)</br>7. Provide a minimalistic server install (for instance, NetworkManager is overkill for a server, and in many cases a hindrance).</br>8. Key packages like databases, languages, Web infrastructure must be solid and pre-configured for high loads (things like php-fpm, nginx, Postgres, etc.).</br>9. Provide kernels tuned for large RAM, high storage I/O and high network I/O.</br>&nbsp;&nbsp;&nbsp;◦ *Kevin Fenzi comment:* we can urge maintainers to do things for us, but not sure we can ship seperate kernels and packages. Generally it's better to make the packages usefull for many use cases and easy to tune/change/configure.</br>10. Provide easy integration into multi-node environments, with tools like Ansible (we may have to favor one such tool, like we favor cockpit).</br>11. We must keep upgrades smooth, as they are now with dnf.</br>12. A "Security Profile" may be suitable. For instance at a minimum a nice Firewalld+Fail2Ban configuration, then go up with Snort, Tripwire, SELinux.</br>13. In short, have a distro that can be deployed in 5min in a small VM and start doing something useful half an hour later</br>&nbsp;&nbsp;&nbsp;◦ *Kevin Fenzi comment:* We have that now and we should keep pushing it forward.</br>14. it's quite likely we'll be wanting to contribute to https://linux-system-roles.github.io/</br></br>*Another Numbering*</br></br>1. Improved support for off-premise Kickstart and pxe installation</br>2. Improved support to use base cloud images for Vms in Fedora Server</br>3. Facilitating the use of cloud images for Vms in Fedora server</br>4. Providing easy installation and pre-configuration for key packages as mail service, caldendar, databases, WEB services, etc. (linux system roles), – probably by providing Ansible playbooks</br>5. Provide easy integration into multi-node environments, with tools like Ansible| |*2.3.1 Mandatory Requirements*|| |Mandatory requirements are exactly as they sound: if any one of these requirements is not met, the server role is ineligible for elevation to "featured" status.</br>1. The Server Role must be packaged in such a way that it is possible to install the complete set as a unit. AKA "One-click Install". [Use Case 1]</br>2. The Server Role must provide an API or similar stable external interface for configuring the role post-installation. Exceptions to this rule may be granted if and only if Optional Requirement 2 (below) is met and it can be demonstrated that the default method of operation is the only reasonable method of operation. [Use Case 1]</br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;◦ If the API is provided by the Fedora project it must be built using a common framework to all Fedora developed Role APIs. If upstream provides such an API, it is permissible to use that.</br>3. The Server Role must provide an API to interrogate the configurable settings of the role as identified by Mandatory Requirement 2. [Use Case 2]</br>4. The Server Role must add to the functionality of the Fedora Server. In other words, a Server Role cannot be considered "Featured" if its purpose is to further reduce the minimal system.</br>5. A Server Role must have an identified point of contact that agrees to maintain the Server Role in Fedora. If this person or group becomes unresponsive, the Server Role will necessarily be demoted from Featured status. A Server role must be possible to trivially update to fix security vulnerabilities, and maintained to provide security fixes in a timely manner.</br>6. A Server Role must be installable without a local graphical utility. [Use Case 7]</br>7. If a Server Role packages multiple upstream projects together as a suite or solution, updates to any of these projects must be coordinated for concurrent release to allow testing of the complete system.</br>8. A Server Role must automatically use and sufficiently implement specified system-wide settings (e.g. a LDAP source for account information, CA certificates, and similar domain-originated or system-wide configuration)|| |*2.3.2 Conditional Requirements*|| |This is not a list of things you should ignore. Rather, this is a list of things that if you implement them, you are committing that they must continue to behave that way in the future.</br>1. The Server Role may be packaged in such a way that it can be uninstalled as a complete unit. The mechanism to accomplish this removal must remain consistent. [Use Case 1]</br>2. The Server Role may provide a sane, usable default. If it does so, it must remain capable of accepting input through its configuration API to change this default. [Use Case 1]</br>3. The Server Role may provide an API to interrogate additional useful information about the running service(s) provided by the Server Role. The content here is up to the Server Role to define, but should be treated as stable (e.g an update should never remove the ability to monitor something). [Use Case 2]</br>4. The Server Role may provide a specification of its needed resources to the Fedora Server in a standard format. (e.g. Memory requirements) If this is provided, the Fedora Server may use this information to create isolated services such as VMs or containers in which to run the Server Role. [Use Case 4]</br>5. The Server Role may request operation in an isolated environment (with or without implementing Optional Requirement 4). If it does so, the Server Role must indicate (using a standard Fedora Server API) what form(s) of isolation it supports. Fedora Server must honor this. [Use Case 4]</br>6. A Server Role may provide a remote graphical (which includes web-based) configuration tool.</br>7. A Server Role may implement all of the other requirements by integrating with the Fedora Server-designated infrastructure (commands, APIs, and the like). This is preferred but not mandatory if the upstream provides a different way to achieve the same objective.|| |**3. Logistical Concerns** </br> *3.1 Delivery Mechanisms*|**9. Logistical Concerns** </br> *9.1 Delivery Mechanisms*| |Fedora Server will produce two main installation resources, a netinstall image and an offline install iso image that allows one to install and configure featured roles offline.</br></br>Supported installation methods:</br>• Automated ("mass") install within a larger Linux infrastructure (e.g. PXE is an option, may have LDAP/IPA).</br>• Manual install without a supporting infrastructure (e.g. the very first Linux server).</br>• Where possible, existing servers and installed roles should be upgradable to new releases with minimal involvement by the admin.</br>• Individual roles should be installable at server install time (e.g. in Anaconda) and post-install.|Fedora Server Edition ~~will~~ produces two main installation resources, a netinstall image and an offline install iso image that allows one to install ~~and configure featured roles~~ offline.</br></br>Supported installation methods:</br>• Automated ("mass") install within a larger Linux infrastructure (e.g. PXE is an option, may have LDAP/IPA).</br>• Manual install without a supporting infrastructure (e.g. the very first Linux server).</br>• Where possible, existing servers ~~and installed roles~~ should be upgradable to new releases with minimal involvement by the admin.</br>• ~~Individual roles should be installable at server install tim (e.g. in Anaconda) and post install~~| |*3.1.1 Where to obtain*|*9.2 Where to obtain*| |Users will be able to obtain these images from the Fedora Project website and mirror networks.|Users will be able to obtain these images from the Fedora Project website and mirror networks.| ||*9.3 Documentation*| ||*Basic Documentation*</br>• Part of Fedora Installation and System Administration Guide</br></br>*Specific / Additional Documentation*</br>• Dedicated Section| |**4. About this Document** </br> *3.1 Authors*|**10. About this Document** </br> *10.1 Authors*| |Contributors to this document include:</br>&nbsp;&nbsp;&nbsp;&nbsp;• Stephen Gallagher</br>&nbsp;&nbsp;&nbsp;&nbsp;• Jim Perrin</br>&nbsp;&nbsp;&nbsp;&nbsp;• David Strauss</br>&nbsp;&nbsp;&nbsp;&nbsp;• Truong Anh. Tuan</br>&nbsp;&nbsp;&nbsp;&nbsp;• Máirín Duffy</br>&nbsp;&nbsp;&nbsp;&nbsp;• Kevin Fenzi</br>&nbsp;&nbsp;&nbsp;&nbsp;• Miloslav Trmač</br>&nbsp;&nbsp;&nbsp;&nbsp;• Simo Sorce</br>&nbsp;&nbsp;&nbsp;&nbsp;• Adam Williamson</br>&nbsp;&nbsp;&nbsp;&nbsp;• Joe Brockmeier|Contributors to this document include:</br>&nbsp;&nbsp;&nbsp;&nbsp;• Stephen Gallagher</br>&nbsp;&nbsp;&nbsp;&nbsp;• Jim Perrin</br>&nbsp;&nbsp;&nbsp;&nbsp;• David Strauss</br>&nbsp;&nbsp;&nbsp;&nbsp;• Truong Anh. Tuan</br>&nbsp;&nbsp;&nbsp;&nbsp;• Máirín Duffy</br>&nbsp;&nbsp;&nbsp;&nbsp;• Kevin Fenzi</br>&nbsp;&nbsp;&nbsp;&nbsp;• Miloslav Trmač</br>&nbsp;&nbsp;&nbsp;&nbsp;• Simo Sorce</br>&nbsp;&nbsp;&nbsp;&nbsp;• Adam Williamson</br>&nbsp;&nbsp;&nbsp;&nbsp;• Joe Brockmeier| Some *"loose ends"* These probably earn a discussion independent of PRD Relation to cloud, IoT, CoreOS, etc * daniel-wtd <daniel@while-true-do.io>. (Dec 17 2020) some examples are coming to my mind: * For example, the IoT Edition features 2 tools (greenboot and zezere), which may be a nice addition for smaller environments or edge computing. Both tools are currently meant for IoT only, but can be easily adopted. Zezere for example can be used to add SSH Keys (or else) to remote edge servers and greenboot is capable to trigger scripts if something goes wrong. * For the cloud/coreos approach, there is even more stuff in both ecosystems podman, docker and kubernetes are a thing that are present on both platforms. Ignition on the other hand shares some of the capabilities of kickstart (at least from a user perspective). I am not sure why 2 different deployment approaches, that basically do the same (preconfigure a system) should co-exist on the long run. To be honest coreOS in its current state lacks some features, that I personally love and even Fedora IoT or Silverblue feel more "mature". For example installing cockpit on Fedora IoT is basically the same as in fedora server. The cockpit deployment on coreos does not work the way it is documented and the IoT way does not work either. CoreOS (at least for now) seems somewhat out of place. * Supporting each other to have a coherent experience, where everything "feels" well known would be the only correct step from my perspective. Relation to cloud Image *(mattdm's comments)* * Also, I want to throw out my long-standing thing for anyone to pick up: merging in the Cloud Base image so it's basically just an alternate deploy of server * either combining energy or just having a collaboration. whichever works best * and if the end result is they stay separate images cool with that too as long as we have a good story as to why one would pick each