Install Cockpit on openSUSE Leap and Tumbleweed

What Cockpit is (and is not)

Cockpit is a web interface for one Linux server: services, logs, storage, networking, updates, containers and a terminal, in the browser. It talks to the same systemd, journal and podman you use from the shell, so whatever you do in one shows up in the other. It is not a configuration management tool and keeps no database of its own: close the tab and the server is exactly as the shell left it.

On Leap 16, Cockpit is the recommended web-based admin tool; on Tumbleweed you get the newest release within days. This series assumes one of the two.

Install the packages

Installing needs root:

sudo zypper install cockpit                # the web service, system pages and terminal
sudo zypper install cockpit-podman cockpit-storaged cockpit-networkmanager

cockpit pulls in the core pieces (cockpit-ws, cockpit-bridge, cockpit-system). The plugins add pages: cockpit-podman for containers (next guide), cockpit-storaged for disks, cockpit-networkmanager for network settings. On SELinux systems, cockpit-selinux adds a page that explains denials. zypper se cockpit lists the rest.

What gets installed, and who is locked out by default:

$ rpm -q cockpit cockpit-ws cockpit-podman cockpit-system
cockpit-365-1.1.x86_64
cockpit-ws-365-1.1.x86_64
cockpit-podman-129-1.1.noarch
cockpit-system-365-1.1.noarch
$ cat /etc/cockpit/disallowed-users
# List of users which are not allowed to login to Cockpit
root

Start it the socket-activated way

sudo systemctl enable --now cockpit.socket
systemctl status cockpit.socket            # active (listening)
sudo ss -tlnp | grep 9090                  # systemd holds the port

Enable the socket, not cockpit.service. systemd listens on 9090 and starts the web service when a browser connects. The openSUSE package also runs a small check before the socket starts; if it fails, the reason is in journalctl -u cockpit.socket (the gotchas guide covers the usual ones).

The unit files after installation: the socket is enabled, the service is static and only ever started by it:

$ systemctl list-unit-files --no-pager --no-legend cockpit.socket cockpit.service
cockpit.service static  -
cockpit.socket  enabled enabled

The firewall rule, explained

firewalld knows a service called cockpit, which stands for 9090/tcp. The command to allow it looks like this; read it before you run it (it needs root):

sudo firewall-cmd --permanent --zone=home --add-service=cockpit
sudo firewall-cmd --reload

• --permanent: write it to the saved configuration, so it survives a reboot.
• --zone=home: only for traffic that firewalld sorts into the home zone. Which zone that is matters more than anything else here.
• --add-service=cockpit: allow the ports of the cockpit service (firewall-cmd --info-service=cockpit shows them).
• --reload: load the saved configuration into the running firewall.

The command only helps if your LAN (or VPN) traffic actually lands in that zone. Putting it in public, the default zone of your network card, opens Cockpit to every network that card is on. The WireGuard guide shows the zone setup that keeps it private, and the firewalld port helper builds, checks and undoes such rules.

First login and administrative access

1. Browse to https://homeserver:9090 (or the IP address).
2. Accept the certificate warning once: Cockpit made a self-signed certificate on first start.
3. Log in with your normal user and its password. Root is refused on purpose.
4. The top bar says "Limited access". Click it to turn on administrative access. Cockpit then uses sudo, and asks for the password sudo wants.

On openSUSE's default sudo policy that is root's password, which confuses nearly everyone the first time. To use your own password instead, install sudo-policy-wheel-auth-self and add yourself to wheel, as shown in the sudo and SSH guide. Next up: the podman plugin.

Frequently asked questions