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 ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
