[lxc-devel] symbolic link for /var/lib/lxc

[Serge Hallyn]

Quoting Harald Dunkel (harald.dunkel at aixigo.de):
> Hi Serge,
> 
> On 07/23/15 15:12, Serge Hallyn wrote:
> > Quoting Harald Dunkel (harald.dunkel at aixigo.de):
> >>
> >> My suggestion would be to use the "real" lxcpath (resolving
> >> all the symlinks and .. and .) for constructing the abstract
> >> socket name.
> > 
> > Well that's true, perhaps lxc should do a realpath on the lxcpath.
> > Patch for that would be welcome.  Note though that if realpath
> > fails, then you should simply take what was given - because it is
> > not required that lxcpath actually exist.
> > 
> 
> I never tried that. If the target for lxcpath is optional, then
> what is $lxcpath needed for, besides creating the abstract socket
> name?

At create time it may be where the confg file is.  (Though it doesn't
have to be, the lxcpath may not exist and you can set configuration
through the api).  At runtime it's indeed where the command socket is
found.

> >>> Since a container named 'lxchost01' could exist and be running
> >>> in 5 different lxcpaths at the same time, we can't really avoid
> >>> this.  (that is, it has to be the case that the lxcpath matters)
> >>>
> >>
> >> I am not sure if I got this correctly, but afaics you can specify
> >> only one lxcpath for running lxc-create. At least 4 of the 5
> >> lxcpaths you mentioned include symbolic links or constructs like
> > 
> > Sorry - 5 lxcpaths that I mentioned where?
> > 
> 
> A few lines above: "5 different lxcpaths at the same time". This
> is just a single container "lxchost01", right?

No, 5 different containers with the same name.

> >> "subdir1/./..", etc., but don't they all point to the same inode
> >> under the same mount point?
> > 
> > No, I have containers named t1 under /var/lib/lxc, /var/lib/lxd/lxc,
> > ~/.local/share/lxc, and maybe /usr/local/var/lib/lxc - they're all
> > different containers.
> > 
> 
> Sure, but these are *several* containers, each with their own socket.
> Very important feature.

It's what I was talking about.

> > But yeah, regarding symlinks you're right that we could readlink
> > to fix that a bit.  That would solve a part of your problem -
> > but it won't help if you do
> > 
> > 	lxc-start -n t1
> > 	mv /var/lib/lxc /var/lib/lxcc
> > 	ln -s /var/lib/lxcc /var/lib/lxc
> > 
> 
> I wouldn't dare to do this.
> 
> Another problem not mentioned before is a bind mount of an lxcpath
> to another point in the filesystem. This would be very hard to detect.

Indeed.

-serge