Re: [vserver] "http://repo.psand.net/ lenny main" debian repository : util-vserver-basic-debian package error => "/var/lib/vservers/.: Function not implemented"

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)?

/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

> 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).

corey

-- 
undefined@pobox.com