YaST is gone in openSUSE Leap 16, and the replacement most administrators reach for day to day is Cockpit, a web console that ships in the default install. The decision Cockpit makes for you is a sensible one. Instead of a heavy, always-running admin stack, you get a lightweight service that activates only when you open it in a browser, then drives the system through the same APIs you would script by hand.
We ran every step below on an openSUSE Leap 16 server in June 2026, so the console layout, the package names, and the SELinux behavior match what you will see. This guide gets Cockpit running, then walks the parts you will actually use: the system overview, services, storage with Btrfs snapshots, software updates, SELinux troubleshooting, the built-in terminal, and finally how to expose the console safely for remote administration.
What Cockpit replaces, and what it does not
Leap 16 split the old YaST monolith into focused tools. Agama is the new installer, Myrlyn is the graphical package manager, and Cockpit is the running-system administration console. That division matters when you plan your workflow, because Cockpit is deliberately not a one-to-one YaST clone. It covers the operational surface (services, storage, networking, accounts, logs, updates, SELinux, a terminal) and leaves installation to Agama and bulk package browsing to Myrlyn or zypper.
The trade-off is worth stating plainly. Cockpit is excellent for the daily operational tasks and for giving a junior admin a safe, auditable view of a box. It is not where you do a complex storage migration or a fine-grained AutoYaST-style mass configuration. For that you still drop to the shell, which Cockpit conveniently gives you in the browser. The same console and the same modules run on SUSE Linux Enterprise Server 16, so what you learn here carries straight over to the paid platform. If you are still weighing the editions, our Leap, Tumbleweed, and SLES comparison covers where each one fits.
Confirm Cockpit is installed and running
On a default Leap 16 install Cockpit is already present. Confirm the packages before you do anything else:
rpm -qa 'cockpit*'You should see the web service, the bridge, and the core modules already in place:
cockpit-ws-354-160000.3.1.x86_64
cockpit-bridge-354-160000.3.1.noarch
cockpit-system-354-160000.3.1.noarch
cockpit-storaged-354-160000.3.1.noarch
cockpit-networkmanager-354-160000.3.1.noarch
cockpit-packagekit-354-160000.3.1.noarchIf this is a minimal or server-role install and the packages are missing, pull in the console plus the storage, networking, and updates pages in one command. The base cockpit meta package only brings the bridge, system, and web service, so name the modules you want explicitly:
sudo zypper install cockpit cockpit-storaged cockpit-networkmanager cockpit-packagekitCockpit is socket-activated, which is the resource win mentioned earlier: the web service does not sit idle consuming memory, it spins up when the first connection arrives. Enable the socket so it is ready on boot:
sudo systemctl enable --now cockpit.socketConfirm the socket is listening:
systemctl is-active cockpit.socketA healthy socket reports active and binds port 9090:
activeLeap 16 runs firewalld by default, so open the dedicated Cockpit service before you try to connect from another machine:
sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reloadThe console is now reachable on port 9090 from any machine on the network. The remote-access section at the end of this guide narrows that exposure once you move past the local LAN.
Open the web console and sign in
Point a browser at port 9090 on the server, over HTTPS:
https://10.0.1.50:9090Cockpit serves a self-signed certificate out of the install, so the browser warns once on a fresh box. That is expected for a local admin console on the LAN; the remote-access section at the end replaces it with a trusted certificate. Sign in with a regular system user that has sudo rights, not root.
After login, Cockpit starts in limited access mode. The toggle in the top right escalates to administrative access by reusing your password, and that is the difference between viewing the system and changing it. Escalate when you need to start a service or edit storage, and stay limited when you are only looking.
Read the system at a glance
The Overview page is the landing screen and the fastest health check you have. It shows CPU and memory load, the machine identity, uptime, and the configuration shortcuts (hostname, system time, performance profile, cryptographic policy) that used to live in separate YaST modules.
The “View metrics and history” link is the one to remember. It opens a time-series view of CPU, memory, disk, and network that is enough to catch a runaway process or a memory leak without installing a full monitoring stack. For a single box or a handful of servers, that built-in history often answers the question before you reach for Prometheus.
Manage systemd services
The Services page lists every systemd unit with its active and enabled state, split across Services, Targets, Sockets, Timers, and Paths. The filter row narrows by name or by state, which is how you find the one failed unit in a list of two hundred.
Click any unit to open its detail page, where you start, stop, restart, enable, or disable it, and read its recent journal output inline. In practice this means a colleague can recover a stuck service from the browser without learning the full systemctl and journalctl vocabulary first, while every action they take is still a normal systemd operation you can audit.
Work with storage and Btrfs snapshots
Storage is where Cockpit earns its place on a Leap box, because Leap installs on Btrfs with Snapper by default. The Storage page draws the disks, partitions, filesystems, and mount points, with live read and write throughput graphs at the top.
Expand the Btrfs volume and you see the subvolume tree, including the Snapper snapshots under the snapshots subvolume. That is the visual companion to the command-line rollback workflow: Snapper still takes the automatic pre and post snapshots around each zypper transaction, and Cockpit lets you see them and the space they consume. When you do need to roll back a bad update, you still do it from the boot menu and the shell, which the post-install guide walks through.
Keep the system patched
The Software Updates page is the packagekit front end. It checks the repositories, lists the available updates with their versions and severities, and lets you apply them individually or all at once.
For interactive patching this is fine, and the severity column helps you prioritize security fixes. For anything scripted or scheduled, the command line is still the right tool, and the zypper command reference covers the patch and dup workflows. One caveat: on an immutable host like Leap Micro the regular updates page does not apply, because those systems update transactionally; there Cockpit uses a separate transactional-update module instead.
Troubleshoot SELinux without leaving the browser
This is the section that justifies adding a module, because Leap 16 is one of the rare SUSE systems that ships with SELinux in enforcing mode by default. Confirm the mode from the shell first:
sudo getenforceOn a default Leap 16 install this returns enforcing:
EnforcingThe SELinux module is not part of the base console, so install it and reload the socket to pick it up:
sudo zypper install cockpit-selinux
sudo systemctl restart cockpit.socketThe SELinux page then shows the current policy state and, more usefully, any access-control denials the kernel has logged.
When a denial appears, each alert carries a “View automation script” button that turns the denial into the exact policy adjustment that allows it. That is the feature to lean on: instead of telling readers to disable SELinux when a service misbehaves, which is the wrong fix, you read the denial here and apply the targeted rule. Enforcing stays on, and the service works.
Run commands in the built-in terminal
Cockpit ships a full terminal in the browser, scoped to the logged-in user. It is the pressure valve for everything the graphical modules do not cover, and it means a remote session over the console alone is enough to administer the box end to end.
The terminal runs as your user, so privileged commands still need sudo, exactly as they would over SSH. Treat it as a convenience for quick checks and one-off fixes rather than a replacement for a proper SSH session in a real terminal multiplexer when you are doing sustained work.
Add the optional modules you actually need
The base install is intentionally lean. Cockpit’s functionality grows through add-on packages, and because the web service is socket-activated, installing a module you use occasionally costs nothing while it sits idle. The ones worth knowing:
cockpit-podmanmanages Podman containers and images from the console.cockpit-machinesadds a libvirt and KVM virtual-machine manager.cockpit-selinuxis the SELinux troubleshooter covered above.cockpit-reposmanages the zypper repositories through the UI.cockpit-kdumpconfigures kernel crash dumps.
Install the set you want in one transaction, then reload the socket so the new pages appear:
sudo zypper install cockpit-podman cockpit-machines cockpit-repos cockpit-kdump
sudo systemctl restart cockpit.socketThe discipline here is to add only what that host actually does. A container host gets cockpit-podman, a virtualization host gets cockpit-machines, and a plain application server gets neither. Fewer modules means a smaller attack surface and a cleaner console.
Expose Cockpit safely for remote administration
Port 9090 on a self-signed certificate is fine inside a trusted LAN, but it is not what you want facing the internet. There are two clean ways to reach a console remotely, and they suit different needs.
The simplest is to not expose Cockpit at all and tunnel over SSH instead. From your workstation, forward the local port to the server and browse to the local end:
ssh -L 9090:localhost:9090 [email protected]With that session open, https://localhost:9090 on your machine reaches the console over the encrypted SSH channel, and nothing new is exposed on the server. For occasional administration this is the safest option because it adds no public listener.
When several people need browser access without an SSH client, put a reverse proxy with a real certificate in front. Install nginx and the Let’s Encrypt client:
sudo zypper install nginx certbot python3-certbot-nginxCockpit refuses proxied connections from an unknown origin by default, so tell it which hostname to trust. Open its config:
sudo vim /etc/cockpit/cockpit.confAdd the origin and the forwarded-protocol header, replacing the hostname with your own:
[WebService]
Origins = https://cockpit.example.com wss://cockpit.example.com
ProtocolHeader = X-Forwarded-ProtoNow create the nginx virtual host. openSUSE loads server blocks from the vhosts directory:
sudo vim /etc/nginx/vhosts.d/cockpit.confThe proxy has to pass the WebSocket upgrade through, otherwise the terminal and live graphs hang. Use this server block, again substituting your hostname:
server {
listen 80;
server_name cockpit.example.com;
location / {
proxy_pass https://127.0.0.1:9090;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;
gzip off;
}
}Enable nginx and request the certificate. Certbot edits the vhost in place to add the TLS listener and the HTTP-to-HTTPS redirect:
sudo systemctl enable --now nginx
sudo certbot --nginx -d cockpit.example.comThis is the HTTP-01 challenge, which works with any DNS provider as long as the hostname resolves to the server and port 80 is reachable. If the box sits on a private network with no public port 80, switch to a DNS-01 challenge with your provider’s certbot plugin instead. Either way, finish by closing 9090 at the firewall so the console is reachable only through the proxy:
sudo firewall-cmd --permanent --remove-service=cockpit
sudo firewall-cmd --reloadWith that in place you reach the console at your own hostname on a trusted certificate, every request rides HTTPS, and the only public surface is the proxy you control. That is the configuration to run in production, and it scales the same way on SUSE Linux Enterprise Server 16 when you promote the host. For the wider first-day setup that surrounds this, the things-to-do-after-install guide and the Leap 16 install walkthrough are the companion pieces.
