Cockpit as a privileged container?

Stef Walter stefw at redhat.com
Tue Aug 12 14:22:47 UTC 2014


On 12.08.2014 15:51, Daniel J Walsh wrote:
> 
> On 08/10/2014 05:02 AM, Stef Walter wrote:
>> 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?
> We are working to add an environment variable that says container=docker
> in all Fedora/RHEL images.  We are hoping to
> get this ability upstream soon.  If your question was about /sysroot for
> the host, I guess the closest thing to a standard is anaconda and
> libguesfs.  But those two do not agree.   I think someone in your group
> suggested /host.
>>
>>> 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.
> Well stuff in /usr/lib64 is also probably used and any parts of
> coreutils you take use.  Potentially some configuration
> you might want shipped within a container.

Cockpit has two kinds of dependencies:

 * Some basic libraries it uses to run.
 * The stuff it actually uses to manage the system, like NetworkManager
   udisks, docker, etc...

The latter would need probably need to run outside the privileged
container ... or be privileged-container capable itself.

>>> 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
> You could mount / at / theoretically, but I believe as soon as you did
> this your app would loose its shared libraries and could start acting
> strange.

Could intelligent use of LD_LIBRARY_PATH be used to solve this?

Stef



More information about the cockpit-devel mailing list