[Pkg-sysvinit-devel] Bug#633845: initscripts: unupgradeable on vserver

[Roger Leigh]

On Thu, Jul 14, 2011 at 04:27:16PM +0100, Roger Leigh wrote:
> On Thu, Jul 14, 2011 at 03:11:12PM +0000, Clint Adams wrote:
> > On Thu, Jul 14, 2011 at 02:04:15PM +0100, Roger Leigh wrote:
> > > CCing Clint and Aurelien: Does this type of check belong in
> > > "ischroot", or would it need adding to a separate (e.g. "isvserver")
> > > tool?  Is the scope of ischroot limited to plain chroot(2) chroots,
> > 
> > Is the objective here to find out if one is running in a
> > "jailed" filesystem namespace but with full access to a
> > global process namespace?
> 
> It's mentioned earlier in the bug history.  Essentially, at least
> in the initscripts case, we don't want to bind mount filesystems
> (/var/run on /run) in the chroot case (since the rcS.d scripts
> won't run to complete the transition).  In the vserver case it's
> simply not possible to do any mounting inside the vserver, and so
> we need to treat it as if it was a chroot (I'm fairly sure it doesn't
> run rcS scripts either).
> 
> So our query is not exactly "is it a chroot?", but
> "does it run the rcS scripts".  Both chroots and vservers are "no"
> for both questions, so we are using the chroot check as a proxy
> for the rcS script question (since we can't find out directly).
> In our initial "guest_environment" shell function (which is what
> became ischroot IIRC) we also had logic to check for a vserver and
> treat it like a chroot.  Note that in a vserver, ischroot always
> fails because /proc/1/root is not readable, even by root, so we
> need to check /proc/self/vinfo instead.

Just a quick ping on this bug.

Are vservers now working OK with the current ischroot implementation,
or is further work needed here?


Thanks,
Roger


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800