Re: [Vserver] VServer seems to work fine basicaly on hppa too -) (just some question)

From: Joel Soete <soete.joel_at_tiscali.be>
Date: Fri 16 Dec 2005 - 10:12:18 GMT
Message-Id: <IRL5OI$D0CA5F27A8F06CE753DD6356D7DAFCCB@scarlet.be>

[...]
> > >
> > 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 :)
>
Yes cool ;-)
 
> 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
>
mmm not 'supposed' any more: that works ;-)
# ./testfs.sh-0.11 -D /dev/loop0 -M /mnt/test -x
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.6.14.3-vs2.1.0-rc10-pa0-d32up parisc/0.30.209
VCI: 0002:0001 263 03000116 (ugid24)

---
testing ext2 filesystem ...
[000]# succeeded.
xid related tests ...
[001]# succeeded.
[002]# succeeded.
[011]# succeeded.
[012]# succeeded.
[014]# succeeded.
[015]# succeeded.
[019]# succeeded.
[020]# succeeded.
[021]# succeeded.
[022]# succeeded.
[023]# succeeded.
[024]# succeeded.
[025]# succeeded.
[026]# succeeded.
[027]# succeeded.
[028]# succeeded.
[033]# succeeded.
[034]# succeeded.
[035]# succeeded.
[037]# succeeded.
xattr related tests ...
[101]# succeeded.
[102]# succeeded.
[103]# succeeded.
[104]# succeeded.
[106]# succeeded.
[108]# succeeded.
[109]# succeeded.
[112]# succeeded.
[113]# succeeded.
[114]# succeeded.
[115]# succeeded.
[116]# succeeded.
[117]# succeeded.
[118]# succeeded.
[119]# succeeded.
[121]# succeeded.
[122]# succeeded.
[123]# succeeded.
[124]# succeeded.
[199]# succeeded.
---
testing ext3 filesystem ...
[000]# succeeded.
xid related tests ...
[001]# succeeded.
[002]# succeeded.
[011]# succeeded.
[012]# succeeded.
[014]# succeeded.
[015]# succeeded.
[019]# succeeded.
[020]# succeeded.
[021]# succeeded.
[022]# succeeded.
[023]# succeeded.
[024]# succeeded.
[025]# succeeded.
[026]# succeeded.
[027]# succeeded.
[028]# succeeded.
[033]# succeeded.
[034]# succeeded.
[035]# succeeded.
[037]# succeeded.
xattr related tests ...
[101]# succeeded.
[102]# succeeded.
[103]# succeeded.
[104]# succeeded.
[106]# succeeded.
[108]# succeeded.
[109]# succeeded.
[112]# succeeded.
[113]# succeeded.
[114]# succeeded.
[115]# succeeded.
[116]# succeeded.
[117]# succeeded.
[118]# succeeded.
[119]# succeeded.
[121]# succeeded.
[122]# succeeded.
[123]# succeeded.
[124]# succeeded.
[199]# succeeded.
---
testing xfs filesystem ...
[000]# failed.
(xfs format failed)
---
testing reiser filesystem ...
[000]# failed.
(reiserfs format failed)
---
testing jfs filesystem ...
[000]# failed.
(jfs format failed)
(well, as I din't include xfs, jfs nore reiserfs in my kernel:
    o xfs showed some pb a time ago (k > 2.6.8.1) need to re-test
    o jfs tested a very very long time ago (need also to retest
    o reiserfs (afair) was broken a longest time ago (iirc k 2.4), since I
      never read any successfull report, though.)
> > > > 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
> 
Cool, I will so look for the 'real' init process inside my guest ;-)
Many thanks for your help and patience,
    Joel
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Fri Dec 16 10:13:14 2005
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 16 Dec 2005 - 10:13:19 GMT by hypermail 2.1.8