Initial Setup, baby steps

Marius Vollmer marius.vollmer at redhat.com
Sat Dec 21 11:54:59 UTC 2013


Hi,

I found myself coming back to the issue of how to 'architect' Initial
Setup.

Initial Setup refers to the steps necessary to get a machine that
already has the "cockpit" package installed to the point where it can
be remotely managed in a browser.

We had two approches:

 - Run a script via ssh on the target machine.

 - Run a javascript program in the browser that talks to cockpit-agent
   on the target machine.

I started to work on the first approach, but my spidey senses made me
stop: There was too much stuff to figure out that would be easy to do
with the second approach, but required inventing new stuff (like data
formats and new communication mechanisms) with the first.  The second
approach also needs inventing new stuff, but that new stuff will
hopefully be useful outside of the Initial Setup as well.


IMO, Initial Setup is already a bit too complicated and interactive for
a script.  We need to run code locally and remotely, in more than one
phase:

 - collect data locally for use in checking (list of Cockpit users and
   their passwords, roles, joined domain)

 - check what needs to be done remotely (set hostname, sync users, join domain)

 - check what needs to be done locally (creating OTP for domain join,
   creating certificate without domain)

 - get confirmation from user, and collect missing parameters.

 - collect data locally for execution (user avatars)

 - do what needs to be done locally

 - do what needs to be done remotely

The steps above are not very precise, some can be combined, some might
not be necessary initially, or even ever.  Still, my feeling is that a
good Initial Setup experience requires more than just "run this script
as root on the target machine with these arguments".

The disadvantages of running the Initial Setup in the browser are of a
general sort:

 - The code comes from the machine running cockpit-ws, not from the
   machine being set up, so we need to figure out how to take the target
   OS version / configuration / etc into account.

 - We can't rely on the setup running to completion since the program
   in the browser can stop at any point.

 - Some sensitive information such as password hashes will pass
   through the browser.

We need to get these under control anyway, I'd say, and the Initial
Setup might not be 'perfect' before addressing them, but so is
everything else.


So...  Here's what I will do, until Stef makes me remember why it is a
bad idea. :-)

 * Allow to specify credentials when opening a web socket.  These
   would be used instead of the ones found via the session cookie.

   This feature would for now only be used for Initial Setup.
   Websockets made for machines on the Dashboard will only be able to
   use the session credentials.

 * Initial Setup will do two things only: set a hostname, and
   synchronize Cockpit users.

   The Cockpit users are all users on the local machine that are in
   one of the Cockpit role groups.

   Synchronizing a Cockpit user will make sure that it exists and that
   it has the same password as on the local machine.

   Creating a user will copy over the avatar and other bits, but if
   the user already exists, nothing will be changed.

   Nothing will be done about SSH keys (user or host), domains,
   certificates, and firewalls.


More information about the cockpit-devel mailing list