cockpit-modules: web panels for day-to-day operations
Cockpit covers basic Linux administration in the browser: services, logs, networking, accounts. Firewall, fail2ban, cron, and Let’s Encrypt sit outside that set — either there is no panel, or it is too generic.
The cockpit-modules group is a set of separate modules for those jobs, plus a store that installs them on the host. Each module lives in its own repository. This is a map of the group, not a walkthrough of UI and commands. Individual panels get their own articles.
Why extra modules
Cockpit grows through packages in /usr/share/cockpit/ (or ~/.local/share/cockpit/ for the current user). A module is a manifest.json, HTML, and JS that call host tools via cockpit.spawn.
The group targets a typical home or small server:
- perimeter: UFW and fail2ban;
- scheduling: crontab and systemd timers;
- TLS: certbot and the Cockpit panel certificate;
- delivery: a module store backed by the same GitLab group.
The UI is in Russian and matches the rest of Cockpit (PatternFly v5). You need Cockpit 264+ and administrator rights for writes.
Shared repository rules
Modules share the same layout so the store and install scripts stay consistent:
- sources in
pkg/<id>/; install.sh— system-wide or--user;- releases tagged
v.M.m.p; - Docker Compose for local development (
localhost:9090); - MIT license.
Host commands run as argv arrays, not shell strings. Input is validated on the client. Without Cockpit admin rights the panel stays read-only.
A project appears in the store catalog only if it lives in the cockpit-modules group. The catalog is not arbitrary GitLab — it is an explicitly trusted set.
Module store
cockpit-modules-store is the entry point. Under Tools you get Module store: the group project list, tags, status (available / installed / update ready), install of a release archive into /usr/share/cockpit/, and removal of user modules. Built-in Cockpit pages are left alone.
You can still install the other panels by hand with install.sh, but the store removes a clone/copy cycle per repository.
Quick install of the store itself:
Panels in the group
| Module | Job |
|---|---|
| UFW | ufw package, status, policies, allow/deny/reject/limit rules |
| Fail2ban | package and service, jails, ban/unban IPs |
| Cron | user crontabs, /etc/crontab and /etc/cron.d/, systemd timers |
| CertManager | Let’s Encrypt / certbot, Cockpit panel TLS, renew |
UFW is a full Uncomplicated Firewall cycle without ufw status numbered over SSH: the package via APT/DNF/YUM/Pacman, enable/disable, default policies, rule list, and add-by port, protocol, and source. Panel write-up: cockpit-ufw-module.
Fail2ban is the neighbouring perimeter panel: daemon install, jails, banned addresses, ban and unban in a selected jail or globally.
Cron is the scheduler people usually edit in nano. User crontabs, system files, and systemd timers in one place. Editing timer unit files is out of scope.
CertManager covers certificates for sites and for the Cockpit panel itself. HTTP-01 and DNS-01, binding a lineage to the panel, upload of your own crt+key, auto-renew via certbot.timer.
How it fits together
On a clean host the natural order is: Cockpit → store → UFW and fail2ban → CertManager for HTTPS on the panel → Cron if needed. Modules are independent: cron does not depend on certbot.
Sources, issues, and releases live at gitlab.com/cockpit-modules. First per-panel write-up: UFW.