Bootstrapping a network of Cockpit managed machine

Introduction

Cockpit consists of roughly two parts: the interface and the agent. The interface is a web application running in a browser. The agent is a daemon accessed by the interface, via SSH or locally.

In a Cockpit managed network of machines, any machine can normally provide the interface and any machine can normally access the agent on any other machine.

Requirements

To provide the interface, a machine must

• have the "cockpit" package
• have a valid certificate for HTTPS
• have the Cockpit TCP port open

To provide access to the agent, a machine must

• have the "cockpit" package
• have the SSH port open
• have user accounts with the same password as the accessing machine

A machine may benefit from

• being able to retrieve packages from RHN/RHUI/Satellite/yum repo
• being registered in a FreeIPA/RHIdM domain for SSH key management/server certificate dispatch
• being registered in a Red Hat Satellite to offer Cockpit from Satellite (wish list)
• advertise its existence and configuration via OpenSLP

Q: what about other centralized authentication means?

Approach

Each interface server has a local database of known machines and their group memberships. This database can be managed explicitly via the interface. We try to keep the databases of multiple interface servers synchronized (via undecided means).

The dashboard is constructed from the database of the interface server. For now, we only have a single "dashboard" group and Cockpit just tries to connect to the agent on all machines in that group.

The user can explicitly add a machine to the dashboard group by giving its IP address or DNS name or picking it from a list of machines that have been discovered by OpenSLP.

Making a machine ready to be used with Cockpit happens in two phases: installation plus basic configuration, and initial setup.

The first phase, installation and basic configuration happens without help from Cockpit as part of the normal OS installation or as part of basic package management. Nothing more than "yum install cockpit", really.

The result is:

• Cockpit code is available in a suitable version for the OS, including cockpit-ws, cockpit-agent, and cockpit-setup.

• realmd is installed.

• SSH is accessible on port 22.

• OpenSLP is configured and the machine advertise the "cockpit" service.

• Cockpit-ws is not enabled, there is no TLS certificate for it, and the Cockpit TCP port is firewalled.

The second phase, initial setup, is performed by the cockpit-setup utility. It must be run as root and can either be used interactively or non-interactively. It takes care of:

• Setting a hostname

• Joining a domain

• Acquiring a TLS certificate

• Opening the firewall for the Cockpit TCP port

• Synchronizing user accounts

The utility can be run interactively from the command line. This is typically done on the first machine in a network.

It can also be run non-interactivly under control of Cockpit. This is done when adding a machine to its first group.

The utility can be run 'dry', where it outputs what would be done without actually doing it. This is used to let the user confirm potentially destructive actions when it is run from Cockpit.

TLS certificates are either acquired by joining a domain or created by a self-signed, ad-hoc CA.

Joining a domain non-interactively is done with a one-time-password.

[...]

Work items

• OpenSLP discovery

  Find machines and their properties via OpenSLP, exposing the result on D-Bus.

  We will always have a connection to the machine serving the interface, even if it is not itself currently being managed.

  The login dance is reverted to its old pattern: To login to Cockpit, we try to open a websocket to "localhost". If it succeeds, we get the configuration via D-Bus from that websocket.

  We store a list of discovered machines (and their groups) on each interface machine. Machines can be added and removed explicitly via D-Bus. Machines discovered via OpenSLP are added. Explicit management takes precedence over OpenSLP discovery. (Ouch, distributed consistency...)

• SSH hostkeys

  We need to be able to check and store SSH hostkeys, much like the ssh command line utility.

• Script execution via raw SSH

  Without using any websocket stuff, we should be able to SSH to a machine, run our script there, and somehow nicely present the progress and outcome.

  We might spice up the existing rescue terminal to stream the output of a command.

• Interactive cockpit-setup

  [...]

• Non-interactive cockpit-setup, dry-run, UI for it.

  [...]