On Thu, Dec 15, 2005 at 01:48:51PM +0100, Joel Soete wrote:
> Hello Herbert,
>
> >
> > On Tue, Dec 13, 2005 at 05:20:22PM +0100, Joel Soete wrote:
> > > Hello All,
> > > Great the kernel was booting fine; just grep the upstream
> > > util-vserver tools and hack lib/syscall-faalback.h to match
> > > __NR_vserver 263 for hppa to build it with default debian pkg
> > > configure options ;-)
> > >
> > > As I already had some chroot disks that I used for severall
> > > test (glibc, ...) and I wouldn't like to re-install a debian
> > > debootstrap, I
> >
> > sounds reasonable ...
> >
> > > use a vserver build -m skeleton ;-) and gather some more info to
> > > start my vserver named DebSid:
> > >
> > > # vserver-stat
> > > CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME
> > > 0 68 134.3M 49.3M 7m32s62 28m01s19 4h14m54 root server
> > > 49153 15 76.8M 22.5M 0m05s31 0m14s53 2h47m02 DebSid
> > >
> [...]
> > > and after stolen an ipv4 address and configure nic, ssh, ...:
> > > > ssh 10.24.252.111
> > > Linux patst007 2.6.15-rc1-pa3-d32up #8 Mon Nov 14 13:01:04 CET 2005
> > > parisc GNU/Linux
> >
> > excellent, so the patch worked fine for you on 2.6.15-rc1-pa3?
> >
> mmm, no sorry I didn't pay attention: this message stand in fact in
> the /etc/motd of the vps (updated last time I booted actualy with
> another testing 2.6.15-rc1-pa3-d32up kernel); I need to check to
> update this motd when the vps is started. Apologies for confusion ;-(
>
> > could you give the testme.sh and testfs.sh a spin on
> > that machine?
> >
> testme works fine:
> # ./testme.sh-0.14 -v
> Linux-VServer Test [V0.14] Copyright (C) 2003-2005 H.Poetzl
> chcontext is working.
> chbind is working.
> chcontext 0.30.209 -- allocates/enters a security context
> This program is part of util-vserver 0.30.209
>
> Copyright (C) 2004 Enrico Scholz
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License. This program has absolutely no warranty.
> Linux 2.6.14.3-vs2.1.0-rc10-pa0-d32up parisc/0.30.209/0.30.209 [Ea] (0)
> VCI: 0002:0001 263 03000116
> (root@patst007)
> (gcc version 4.0.3 20051201 (prerelease)
> (Debian 4.0.2-5))
> #2 Wed Dec 7 12:07:47 CET 2005
> ---
> [000]# chcontext true && chcontext --ctx 45678 true
> [000]# succeeded.
> [001]# chcontext --ctx 45678 egrep 'context|VxID' /proc/self/status
> [001]# succeeded.
> [011]# chcontext --secure --ctx 45678 mknod /tmp/testme.sh-0.14.x4zqUF/node c 0 0
> [011]# succeeded.
> [031]# chcontext --hostname zaphod.21379 uname -a | grep -q zaphod.21379
> [031]# succeeded.
> [101]# chbind --ip 192.168.0.42 true
> [101]# succeeded.
> [102]# chbind --ip 192.168.0.1/255.255.255.0 --ip 10.0.0.1/24 true
> [102]# succeeded.
> [201]# chcontext --ctx 45678 --flag fakeinit bash -c 'test $$ -eq 1'
> [201]# succeeded.
> [202]# chcontext --flag fakeinit bash -c 'test $$ -eq 1'
> [202]# succeeded.
>
> OTC testfs.sh-0.11 failed after a return (no messaged)?
> I have a quick look and testfs -v -F ext2 (help example)
> launch "mkfs.ext2 /dev/zero"
>
> manualy this cmdl is querying:
> mke2fs 1.38 (30-Jun-2005)
> /dev/zero is not a block special device.
> Proceed anyway? (y,n)
>
> though.
>
> (please exaplain me what is it supposed to do and detect as pb?)
check testfs.sh -h and you will find that you can
specify a device, which will be used to create
various filesystems on, and verify the different
aspects of attributes, barrier and xid tagging
because those tests are destructive, the default
is the /dev/zero device, which will not work :)
something like this is supposed to work, given that
you have support for the filesystems:
dd if=/dev/zero of=/var/tmp/200MB.img bs=1M count=200
losetup /dev/loop0 /var/tmp/200MB.img
mkdir /mnt/test
testfs.sh -D /dev/loop0 -M /mnt/test -x
> > > The additional question is (may be non sense but thought): those
> > > chroot disk was also bootable, so if I want to reboot I would
> > > just have to write and run a script which will would restore /dev
> > > /etc/init.d and corresponding rc?.d?
> >
> > well, it might be an option to use udev to populate
> > the dev (on a real boot) and just clense them before
> > you use it as guest ...
> >
> > > Or is it possible to instruct vserver to use better a /dev.vserver as
> > > well as /etc/init.d.vserver, ...?
> >
> > you could also do some --bind mounting on guest
> > startup (see pre/post scripts and fstab) and of course
> > if security is not an issue for your guests, you could
> > also let them run with the fully populated /dev
> >
> (well I just discover this proj about 2 weeks ago so still have planty
> to learn ;-) )
>
> Effectively for the moment I am not already worry on security of the
> guest vps but more of application started (as motd update ;-)), also
> the option "pre/post scripts" would certainly take my first attention.
>
> (btw: am I wrong: the init of guest vps only run the rc2.d scripts
> (here the default run level in /etc/inittab) and not previous levels?
> what would be the best way: move all request startup script in
> /etc/verserver/DebSid...?)
there are different init styles, one (plain) calls the 'real'
init process inside the guest, the other (sysv) just
executes the runlevel scripts of the 'default' runlevel
HTH,
Herbert
> Thanks a lot,
> Joel
>
> ---------------------------------------------------------------
> A free anti-spam and anti-virus filter on all Scarlet mailboxes
> More info on http://www.scarlet.be/
>
> _______________________________________________
> 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
Received on Thu Dec 15 15:01:17 2005