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
Received on Tue Nov 30 12:31:55 2010