{"id":169030,"date":"2026-06-18T04:15:48","date_gmt":"2026-06-18T01:15:48","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=169030"},"modified":"2026-06-18T04:15:48","modified_gmt":"2026-06-18T01:15:48","slug":"cockpit-web-console-opensuse-leap","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/cockpit-web-console-opensuse-leap\/","title":{"rendered":"Manage openSUSE Leap with Cockpit: the YaST Replacement"},"content":{"rendered":"

YaST is gone in openSUSE Leap 16, and the replacement most administrators reach for day to day is Cockpit<\/a>, 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.<\/p>\n\n

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.<\/p>\n\n

What Cockpit replaces, and what it does not<\/h2>\n\n

Leap 16 split the old YaST monolith<\/a> 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.<\/p>\n\n

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<\/a> covers where each one fits.<\/p>\n\n

Confirm Cockpit is installed and running<\/h2>\n\n

On a default Leap 16 install Cockpit is already present. Confirm the packages before you do anything else:<\/p>\n\n\n

rpm -qa 'cockpit*'<\/code><\/pre>\n\n\n
You should see the web service, the bridge, and the core modules already in place:<\/p>\n\n\n
cockpit-ws-354-160000.3.1.x86_64\ncockpit-bridge-354-160000.3.1.noarch\ncockpit-system-354-160000.3.1.noarch\ncockpit-storaged-354-160000.3.1.noarch\ncockpit-networkmanager-354-160000.3.1.noarch\ncockpit-packagekit-354-160000.3.1.noarch<\/code><\/pre>\n\n\n
If 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<\/code> meta package only brings the bridge, system, and web service, so name the modules you want explicitly:<\/p>\n\n\n
sudo zypper install cockpit cockpit-storaged cockpit-networkmanager cockpit-packagekit<\/code><\/pre>\n\n\n
Cockpit 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:<\/p>\n\n\n
sudo systemctl enable --now cockpit.socket<\/code><\/pre>\n\n\n
Confirm the socket is listening:<\/p>\n\n\n
systemctl is-active cockpit.socket<\/code><\/pre>\n\n\n
A healthy socket reports active and binds port 9090:<\/p>\n\n\n
active<\/code><\/pre>\n\n\n
Leap 16 runs firewalld by default, so open the dedicated Cockpit service before you try to connect from another machine:<\/p>\n\n\n
sudo firewall-cmd --permanent --add-service=cockpit\nsudo firewall-cmd --reload<\/code><\/pre>\n\n\n
The 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.<\/p>\n\n
Open the web console and sign in<\/h2>\n\n
Point a browser at port 9090 on the server, over HTTPS:<\/p>\n\n\n
https:\/\/10.0.1.50:9090<\/code><\/pre>\n\n\n
Cockpit 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.<\/p>\n\n\n
\"Cockpit<\/figure>\n\n\n
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.<\/p>\n\n
Read the system at a glance<\/h2>\n\n
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.<\/p>\n\n\n
\"Cockpit<\/figure>\n\n\n
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.<\/p>\n\n
Manage systemd services<\/h2>\n\n
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.<\/p>\n\n\n
\"Cockpit<\/figure>\n\n\n
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.<\/p>\n\n
Work with storage and Btrfs snapshots<\/h2>\n\n
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.<\/p>\n\n\n
\"Cockpit<\/figure>\n\n\n
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<\/a> walks through.<\/p>\n\n
Keep the system patched<\/h2>\n\n
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.<\/p>\n\n\n
\"Cockpit<\/figure>\n\n\n
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<\/a> 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.<\/p>\n\n
Troubleshoot SELinux without leaving the browser<\/h2>\n\n
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:<\/p>\n\n\n
sudo getenforce<\/code><\/pre>\n\n\n
On a default Leap 16 install this returns enforcing:<\/p>\n\n\n
Enforcing<\/code><\/pre>\n\n\n
The SELinux module is not part of the base console, so install it and reload the socket to pick it up:<\/p>\n\n\n
sudo zypper install cockpit-selinux\nsudo systemctl restart cockpit.socket<\/code><\/pre>\n\n\n
The SELinux page then shows the current policy state and, more usefully, any access-control denials the kernel has logged.<\/p>\n\n\n
\"Cockpit<\/figure>\n\n\n
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.<\/p>\n\n
Run commands in the built-in terminal<\/h2>\n\n
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.<\/p>\n\n\n
\"Cockpit<\/figure>\n\n\n
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.<\/p>\n\n
Add the optional modules you actually need<\/h2>\n\n
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:<\/p>\n\n