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