Feature: Cockpit Container

Goal: Deliver Cockpit in a Container

Pull a docker container and run cockpit
What would it take to make Cockpit run really well from a container and be able to configure and control both the server the container is running on, and other servers.
Previously we've delivered half-hearted containers, this goes beyond that.
Non-goal: This is not about running Cockpit anywhere.
- We must be ready to run on the target operating system, including architecture, version, assumed dependencies.
Non-goal: This won't replace the better way of running Cockpit: having Cockpit delivered with the operating system.

General brainstorming area ... broken out into specifics below

Ultimately, the browser might be the component that downloads the missing UI resources from the general Internet. (mvollmer).

How do we handle the case if the bridge is not installed.

Copy the bridge into the homedir or more likely $XDG_RUNTIME_DIR and run it from there
Likely reduce the dependencies of the bridge only depends on glib and glibc.
Likely reduce the bridge so it's just one file
- Package reauthorize stuff separately, expect it on the target operating system.
  - Make it part of polkit itself?
Container would need to have cockpit-bridge built for multiple archs?

If no shell package on target system, assume that cockpit packages have not been installed
Have cockpit-bridge be able to send cockpit-ws information about the target operating system
Ability for cockpit-ws (in the container) to pick a set of packages from its own cache relevant to target operating system.
Still pluggable? Or do we say that only Cockpit running on host is pluggable.

What do we need to be a privileged container for?

Can we run cockpit as an uniprivileged container since we're SSH'ing into the system as our means of gaining access?
- How would we ssh into localhost, local machine?