Server/Using Ansible

Fedora Server Ansible Team Activists Fredrik Arneving (swefredde) Peter Boy (pboy) John Himpel (jwhimpel) more to add (hopefully) Communicating Mailing list: server@lists.fedoraproject.org IRC: #fedora-server on freenode

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:

1. Do the scripts play well with Fedora Server?
2. Do we want to encourage the use of those scripts and how?
3. How can we make them (better) usable in Fedora Server?
4. Can we use them as a kind of base library for more complex, cross-package services?
5. 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 (??)