Stephen Gallagher bravely embraced his spot as one of the first talks of the day, after a Flock pub night. As a representative of the Fedora Server working group, he presented an overview and status report on the Fedora Server, one of the new products that makes up the Fedora.next initiative.
Background and basics
First he discussed the history of the work. One goal of the working group is to combat the notion that Fedora is not for servers. If the downstreams of Fedora (such as Red Hat Enterprise Linux and CentOS) are popular for servers, “surely someone at some point thinks Fedora is for servers.”
Furthermore, Gallagher continued, these days the operating system platform itself is no longer the sole focus of system administrators. The applications stacked on the server are what their users are demanding, and the OS is merely a way to deliver those applications. So Fedora Server is intended to be a platform to deploy the latest versions of these applications. Of course, this wouldn’t change the desire for Fedora to be a great way to debut and integrate technologies that will be seen in the next generation of downstream server platforms.
So how will the Server meet these goals? First, availability: continuing the tradition of a highly stable platform that remains up for long periods. Second, though, is manageability, which will help increase the adoption of the platform among small and medium businesses where it’s too expensive to employ large sysadmin teams. Compatibility and extensibility are also a key focus — allowing interoperation with other operating systems in mixed environments, and emphasizing modular and plug-in architectures that increase the community’s ability to build on the platform. Finally, Gallagher emphasized resilience, or the ability for the system owner to quickly and effectively recover in the event of an issue.
Server Roles
Gallagher then moved on to talk about RoleKit. To do this, he first mentioned pet versus cattle roles. “Pet” servers are ones you care for regularly, and if they get sick, you spend resources to keep them well. “Cattle” servers, on the other hand, are not as valuable individually, so if one gets sick, you simply replace it. RoleKit is built in two pieces to manage server roles: a daemon with a well documented public API for deploying and managing server roles, and a command-line interface to that API, rolectl. So for example, the administrator could enter a simple rolectl command to easily make a server become a typical Postgresql database server.
In Fedora Server 21, Gallagher believes there will be at least two roles available to start with, a FreeIPA domain controller that interoperates with Microsoft Windows environments, and the aforementioned PostgreSQL database server. The aim, Gallagher says, is for system owners to say how hard this used to be, and then “to quickly stop saying that.”
In the future, additional roles will be added, such as a caching server and — a more complex but very important target — a network file server with NFS and Samba services. He also pointed out that because of the public API and extensibility provided, the community will be able and encouraged to create and improve additional roles, beyond those the Server working group is driving.
Infrastructure for Fedora Server manageability
Gallagher moved on to talk about OpenLMI, a powerful, low-level interface for managing diverse systems. OpenLMI has added an easy to use lmishell utility, a Python-based scripting environment for accessing the management functions of CIM. CIM is a framework for management that is known for being powreful but also incredibly complex. OpenLMI tames this complexity and delivers a management tool meant to rival Microsoft’s PowerShell feature for servers.
Cockpit is another feature that delivers manageability through a modern web interface. It will handle one server or many, interoperate with other tools and utilities, and make management simple and effective. Reaction to Cockpit has been strong and positive and this feature will not only enhance Fedora Server but in the future do the same for RHEL and CentOS. Cockpit represents a major step forward in the Linux approach to management, Gallagher continued, both by bringing these tasks into the grasp of novice administrators, and by playing well with others, including containers such as Docker.
Gallagher then ran a short live demonstration of the Cockpit system. One of the ease of use features he pointed out early was the “Join Domain” control which makes it easy to bring a Linux server into an existing Windows domain via realmd. He showed a number of other control panels to access the journal and other runtime systems, and then noted that containers are also easy to manage with Cockpit. In the future, he continued, it will be possible for Server Roles themselves to be deployed easily in containers, so upgrades to the Fedora Server host will not affect the roles in use — and those roles can be migrated later at convenience.
One question was whether Cockpit will itself support deploying Server Roles. Gallagher said the answer is absolutely — but not in time for Fedora 21. In answer to another question, Gallagher mentioned that for some roles, the owner may need to provide information. The API allows these to be passed in a dictionary, so it will be possible for Cockpit to query the user for them.
This presentation along with almost all the other Flock presentations are available on the Flock YouTube channel here. You can watch the complete Fedora Server presentation, including the demo, right here:
