openSUSE:ALP/Workgroups/SysMngmnt/Cockpit

Jump to: navigation, search

Goal

The ALP System Management work group did some research and created a document containing the conclusions of such a research and the plans and commitment for the first ALP prototype on September 2022: conclusion.md

As part of the result, the work group is trying to make Cockpit a worth default system for 1:1 management of ALP systems.

Status

Updated: 2022-10-20

  • Done
    • Recent version of Cockpit, including (open)SUSE branding, available at TW and ALP.
    • Cockpit's web server containerized and available as an ALP Workload.
    • Documented installation and status of Cockpit at ALP (see next section)
    • Fixed several issues affecting Cockpit on ALP (metrics management, Kdump compatibility, packaging issues, tools compatibility...)
    • Documented many aspects of the state of the art regarding system management, Cockpit, ALP and transactional systems in general.
  • Doing
    • Better check for firewalld permissions
  • Planned:
    • Help to develop an official mechanism to theme Cockpit (without our current patches). See https://github.com/cockpit-project/cockpit/issues/16359.
    • Fix several things that doesn't work well in Cockpit with transactional systems
    • Make cockpit-machines work with containerized libvirt
    • Rethink our Cockpit packaging from scratch
  • For more (scattered) details, see blog posts: 2022-07-19, 2022-08-02, 2022-08-23, 2022-09-06, 2022-09-22, 2022-10-20

Cockpit at ALP

This section describes how to use Cockpit on ALP and the challenges that still need to be solved to make the installation and usage of Cockpit a completely straightforward experience on ALP.

Based on experience with ALP-0.1-Build13.5.

The pattern alp_cockpit is installed by default in the image. It contains the basic components to administer the system with Cockpit, but it does not include the Cockpit's web server that provides the user interface. Notice you don't need the Cockpit's web server installed in every single machine since one instance of the web interface can be used to connect to several hosts, as long as all of them have the basic alp_cockpit pattern installed. In any case, if you are administering several machines consider using a tool designed for multi-machine administration like Salt, Ansible or Uyuni (SUSE Manager).

Deploying the Cockpit's Web Server

There are two ways to deploy the web server in an ALP machine:

  • as a container from the repository of ALP workloads
  • installed via packages right into the ALP system

The first one is more convenient in most situations since it does not imply modifying the base system, which in the case of a transactional systems like ALP can have several consequences like the need to reboot the system. On the other hand, it uses SSH to connect to the managed system which also has some implications (see below).

After installing the web server with your preferred method, just connect with a web browser to https://ip-or-name-of-your-alp:9090/, accept the self-signed certificate and login with the credentials of any user of the ALP system.

Run the Web Server as a Containerized Workload

When the containerized web server is used, authentication through the web interface will be performed using SSH under the hood. By default, the root user cannot open an SSH session so there must be a non-root user in the managed system that can login via password. As a less secure alternative, the SSH server can be configured to allow password login for root.

To install and run the container automatically on every boot: 

  podman container runlabel INSTALL registry.opensuse.org/suse/alp/workloads/tumbleweed_containerfiles/suse/alp/workloads/cockpit-ws:latest
  systemctl enable --now cockpit.service

It's also possible to fetch and run the containerized Cockpit's web server only once: 

  podman container runlabel --name cockpit-ws RUN registry.opensuse.org/suse/alp/workloads/tumbleweed_containerfiles/suse/alp/workloads/cockpit-ws:latest

Install the Web Server Via Packages

As an alternative, the Cockpit web front-end can be directly installed via packages in the ALP system. 

transactional-update pkg install cockpit-ws
reboot
systemctl enable --now cockpit.socket

Of course, systemctl start can be used instead of systemctl enable in order to execute the web server only once and not on every boot.

When installing from packages, authentication is performed locally which implies the root credentials can be used to login into the web interface, although it may not be the ideal security setup.

Adding More Functionality to Cockpit

With the selection of packages installed by the alp_cockpit pattern, there is quite some functionality available out-of-the-box. But it can be expanded by installing additional Cockpit extensions.

Metrics

To enable the visualization of some current metrics, install the PCP Cockpit extension. 

transactional-update pkg install cockpit-pcp
reboot

That Cockpit extension also provides the possibility of displaying historical metrics. For that to work, some configuration may be needed in the system, but it can be easily done with some clicks in the Cockpit user interface.

Software Updates

The package cockpit-tukit can be used to perform transactional software updates. To install it, use the following commands: 

transactional-update pkg install cockpit-tukit
reboot

Management of kdump

Installing the Cockpit extension for Kdump allows to start and stop the Kdump service (although the service is only useful if Kdump was configured previously, something that Cockpit cannot do) and to change the location and the format of the dump file. To install the extension just do the usual: 

transactional-update pkg install cockpit-kdump
reboot

DEVELOPMENT NOTE: Robert Simai's team is enhancing cockpit-kdump compatibility with (open)SUSE. Progress tracked at https://jira.suse.com/browse/CSD-192 (SUSE internal link) and https://trello.com/c/orCGQkPg/49-follow-cockpit-kdump-enhancements-to-include-them-at-alp

Management of Storage Devices

To manage local storage devices and its associated technologies, install the Storaged Cockpit extension. 

transactional-update pkg install cockpit-storaged
reboot

Currently, this only works 100% on the unofficial non-transactional variant of ALP. Several operations are unreliable in the default transactional ALP.

Management of Virtual Machines

The package cockpit-machines allows to manage libvirt artifacts like storage pools, networks and virtual machines.

Installing the package can be easily done with: 

transactional-update pkg install cockpit-machines
reboot

After installation, it may happen that clicking on the "Virtual Machines" section of Cockpit results in a message similar to "Virtualization Daemon (libvirt) is Not Active". That can be solved easily by enabling (or simply starting) the service libvirtd, which can be done in the "Services" section of Cockpit.

DEVELOPMENT NOTE: the plan for ALP is to run the libvirt stack containerized. At the moment of writing, that is available as the kvm container at the ALP workloads repository. That means we should reconsider how we ship cockpit-machines in the future. We maybe will need to base it on that containerized libvirt instead of RPM libvirt packages installed on the ALP system. Tracked at https://trello.com/c/IghVKGez/50-make-cockpit-machines-work-with-containerized-libvirt

How to installing cockpit-machines on ALP OS without any dependencies (devel purpose)

As the system use transactional-update to install packages, you can not install packages without dependencies. A workaround is possible with the shell option: 

transactional-update shell
...
2022-09-26 14:39:39 Executing `bash`:

Download the cockpit-machines package and install it with rpm command, and exit the transactionnal-update shell: 

zypper download cockpit-machines
rpm -vhi /var/cache/zypp/packages/repo-oss/noarch/cockpit-machines-270.2-2.1.noarch.rpm --nodeps
exit

Reboot your system to use latest snapshot wich contains the installed cockpit-machines package: 

transactional-update reboot
reboot


DEVELOPMENT NOTE: Currently cockpit-machines only connect localy: in the src/config.js file there is a qemu:///system. Moreover there is a mechanism to get the state of the libvirtd which needs to be adjusted or a blank page will be displayed.

Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:ALP/Workgroups/SysMngmnt/Cockpit&oldid=170287"