Re: [PATCH] send 'container=libvirt' in env to container init

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Eric Blake (eblake@xxxxxxxxxx):
> On 05/16/2011 09:14 AM, Serge Hallyn wrote:
> >>> @@ -112,6 +112,7 @@ static virCommandPtr lxcContainerBuildInitCmd(virDomainDefPtr vmDef)
> >>>  
> >>>      virCommandAddEnvString(cmd, "PATH=/bin:/sbin");
> >>>      virCommandAddEnvString(cmd, "TERM=linux");
> >>> +    virCommandAddEnvString(cmd, "container=libvirt");
> >>
> >> POSIX reserves lowercase env names for the user.  Is upstart really
> >> using a lower case name, or should this be an upper case name?
> > 
> > No upstart isn't doing anything itself :)  Just blame me - the upstart
> > scripts I put into lxcguest do in fact check for lower-case.
> > 
> > What do you mean by 'for the user'?  For the user to type into the
> > boot args, or something else?
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
> 
> Environment variable names used by the utilities in the Shell and
> Utilities volume of POSIX.1-2008 consist solely of uppercase letters,
> digits, and the <underscore> ( '_' ) from the characters defined in
> Portable Character Set and do not begin with a digit. Other characters
> may be permitted by an implementation; applications shall tolerate the
> presence of such names. Uppercase and lowercase letters shall retain
> their unique identities and shall not be folded together. The name space
> of environment variable names containing lowercase letters is reserved
> for applications. Applications can define any environment variables with
> names from this name space without modifying the behavior of the
> standard utilities.
> 
> That is, if your startup scripts make anything in the system, including
> /bin/sh, behave differently because it is in a container, then it's

Ah, this is about 'proper' environment variables.  But environment
variables are just being used to pass name=value boot arguments
to init.  So I wouldn't have thought this would apply.  It would
apply from the point of view of libvirt starting a program, but
not from the point of view of init trying to parse its command
line arguments.

Very interesting.  When you consider the init=/bin/sh case, I
can see where it would make sense.

> probably better to use an upper-case name, since /bin/sh should not
> behave differently regardless of what lower-case names are in the
> environment.
> 
> But this is a borderline case - upstart is outside the realm of POSIX,
> and you can easily arrange for $container to be reset before any
> standard applications are ever invoked from within the container.
> 
> >>>      virCommandAddEnvPair(cmd, "LIBVIRT_LXC_UUID", uuidstr);
> >>>      virCommandAddEnvPair(cmd, "LIBVIRT_LXC_NAME", vmDef->name);
> >>
> >> Can upstart be taught to look for LIBIVRT_LXC_UUID instead?
> > 
> > That's a possibility, yes.  It just makes it less symmetric to the
> > liblxc case, but if you prefer that I see no reason why it wouldn't
> > work.
> 
> Do you have a pointer to the liblxc code that's inspecting its environment?

Not liblxc - liblxc just sends 'container=lxc' to init.  One (of two)
of the upstart scripts which use that is here:

http://bazaar.launchpad.net/~serge-hallyn/ubuntu/natty/lxc/lxc-clone/view/head:/debian/lxcguest.lxcmount.upstart

thanks,
-serge

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]