[lxc-devel] Use container specific domain socket name

[Daniel Lezcano]

On 04/11/2013 09:53 AM, Stéphane Graber wrote:
> On 04/11/2013 09:18 AM, Jäkel, Guido wrote:
>> I also think that "LXC should have as less dependencies as possible to ease the support for different plattforms" has more weight than "don't invent things twice".
>>
>> quoting Daniel Lezcano:
>>> I think the solution to solve this issue is to use the AF_INET protocol
>>> on the loopback using the loopback's broadcast address and filter the
>>> messages with the container name. The code should be 'trivial'.
>> May this concept be enhanced in the way that the sender and the receiver don't need to settle on the same host (by using an optional user defined the broadcast address -- the hosts net one)? This may offer the possibility to centralize additional monitoring of actual container states on another completely other host. May it be wise to add the name of the host to the messages?
>>
>> In my personal use case -- a farm with identical LXC hosts and NFS-based filesystems offering to start an container on any of it -- this might offer the possibility to query if an container is already up anywhere. In the moment, i'm using heurisitics like pinging the containers base address or checking some timestamps on the containers rootfs for this.
>>
>>
>> greetings
>>
>> Guido
> If we're using broadcast on loopback, then no, it won't be very trivial
> to have this made available on a unicast address and frankly I wouldn't
> recommend this for security reasons.

Yes, as we are doing broadcasting, then we have to use UDP and with the
loopback we have the guarantee we don't lose packets (modulo buffer
overflow which can be easily detected with a sequence number). The
approach is self contained.

The need of Jakel makes perfectly sense and IMO, that should be build on
top of lxc. A daemon "lxcd" supervising all the containers and being
accessible from the network could be done. That will be a centralized
processing of the containers, where the network and the security aspect
could addressed based on a publish/subscribe mechanism.


> We can identify the source of the network traffic on the loopback device
> (source PID, source UID) but not on something coming from the network,
> with commands coming from outside the machine, we'd need the usual mess
> of SSL + authentication which I don't think we want to implement in LXC.
>
> I think your best bet for remote control of LXC containers is to wait
> until we have our own libvirt driver (libvirt-lxcapi) which is on the
> roadmap for 1.0, then use libvirt's network interface to control your
> LXC containers.

Yes, this is another alternative.

Thanks
  -- Daniel