All,
At today's Fedora Server meeting on IRC, it was requested that we open a thread on the Server mailing list to provide use cases. This is my attempt to start that discussion.
Use Case #1: 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.
Use Case #2: In reality, I suppose this is just a variation on Use Case #1.
The site wishes to host dhcp, dns and other network management related services locally. The site also might wish to use dnssec to help with network security and integrity. I know that DNS over HTTPS (DoH) vs DNS over TLS (DoT) is somewhat controversial, but configuration of these options could be provided by server-ansible-roles.
My network-foo is not strong enough to know if/how Unbound fit into the picture. But again with the proper server- ansible-roles, it should be able to integrate into this architecture.
Use Case #3: Again, this might just be a variation on Use Case #1.
Radicale is a program that will synchronize calendars, contacts, and to-do lists between applications that support CalDAV, CardDAV and http. It allows a user to keep this information in sync between a desktop, laptop and/or a smart phone on linux, windows and ios. It involves installing rpms for radicale, (apache or nginx), and most-likely git (for version control of the data files). Configurations for radicale and the web server need to be altered according to user preferences. Such configuration changes include things like authentication, reverse proxy, wsgi, rights management, etc. Hopefully, two server-ansible-roles would perform all the necessary configuration changes (one role for apache and another for nginx).
Use Case #4: If we wanted to be real ambitious, a role for installing and configuring Wildfly (or any other large complex piece of software). It could be installed via the provider’s installation method which would probably include software installed in /opt that are specific to the individual application. Or we could perhaps develop server-ansible-roles to download all the individual component pieces, package them into rpms, submit them to the Fedora Packaging processes for inclusion into basic fedora.
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.
Let the conversation begin.
I’m to add some items:
Am 26.05.2021 um 23:48 schrieb John W. Himpel john@jlhimpel.net:
All,
At today's Fedora Server meeting on IRC, it was requested that we open a thread on the Server mailing list to provide use cases. This is my attempt to start that discussion.
Use Case #1: A small site without an experienced Systems Administrator wishes to host their own email server. ... 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.
Another problem is that very many (almost all?) completely ignore the structure of the configuration files that Fedora uses, which makes subsequent updates very difficult. Is especially noticeable with dovecot.
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.
Perhaps we should put together one or more types of use cases associated with different features of the configuration.
One possible type would be the "mail concentrator" which collects mail from one or more mail service providers and also uses it to send mail. This does not need DKIM and Co.
Another type would be "small Business / Home user", who needs DKIM and Co, but no sophisticated user management.
Use Case #4: If we wanted to be real ambitious, a role for installing and configuring Wildfly (or any other large complex piece of software). It could be installed via the provider’s installation method which would probably include software installed in /opt that are specific to the individual application. Or we could perhaps develop server-ansible-roles to download all the individual component pieces, package them into rpms, submit them to the Fedora Packaging processes for inclusion into basic fedora.
It would have to include:
- checking the requirements: appropriate Java version - maybe additional software, usually a database (postgresql) - creating the systemd infrastructure - downloading the software and installing it, probably in /opt - Managing updates.
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.
++ to all of these
server@lists.fedoraproject.org
-
John W. Himpel -
Peter Boy