Bootstrapping a network of Cockpit managed machine

Terms

"Management server": Any machine running cockpit-ws and cockpit-agent. A management server manages itself and zero or more "managed systems".

"Managed system": Any machine running cockpit-agent that is to be managed by one or more external management servers.

Requirements

A management server must

• have the "cockpit" package
• have a valid certificate for HTTPS
• have the Cockpit TCP port open
• know the SSH host keys of all its managed systems

A managed system must

• have the "cockpit" package
• have the SSH port open
• allow login of certain users with the same credentials as the management server.

Approach

The basic thing is to figure out is which requirements to take care of from within Cockpit, and which to address externally, "somehow".

The basic guideline is that we do as much as possible from within Cockpit, and provide instructions for the rest.

From within Cockpit:

• know the SSH host keys of all its managed systems
• have the "cockpit" package (managed system)
• allow login of certain users with the same credentials as the management server.

Externally:

• have the "cockpit" package[0] (management server)
• have a valid certificate for HTTPS (management server)
• have the Cockpit TCP port open (management server)
• have the SSH port open (managed system)

We will have a utility to setup a management server. Setting up a managed system must work with the default OS installation, which we might need to tweak.

Implementation

Setup of a management server:

• A certificate is acquired by either joining a domain, by letting people import it explicitly, or by generating a self-signed one.

• The "cockpit" package is installed.

• The firewall is configured.

Setup of a managed system from within Cockpit:

• Ask for "setup credentials". Options might be "use my current credentials" which would use the user / password from the cookie and asking for a dedicated user / password.

• Cockpit logs in once with the setup credentials to install the "cockpit" package, if necessary, with some reasonably nice UI.

• Cockpit logs in again with the setup credentials and runs cockpit-session/cockpit-agent as usual.

• Cockpit offers to join the managed system to a domain.

• Cockpit offers to create missing users on the managed system. All users on the management server that are part of one of the Cockpit role groups are considered.

If any of this fails, the machine is still added to the list managed systems. The user can activate the setup procedure again from the machine menu.

Work items

• Managed system groups

  A authenticated user can manage a number of "managed system groups", both system-wide groups and user-specific groups.

  These groups are exposed and managed as D-Bus objects, which gives us notification, access control, etc in the usual way.

  The groups are on the D-Bus connection corresponding to the management server. Thus, we will always have a connection to the management server, even if that server 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 the management server. If it succeeds, we get the configuration via D-Bus from that websocket.

  If the management server happens to be in the current group of managed systems, we just use the existing websocket.

• D-Bus websocket with arbitrary credentials

  We should be able to simultaneously open multiple websockets to a given machine with different credentials. Thus the credentials should somehow be included in the weboscket connection request.

• SSH hostkeys

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

• Package installation via raw SSH

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

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

• User synchronization

  We should be able to export information about a user as a single value (dict) and be able to create a new, identical user from it on a different machine. The information should include the avatar.

• Setup wizard

  We need to pull all this together in a single "Setup" operation.

• Setup script for management servers.

• OpenSLP discovery

  Find machines via OpenSLP.

• OpenSLP advertisement

  A default Fedora installation advertises itself via OpenSLP.