On Tue, 30 Nov 2010 13:31:07 +0100 Herbert Poetzl <herbert@13thfloor.at> wrote: > 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? then feel free to modify the init script so that it doesn't set the barrier for particular directories (add an environment variable in /etc/default/util-vserver to contain directories you don't want the barrier set on and then test/grep that variable before setting the barrier on each directory) and submit your patch as a wishlist bug on the debian package. "patches welcomed" ;-) > > /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? i'm not sure about the .pkg and .hash, but i presume /etc/vservers/.defaults/vdirbase is set because that's the default base directory and in case no guest used the default (and therefor barriers had only been set on each guest-specific base), then a barrier still gets set on the default. > > > 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 feel free to delete the runlevels. "update-rc.d -f util-vserver remove". or if "update-rc.d" is too debian-specific for a new debian user, then use the more direct "rm -f /etc/rc*.d/*util-vserver" (which an experienced linux admin/user should be able to figure out, even on behalf of a new linux user... until upstart/systemd displace sysvinit, grrr). and feel free to add whatever you want to /etc/rc.local. but i appreciate that debian covers the common/80% case in their init script and gives me the "freedom" to customize for the other 20% of use cases (eg the init scripts are easily modified shell scripts and are not automatically replaced on package upgrades if modified). the other 20% are usually advanced/unique use cases, so those users shouldn't be surprised they have to modify an existing distro package config or create their own. i feel this is also "secure by default" first to new linux-vserver users and secondly to those that fall into the 80% use case, which was (partly) ghislain's concern: "that seems to me a security issue as no one will do it". so i recommend automating the barrier setting (by default as it's probably appropriate 80% or more of the time and can be modified/removed if not) and you recommend only checking and issuing a warning (ie "setattr --barrier /etc/vservers/<guest>/vdir/.."), which i see both as better than the reported behavior of the current package (ie installation fails if not running a vserver-enabled kernel as it tries to set one or more barriers). > but OTOH, I do not care that much as I don't use > debian or the packages in question ... but i appreciate hearing others experience, insight, opinion, etc as it adds to the collective knowledge/wisdom of the mailing-list/community, so thank you for sharing. > best, > Herbert > > > corey > > -- > > undefined@pobox.com > corey -- undefined@pobox.com