Cockpit as a privileged container?

Stef Walter stefw at redhat.com
Sun Aug 10 09:02:05 UTC 2014


On 09.08.2014 01:04, Colin Walters wrote:
> On Fri, Aug 8, 2014, at 11:57 AM, Stef Walter wrote:
>>
>> So to summarize this... Do you know of anyone who's tried this stuff out
>> with Cockpit? Interested in the results in any case, and open to patches
>> that help make it work.
> 
> I don't offhand.  One way to approach this might be to mount the host
> file system at /sysroot or something in the container.  The cockpit
> would have to conditionalize itself and say: Am I in a container? 

Is there a standard way to do this on Linux?

> Look
> at /sysroot/proc.

So I guess you're mostly talking about cockpit-agent here, although
cockpit-ws would also need to some how trick PAM into looking at the
/sysroot/etc/pam.d path ... But I guess that could be via a symlink.

I guess that also when we connect to such a system via ssh, we would
have to run the cockpit-agent command at a different path? What would
that path be?

> Though that might get untenable for things like systemd APIs that are
> basically just wrappers around looking at files in /run.  

We would probably have to symlink /run to /sysroot/run

In fact the only interesting parts of the cockpit container file system
would be /usr/libexec/cockpit-* and /usr/share/cockpit.

> Maybe flip it around and try to have cockpit-in-container have its data
> all isolated in /usr/lib/cockpit (including the binaries).
> 
> On the other hand - if we made Cockpit work in this pattern, I'd say it
> would work for any management agent / config system / etc.

Right. So how does this work in real life (for example with Docker). Is
there a way to just remount / with a bind mount into the container at /
and then remount the container file system in an alternate place?

Stef



More information about the cockpit-devel mailing list