• Leigh B Stoller's avatar
    No longer return tunnel info to containers; just plain interfaces. · bd2964e2
    Leigh B Stoller authored
    Neither OpenVZ or XEN containers can do anything with the tunnel info,
    since tunnels are created in the root context and all the container
    sees is an interface. We have a hack in the client side for openvz,
    but rather then try to duplicate that hack for every XEN guest, lets
    do this the right way, and return plain ifconfig lines from tmcd and
    config them like any other interface. Since we rely on MAC addresses
    to do this, we now return MACs to the root context when it gets the
    tunnel info.
    
    To do this we need to know the difference between the root context
    asking for info *about* the container, and the container asking for
    its *own* info. Since both XEN and OpenVZ containers are redirected
    through the tmcc proxy, I changed the protocol so tmcd can tell who is
    asking. This is imperfect, since we might someday want the container
    to bypass the proxy, but for now it will do.
    
    The other consideration is that a XEN container might have requested a
    public IP, in which case it could actually do all of the tunnel stuff
    itself, but then again we have to worry about all of the guests being
    able to do tunnels, and so the easiest thing to do is just always do
    it in the root context for the container.
    bd2964e2
Name
Last commit
Last update
..
myplc Loading commit data...
newtmcd Loading commit data...
GNUmakefile.in Loading commit data...
libtmcd.c Loading commit data...
libtmcd.h Loading commit data...
mod_tmcd.c Loading commit data...
newtmcd.c Loading commit data...
tmcd.c Loading commit data...
tmcd.restart.in Loading commit data...