[Vserver] /dev/stderr
Can I use /dev/stderr within vservers ? ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Improving utils / debian package
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.
DaCaPazzo: 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.
Pazzoupdate_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
Re: [Vserver] Improving utils / debian package
vserver vstest build --netdev eth0 --interface 192.168.192.168/24 \
--initstyle plain --context 501 --hostname vstest.company.local \
-m debootstrap -- -d sarge -m http://mirror.company.local/debian \
-s /usr/lib/debootstrap/scripts/vserver_sarge
scripts/vserver_sarge is the same as scripts/sarge, our modifications
are:
- remove some packages (don't ask me which ones, I don't remember -
probably the ppp* stuff and maybe something else, but that's not
so important - we could discuss them on the list, more eyes can
for sure find more useless packages)
- remove unused arch's
- call our cleanup script after second_stage_install like:
install_debs () {
first_stage_install
second_stage_install
. /usr/lib/util-vserver/vserver-cleanup
}
- and now the /usr/lib/util-vserver/vserver-cleanup script (sorry
for posting it here and not using some link / attachment - it
really needed some change / comment as it was very proprietary:
# (error messages are german - but they shouldn't be hard to
# understand / translate)
VS_ETC=/etc/vservers
# the following line should be replaced by some sed magic -
# I never really understood what kind of regex sed is using -
# preg syntax doesn't work, maybe someone has a good link for
# me?! I was too lacy und used perl - sorry!
VS_NAME=`echo $TARGET | perl -e while () { s/.+\///; print; }`
VS_ROOT=${VS_ETC}/.defaults/vdirbase/${VS_NAME}
if [ ! -e $VS_ROOT ]; then
error 1 VS_ROOT \$VS_ROOT\ existiert nicht
fi
if [ -e ${VS_ETC}/${VS_NAME}/uts/nodename ]; then
VS_HOSTNAME=`cat ${VS_ETC}/${VS_NAME}/uts/nodename`
else
error 1 VS_HOSTNAME Konnte den Hostname nicht ermitteln
fi
if [ -e ${VS_ETC}/${VS_NAME}/interfaces/0/ip ]; then
VS_IPADDR=`cat ${VS_ETC}/${VS_NAME}/interfaces/0/ip`
else
error 1 VS_IPADDR Konnte die IP-Adresse nicht ermitteln
fi
mv $VS_ROOT/etc/inittab $VS_ROOT/etc/inittab.dist \
grep -v respawn\:/sbin/getty $VS_ROOT/etc/inittab.dist \
$VS_ROOT/etc/inittab
echo $VS_HOSTNAME $VS_ROOT/etc/mailname
echo $VS_HOSTNAME $VS_ROOT/etc/hostname
echo $VS_IPADDR $VS_HOSTNAME localhost $VS_ROOT/etc/hosts
chroot $VS_ROOT shadowconfig on
# copy sources.list from somewhere in /etc/vservers/.defaults/...
# to $VS_ROOT/etc/apt/ - I'm doing something proprietary here
# we are creating a useful bashrc for root fitting our needs,
# probably not useful for everybody, but cut be handled like
# the sources.list
# if this function seems a little bit strange to you have a look
# at my discussion with ola - it's explained (and also simplified)
# there
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
}
# missing others here - ola should have a full list as he has merged
# this ones - search them in the irc log
for i in klogd networking mountvirtfs mountall.sh mountnfs.sh ifupdown;
do
update_rc $i
done
---
ok, that's it - works fine and has already installed many many
ready-to-use debian vservers. It for sure needs some cleanup, as
ola merged most of this stuff into newvserver we could use his
code in a new cleanup script for debian as a part of util-vserver
somewhere in /usr/lib/util-vserver/distributions/...
this approach needs no modification to vserver-build.functions,
tries to do things the way debian likes it and tries to be as less
intrusive as possible.
Cheers,
Thomas Gelf
Am Donnerstag, den 05.05.2005, 11:58 +0200 schrieb Gilles:
Hello.
Could you please post a full command-line for building a Debian vserver
by invoking the -s switch?
Where can I fetch the magic script?
Thanks,
Gilles
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
--
Thomas Gelf [EMAIL PROTECTED]
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Improving utils / debian package
Hi.
scripts/vserver_sarge is the same as scripts/sarge, our modifications
are:
- remove some packages (don't ask me which ones, I don't remember -
probably the ppp* stuff and maybe something else, but that's not
so important - we could discuss them on the list, more eyes can
for sure find more useless packages)
- remove unused arch's
- call our cleanup script after second_stage_install like:
install_debs () {
first_stage_install
second_stage_install
. /usr/lib/util-vserver/vserver-cleanup
}
You provided the vserver-cleanup script but not the vserver_sarge.
Could you send it too?
# the following line should be replaced by some sed magic -
# I never really understood what kind of regex sed is using -
# preg syntax doesn't work, maybe someone has a good link for
# me?! I was too lacy und used perl - sorry!
VS_NAME=`echo $TARGET | perl -e while () { s/.+\///; print; }`
[OT] I'm sorry that the whole script is not in Perl! :-}
As Debian is perl-based, why not?
Thanks,
Gilles
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] OpenFoundry project for Vserver Utilities
Herbert Poetzl [EMAIL PROTECTED] writes: mmh... I am not very happy with the way how this was solved, because: well, if you would show up now and then on the channel we might have taken a different approach ... but I guess although the various aspects might not be perfect, IMHO the direction is generally good ... at least I prefer this over a dozen different branches done by everybody and his dog ... To avoid the dozen of different branches, I would like when the solved issues/bugs/patches/wishes will be filled at a central place instead of spreading them across IRC logs, maillists or Wikis. Personal mail is also problematic because some issues can not be handled immediately but require further investigations and might be forgotten over the time. [... moving the CVS tree into an SVN repository ...] First two points can be perhaps solved by converting the CVS tree but I never did such a conversion. As already mentioned, I do not see the necessity of such a step. well, this isn't intended to replace the savannah (i.e. your) development branch, the idea is to have a breeding ground for various changes, kind of idea pool, where you can skim the useful stuff very easily ... I just think that SVN can not be used for that. E.g. I will pick some (but not all) of the changes in SVN and apply them (perhaps with small changes) to my util-vserver branch. But who will remerge my branch (with lots of conflicts) back into SVN? And the larger the changes in SVN will be, the larger and meaninglesser will be the 'svn diff my branch' output. I prefer small changesets which fulfill exactly one purpose. if you have a better solution for that, please let us know, we are easily convinced by good arguments ;) My mid-term plans are including a switch to GNU Arch when it is provided by Savannah. But the extremely positive mentioning of Monotone at lkml and its very good changeset support (this in GNU Arch is not good, but still better than this of SVN) will bring me to evaluate this SCM system before doing a final decision. For now, please use the Savannah infrastructure (bug- and patch-tracker) and try to use replyable addresses as possible. ;) Enrico pgpRTMpH2Xb7j.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Improving utils / debian package
Hi again!
Am Donnerstag, den 05.05.2005, 13:17 +0200 schrieb Gilles:
scripts/vserver_sarge is the same as scripts/sarge, our modifications
are:
- remove some packages (don't ask me which ones, I don't remember -
probably the ppp* stuff and maybe something else, but that's not
so important - we could discuss them on the list, more eyes can
for sure find more useless packages)
- remove unused arch's
- call our cleanup script after second_stage_install like:
install_debs () {
first_stage_install
second_stage_install
. /usr/lib/util-vserver/vserver-cleanup
}
You provided the vserver-cleanup script but not the vserver_sarge.
Could you send it too?
ok, maybe I wasn't clear enough: debians debootstrap ships with
scripts like /usr/lib/debootstrap/scripts/sarge which are used
by debootstrap to install the right distribution. I did nothing
but take the original one and applied the changes above - that's
it ;-)
[OT] I'm sorry that the whole script is not in Perl! :-}
As Debian is perl-based, why not?
hehe - I would agree - but as all (most of) the other vserver scripts
are shell-based and I didn't really want to start a tool war by
rewriting everything from scratch going on with shell only seemed to
be more polite ;-)
Cheers,
Thomas
--
Thomas Gelf [EMAIL PROTECTED]
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] OpenFoundry project for Vserver Utilities
On Thu, May 05, 2005 at 01:48:12PM +0200, Enrico Scholz wrote: Herbert Poetzl [EMAIL PROTECTED] writes: mmh... I am not very happy with the way how this was solved, because: well, if you would show up now and then on the channel we might have taken a different approach ... but I guess although the various aspects might not be perfect, IMHO the direction is generally good ... at least I prefer this over a dozen different branches done by everybody and his dog ... To avoid the dozen of different branches, I would like when the solved issues/bugs/patches/wishes will be filled at a central place instead of spreading them across IRC logs, maillists or Wikis. Personal mail is also problematic because some issues can not be handled immediately but require further investigations and might be forgotten over the time. [... moving the CVS tree into an SVN repository ...] First two points can be perhaps solved by converting the CVS tree but I never did such a conversion. As already mentioned, I do not see the necessity of such a step. well, this isn't intended to replace the savannah (i.e. your) development branch, the idea is to have a breeding ground for various changes, kind of idea pool, where you can skim the useful stuff very easily ... I just think that SVN can not be used for that. E.g. I will pick some (but not all) of the changes in SVN and apply them (perhaps with small changes) to my util-vserver branch. But who will remerge my branch (with lots of conflicts) back into SVN? be assured we will do that the one or other way ... (do not worry about those things, I'm doing that for some time now for my RPMs because the mainline (your) version doesn't even compile on most of my systems) so we probably end up trashing the 0.30.207 branch once there is a 0.30.208 release from you, and refine the 'missing' parts and upload/add it to that one (or something more sophisticated utilizing 3-way merge and a big crowbar) And the larger the changes in SVN will be, the larger and meaninglesser will be the 'svn diff my branch' output. I prefer small changesets which fulfill exactly one purpose. that is the way we do it with the kernel (see FOR-*) and this will probably be the way we do it with the tools, feel free to adjust the actual feed back process to your needs (nobody knows how to feed back stuff right now) if you have a better solution for that, please let us know, we are easily convinced by good arguments ;) My mid-term plans are including a switch to GNU Arch when it is provided by Savannah. But the extremely positive mentioning of Monotone at lkml and its very good changeset support (this in GNU Arch is not good, but still better than this of SVN) will bring me to evaluate this SCM system before doing a final decision. For now, please use the Savannah infrastructure (bug- and patch-tracker) and try to use replyable addresses as possible. ;) if you do not know who to reply to, send it to me chances are good that the report was mine ... best, Herbert Enrico ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] /dev/stderr
On Thu, May 05, 2005 at 09:55:23AM +0200, KaalH! wrote: Can I use /dev/stderr within vservers ? yup, /dev/std* are symlinks into the file descriptors (there is nothing like a device for stderr) so usually those look like this: $ ls -la /dev/std* lrwxrwxrwx 1 root root 4 2005-05-04 05:44 /dev/stderr - fd/2 lrwxrwxrwx 1 root root 4 2005-05-04 05:44 /dev/stdin - fd/0 lrwxrwxrwx 1 root root 4 2005-05-04 05:44 /dev/stdout - fd/1 $ ls -la /dev/fd lrwxrwxrwx 1 root root 13 2005-05-04 05:44 /dev/fd - /proc/self/fd HTH, Herbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] problems with vserver create -m yum
On Thu, May 05, 2005 at 02:17:31PM -0400, Paul S. Gumerman wrote: I'm following (and correcting where I can) the CentOS distribution howto here: http://linux-vserver.org/CentOS_HowTo hmm, how is that related to the thread you replied to? this is on a dual Opteron box, using the x86_64 arch, and I'm having a problem with yum. It seems that the $releasever variable is not being set to 4 or 4.0, and so when yum attempts to grab info from the repository, it is trying to access http://mirror.centos.org/CentOS/Null/updates/x86_64/repodata/repomd.xml instead of http://mirror.centos.org/centos/4/updates/x86_64/repodata/repomd.xml I tried the obvious step of exporting releasever=4, but that had no effect. Can anyone help? which version of kernel/patch/tools? TIA, Herbert Regards, Paul ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] problems with vserver create -m yum
That's part of what vserver create should be installing, but it can't run properly. Daniel Hokka Zakrisson wrote: Paul S. Gumerman wrote: I'm following (and correcting where I can) the CentOS distribution howto here: http://linux-vserver.org/CentOS_HowTo this is on a dual Opteron box, using the x86_64 arch, and I'm having a problem with yum. It seems that the $releasever variable is not being set to 4 or 4.0, and so when yum attempts to grab info from the repository, it is trying to access http://mirror.centos.org/CentOS/Null/updates/x86_64/repodata/repomd.xml instead of http://mirror.centos.org/centos/4/updates/x86_64/repodata/repomd.xml I tried the obvious step of exporting releasever=4, but that had no effect. Can anyone help? You should install the centos-release package, or whatever the package that provides redhat-release is called in CentOS. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] problems with vserver create -m yum
Paul S. Gumerman wrote: That's part of what vserver create should be installing, but it can't run properly. Ah, I didn't realize this was at build time. You'll want to replace $releasever in the configuration file(s) with the appropriate value. -- Daniel Hokka Zakrisson ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
