From: Thomas Gelf (vserver_at_gelf.net)
Date: Thu 05 May 2005 - 09:22:33 BST
Hi all!
Sorry for starting a new thread - this one has to do with some parts of
"Summary of recent improvement discussion", some parts of "OpenFoundry
project for Vserver Utilities" and want's to offer a solution for the
util-vserver / vserver-debiantools mix in Sarge / SID. As a summary and
for all of you who didn't follow it on IRC here a (not really short)
summary of the discussion between me (Thomas Gelf / nickname Pazzo) and
Ola Lundqvist (nickname ola) about improvements / future direction of
Vserver utils for Debian:
Discussion started on 2005/05/03 at 18:23:34 (timezone Europe/Rome)
ola I have just sent a mail to the mailinglist about some changes
that I will make.
ola Please comment if you have comments. :)
... (searching/fixing bug in SID's .207 utils)
Pazzo ola: what about vserver-debiantools - what are they doing more
than util-vserver?
Bertl ola: how would that improve things? IIRC isntallation happens in
a non chrooted environment ...
ola: last two items sound sane to me ...
ola Pazzo: vserver-debiantools fix a number of files inside the
vserver (like /etc/apt/sources.list) and some more things. It
also have a .deb cache feature.
Bertl ola: we should keep one thing in mind: we do not want to make a
debian branch, a redhat, and a gentoo branch .. we want to make
_one_ tool which can handle _all_ of them on _all_ distros ...
Pazzo ola: hmmm... that's a good thing and really useful. I did so by
creating /usr/lib/util-vserver/vserver-cleanup and
/usr/lib/debootstrap/scripts/vserver_sarge
ola: and then using vserver build -m debootstrap with the "-s"
switch
ola Bertl: I agree.
Pazzo (vserver-cleanup is called then by the debootstrap script)
ola Pazzo, that can be a good thing.
... (next step: some little change proposals, small bug fixes, step 1:
update-rc.d behaviour)
Pazzo ola: another thing: $REMOVE_LINKS
ola: update-rc.d -f removes all links in /etc/rc?.d - BUT...
ola: ... I discovered that debian's package management will set
it back to "default" if you upgrade a package and it finds no
link
Bertl hmm, isn't that a bug then?
Pazzo Bertl, ola: if you leave a single link there it doesn't do so
ola Pazzo: Yes I know that, but I do not have any solution for that
using the current script.
DaCa Pazzo: yes, the trick is to leave at least one link there
Bertl Pazzo: hmm, yeah, maybe in an unused runlevel?
ola Ahh yes that was the solution. I do not do that using the
maintainer script though.
Pazzo we did update-rc.d $service stop 90 3 .
for all packages that should be removed
Bertl hmm, doesn't that mean that shutting down the server will call
them?
Pazzo Bertl: Debian uses runlevel 2 by default
putting the stop link into 4 or 5 would also be ok
Bertl something completely different, why don't we use a 'special'
vserver runlevel?
Pazzo Bertl: because of tools like update-rc.d and package
management / postinstall scripts?
... (step 2: newvserver provides it's own inittab)
Pazzo ola: for /etc/inittab maybe some grep would be less "intrusive"
than providing a own inittab file:
mv $VS_ROOT/etc/inittab $VS_ROOT/etc/inittab.dist && grep -v
respawn\:/sbin/getty $VS_ROOT/etc/inittab.dist >
$VS_ROOT/etc/inittab
ola Pazzo: Yes grepping is less intrusive than providing a new file.
... (step 3: removing symlinks is not "upgrade-proof" - fixing this and
adding other scripts that should be removed)
Pazzo ola: what about ifupdown, mountvirtfs, mountall.sh and
mountnfs.sh?
I'm removing them too
ola Remove those symlinks too or.
Pazzo for i in klogd networking mountvirtfs mountall.sh mountnfs.sh
ifupdown; do
ola If you have a patch that would be great.
Pazzo update_rc $i
update_rc is a small shell function removing with -f the
symlinks and adding one stop link
Pazzo http://www.pastebin.com/279170
... (shell code sniplet)
function update_rc() {
service="$1"
program=`chroot $VS_ROOT which update-rc.d`
if [ -x $VS_ROOT/$program ]; then
chroot $VS_ROOT $program -f $service remove
chroot $VS_ROOT $program $service stop 90 3 .
else
error 1 UPDATE_RC.D "Konnte update-rc.d in VServer nicht ausführen"
fi
}
ola for link in $REMOVE_LINKS
do
update-rc.d -f \$link remove
update-rc.d -f \$link stop 90 3 .
done
This is how it will look now. Will that do the proper things?
...
ola Pazzo: I agree that it may be a better solution. Patches are
welcome. :)
REMOVE_LINKS="klogd hwclock.sh setserial urandom networking
umountfs halt reboot"
So what am I missing... mountall.sh mountvirtfs and mountnfs.sh
and ifupdown.
Pazzo ola: sure - we did the strange function because we do not want
the vserver to be started
ola ok
Pazzo (maybe better replace update-rc.d with a variable)
ola maybe not that important.
Pazzo ok
ola What do update-rc.d -f \$link stop 90 3 .
do?
put a stop link in ... runlevel 3?
Will that prevent it from upgrades to be added?
Pazzo ola: yes
unfortunately I don't remember where - but I read somewhere that
debian while updating it's rc-stuff it :
- looks if there is some link
- if not, it sets them to the defaults
ola Actually some parts may actually be generic, and not just for
debian.
Pazzo - if yes it doesn't touch them
... (step 4: maybe useless)
Pazzo hmm... I'm also doing "shadowconfig on", set /etc/mailname to
the hostname - but I don't know if this would be settings for
everyone
... (step 5: sources.list)
Pazzo ola: I think it should be possible to modify the default
sources.list - so better put it into
/etc/vservers/.default/whatever
...
Pazzo hey, copying ssh keys is a good idea
... (now I'm trying to explain how I modified util-vserver 'til now to
fit my needs on my Debian hosts)
ola I'm not sure how to provide all this features to vserver ...
build.
I can not add a huge number of arguments, or can I.
Pazzo ola: what do you think about our debootstrap script solution?
I'm doing vserver xy build ...
-s /usr/lib/debootstrap/scripts/vserver_sarge
vserver_sarge is similar to sarge, with some extra excludes
and it calls our /usr/lib/util-vserver/vserver-cleanup script
ola Yes that is a good solution. The -s option is debian specific
though. :)
Whould I add that to the "real" util-vserver too?
Pazzo maybe you could take your cleanup part as it is for sure done
more careful than my one ;-) ...
ola: I would make /usr/lib/debootstrap/scripts/vserver_sarge
part of util-vserver, you could also move it to something
like /usr/lib/util-vserver/distributions/somewhere and also put
the debian cleanup stuff there
... (later)
Pazzo ola: for the debootstrap script: you may modify the packages
there, remove unsupported archs and call the cleanup script
after the second_stage_install
as told before I would also take the sources.list out of the
cleanup script and put it somewhere in
/etc/vservers/.defaults/...
... (short summary, trying to explain)
newvserver (from vserver-debiantools) creates a vserver and does some
cleanup (removing getty's, klogd - all the bad things) and leaves out
useless (in a vserver) packages. as creating a vserver should be
util-vserver's job on all distributions I don't like the idea of having
a different tool for Debian and did the following:
- time ago the "-s" switch was added to util-vserver (at least in the
debian package, don't know if my suggestion and "patch" has found it's
way into upstream sources) to allow us to tell the debootstrap method
to use a special script. the same switch is also used by debootstrap
itself, so this seems to be clean and logical.
- this "-s" switch allowed me to create a special debootstrap script
leaving out some packages / unused archs and calling a cleanup-script
lying somewhere in /usr/lib/util-vserver - probably
/usr/lib/util-vserver/distributions/somewhere would be the right
place, any suggestion? this cleanup script is then doing all the
cleanup with chroot & co and without starting the vserver
... (another script was mentioned - I don't know enough about it to say
if it could be moved to util-vserver, maybe someone else can do so)
Pazzo what else is debian-specific in vserver-debianutils?
what does newnfsserver do?
ehm - newnfsvserver
ola Pazzo: It will create a vserver suiteable for a nfsrootmounted
diskless client.
The name is not perfect.
... (ola fixed some of the discussed things in newvserver, I did some
testing)
Pazzo ola: I got some errors as the created sources.list fails
partially (I'm mirroring only binary packages, no sources) - but
that's ok
...
Pazzo ola: some other thoughts:
- I don't like the idea of starting/stopping vservers while
creating them, it should be possible to do all this jobs with
chroot & co
... (it "shouldn't" be possible, it IS possible as we are already doing
so :)
... (let's go on, thoughts about "non-interactivity")
Pazzo - vserver XY build is non-interactive, newvserver is interactive
- I would prefer the idea of using "vserver XY build" with a
special debootstrap script which is then calling the cleanup
script
- interactivity should be an extra option but not on by default
(root password, timezone and such stuff)
- timezone config can be taken from the host
- another thing breaking "non-interactivity": as written before
adding deb-src http://mymirror/... did fail as I have no local
src mirror. result:
update available list script returned error exit status 1.
Press <enter> to continue.
this "Press ..." shouldn't be there
ola Pazzo: I agree.
...
ola I like the ideas.
...
ola Sounds like a good solution. I'll work on something. If you have
time I would be happy if you can provide files/patches etc. :)
...
Discussion finished at 20:32:34
Ok, what else?
* Replying to the "OpenFoundry-thread" Ola told us
(http://list.linux-vserver.org/archive/vserver/msg09644.html) that he
would add the remount hack to vserver-stop - that's what I'm doing in
my .debs since I realized in a discussion with Bertl that atm it is
the only possibility to do stop vservers without pain. Enrico told me
that he wouldn't add such a hack to his utils and Bertl that this is
for sure not a job to be done in the kernel patch so what else should
I do?
Kilian Krause started the "packaging review for new Debian packages"
thread on this ml on 2005/12/27, I had some discussion with him,
reviewing differences between his and my util-vserver package. You can
read up discussion here:
http://irc.13thfloor.at/LOG/2005-01/LOG_2005-01-10.txt
http://irc.13thfloor.at/LOG/2005-01/LOG_2005-01-11.txt
That's where the remount-hack probably found it's way into official
Debian packages - maybe in the meantime this is outdated - I don't
know. Is the remount hack still needed?? Is there still no
alternative?
If not I'm would be happy if also upstream sources contain it unless
someday someone will find a better solution - but we should not forget
about it!
* Ola asked if his tools should be added to util-vserver: yes and no -
what they are doing is useful, but in my opinion they shouldn't be
separate tools as I prefer my debootstrap-script approach. What's your
opinion?
* Adding --numeric-ids to vserver-copy sounds good - but don't ask me
about vserver-copy as I didn't use it 'til now - debootstrap is great
and with a local mirror for sure my preferred way of installing Debian
Vservers.
* I have no idea what Ola's changes to vserver-build.debootstrap will be
- and maybe these will become useless if we are using debootstrap
scripts. Ola?
* force-reload - hmmm... never seen before :) What does it do? kill
everything in a context?
* another question: what is the preferred initstyle for a Debian Vserver
on kernel 2.6? I'm using "plain" and not able to shut down my vservers
cleanly - error msg is:
> vkill: vc_ctx_kill(): No such process
> Vserver '/etc/vservers/XY' still running unexpectedly; please
> investigate it manually...
any idea / suggestion?
* I also have read the discussion about who should be responsible for
package management - the vserver itself or the host for all vservers.
I have not enough knowledge about rpm & yum to tell you something
intelligent about them.
For Debian the way described in this mail is the best thing for my
needs and maybe for others too - I believe that a Debian Vserver
without package management tools makes no sense. Maybe that's not
true for rpm-based distributions - I don't know.
In my opinion package management is a Vserver's job - the host should
care about installing / destroying / copying / moving / starting /
stopping them - that's it.
Ok, that's all folks - let's start the flame war ;-)
Best regards,
Thomas Gelf
-- Thomas Gelf <vserver_at_gelf.net>_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver