Subject: Re: [vserver] "http://repo.psand.net/ lenny main" debian repository : util-vserver-basic-debian package error => "/var/lib/vservers/.: Function not implemented"
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Tue, 30 Nov 2010 13:31:07 +0100

On Tue, Nov 30, 2010 at 01:40:11AM -0600, Corey Wright wrote:
> feel free to ignore my below input, as i have no intentions of using your
> debian packages (i backport the official debian package instead), but just
> to provide an alternate perspective.

> On Mon, 29 Nov 2010 11:45:02 +0100
> Ghislain <gadnet@aqueos.com> wrote:

> > > This is a problem with the package util-vserver-basic-debian. If it
> > > isn't installed on an already existing vserver kernel, it won't work.
> > > I think Ghislain who builds those packages might be interested in
> > > sorting that out.

> > > The workaround is to reboot with the new kernel (which installed fine
> > > for you), then to run

> > > apt-get -f install

> > > to get the utils installed.

> > > Cheers,
> > > ==
> > > From Ben Green

> > yes perhaps i should simply refuse to install on non vserver enabled
> > kernel. Do you see any useful scenario where the util should install on
> > a non vserver enabled kernel ?

> yes: i install debian and later install a vserver-enabled kernel and the
> utils... but you want me to first install the vserver-enabled kernel,
> reboot, and then install the utils?

> > with kernel that are not enable barrier setting fails

> so don't set the barrier on non-vserver-enabled kernels.

> /etc/init.d/util-vserver:98 "if [ -e /proc/self/vinfo ]"

> > and therefor the
> > user is responsible to create it later

> why not automate it for the user on every restart (in case the user
> creates a new guest or moves one since he installed your package and
> you set the barriers)?

what if the user doesn't want to have the barrier set for
a certain directory containing a guest?

> /etc/init.d/util-vserver:127-138
> 
> # Then set the chroot barrier
> for vserver in `ls /etc/vservers` 
> do 
>     vdiractual=`readlink -f /etc/vservers/$vserver/vdir` 
>     if [ -d "$vdiractual" ]
>     then
>         setattr --barrier $vdiractual/..
>     fi
> done

> vrootactual=`readlink -f /etc/vservers/.defaults/vdirbase`
> setattr --barrier $vrootactual $vrootactual/.pkg $vrootactual/.hash

what's the idea behind that?

> > that seems to me a security issue
> > as no one will do it . So i think i will simply prevent any install
> > on non enabled kernels if no one has any other advice on this.

> i don't disagree that the user will be unlikely to set the barrier(s)
> himself, so why not do it for him and allow it for non-enabled kernels
> too, but test for the kernel capability at run-time (otherwise either
> you blindly assume that the user has a vserver-enabled kernel or you
> require the user to exclusively use/install your vserver-enabled
> kernels; both are suboptimal and avoidable).

personally I'd prefer a check and warning over this
automated behaviour anytime, I don't like runlevel
scripts which think they are smarter than the admin

but OTOH, I do not care that much as I don't use
debian or the packages in question ...

best,
Herbert

> corey
> -- 
> undefined@pobox.com