Skip to content

Server Applications

Marius Vollmer edited this page Mar 29, 2017 · 18 revisions

Server Apps aka Server Roles

Users want to add stuff to their servers so that they can do their real job, such as serving web pages, running data bases, etc. We call this stuff "Server Applications".

User also want to add stuff to extend the functionality of the operating system and its UI, such as lvm2, network teams, container runtimes, selinux troubleshooting, etc. We call this other stuff "Operating System Extenstions".

This here is about Server Applications.

(Cockpit should also be able to manage Operating System Extensions, of course, and it isn't any good at it right now.)

We model "Server Applications" after other kinds of applications that people are familiar with: You discover them in some sort of AppStore, you install them without any dialog wizards, and after that you can use them.

Unlike desktop applications, you don't launch server applications. They are always there, just like "Storage" and "Journal" are always there.

Some applications have their UI entirely inside Cockpit, and installing them will make them appear in the Cockpit navigation menus.

Some applications have their setup configuration and basic monitoring in Cockpit, but the main UI is reached via a link.

Applications are managed in a new "Applications" tool. It lists the installed applications, has a way to discover and install more.

Each application is responsible for presenting itself on the list of installed Applications. It does this by contributing a chunk of JavaScript via Cockpit resource globbing.

Typically, one entry in the list of applications can show status of its services and its journal messages, can launch some configuration dialog, and links to the main UI.

Applications have control over their own removal.

Application updates are TBD[3].

Application Store

Applications will come as OS packages, container images, or maybe even Flatpaks. So we use the existing sources for these things to also retrieve Server Applications meta data and to download the actual application.

OS packages, Flatpak

We copy what GNOME Software does and maybe extend it[2]. After installing the application, it will naturally show up as an additional Cockpit package (or many) in the Cockpit manifests[1].

https://www.freedesktop.org/wiki/Distributions/AppStream/

Container images

We check what "System Containers" are doing and maybe extend it. Maybe push them into the appstream. After downloading the container image, it will show up in the Cockpit manifests via some system container magic that allows putting files into the host[1].

http://www.projectatomic.io/blog/2016/09/intro-to-system-containers/

Concrete Applications

FreeIPA - Domain Controller

Its entry in the list of installed applications shows whether FreeIPA is setup or not, and allow simple setup via the ipa-server-install utility.

After setup, it will monitor the systemd services of FreeIPA and show their journal entries.

It will prominently show a link to the FreeIPA administration UI.

At least initially, this application will use OS packages and be developed in the Cockpit source tree.

PostgreSQL - Database

TBD

NFS - File Sharing

TBD

Apache - Web Server

TBD

Next steps

  • Study Appstream, show it in Cockpit, add the concept of "Server Applications" to it.

  • Make the Applications component for Cockpit and a trivial HelloWorld application.

Footnotes

[1] Changes to the manifests currently require a logout/login. We can remove that limitations, and initially prompt the user to logout after installation.

[2] Maybe with, maybe without PackageKit.

[3] OS packages should probably be updated together with the OS, while Flatpaks and System Containers could be updated individually from the list of installed applications.

Clone this wiki locally