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.comReceived on Tue Nov 30 07:41:50 2010