[Vserver] Xen + VServer
Hi all,
I used to run VServer in the past and recently gave Xen a try. I pretty
much like both of these technologies - each of them has some advantages
that the other one can't offer. I appreciate the real independence of
Xen domains but the memory overhead of running a kernel for each domain
and the need to partition the memory space may become a limitation. On
the other hand in VServer the contexts run on top of the same kernel and
may share the available memory which may come handy in some deployments.
So I decided to merge both patches and surprisingly enough - it works! I
don't now (yet) how stable it is but the kernel booted as domU and a
guest vserver context was created, some prcosses are running inside and
everything looks just fine.
Versions used:
* Linux kernel 2.6.11
* Xen 2.0-testing from yesterday
* VServer 2.0-rc4 (last version for 2.6.11)
Apply the attached patch on top of these.
Xen userspace is 2.0-testing as well, util-vserver 0.30.204 (debian
build), running on Debian Sarge.
My configuration was x86, statically compiled without modules, domU with
no physdev access, 3G/1G memspace split on x86, no preempt, no selinux.
What else?
This is the very first shot, I don't guarantee that it is stable,
secure, etc, but if you're brave enough give it a try ;-)
Michal Ludvig
--
* Personal homepage: http://www.logix.cz/michal
Index: linux-2.6.11/arch/xen/i386/Kconfig
===
--- linux-2.6.11.orig/arch/xen/i386/Kconfig
+++ linux-2.6.11/arch/xen/i386/Kconfig
@@ -546,6 +546,46 @@ config HIGHMEM4G
endchoice
+choice
+ prompt "Memory Split User Space"
+ default SPLIT_3GB
+ help
+ A different Userspace/Kernel split allows you to
+ utilize up to alsmost 3GB of RAM without the requirement
+ for HIGHMEM. It also increases the available lowmem.
+
+config SPLIT_3GB
+ bool "3.0GB/1.0GB Kernel (Default)"
+ help
+ This is the default split of 3GB userspace to 1GB kernel
+ space, which will result in about 860MB of lowmem.
+
+config SPLIT_25GB
+ bool "2.5GB/1.5GB Kernel"
+ help
+ This split provides 2.5GB userspace and 1.5GB kernel
+ space, which will result in about 1370MB of lowmem.
+
+config SPLIT_2GB
+ bool "2.0GB/2.0GB Kernel"
+ help
+ This split provides 2GB userspace and 2GB kernel
+ space, which will result in about 1880MB of lowmem.
+
+config SPLIT_15GB
+ bool "1.5GB/2.5GB Kernel"
+ help
+ This split provides 1.5GB userspace and 2.5GB kernel
+ space, which will result in about 2390MB of lowmem.
+
+config SPLIT_1GB
+ bool "1.0GB/3.0GB Kernel"
+ help
+ This split provides 1GB userspace and 3GB kernel
+ space, which will result in about 2900MB of lowmem.
+
+endchoice
+
config HIGHMEM
bool
depends on HIGHMEM64G || HIGHMEM4G
Index: linux-2.6.11/arch/xen/i386/kernel/entry.S
===
--- linux-2.6.11.orig/arch/xen/i386/kernel/entry.S
+++ linux-2.6.11/arch/xen/i386/kernel/entry.S
@@ -1011,7 +1011,7 @@ ENTRY(sys_call_table)
.long sys_tgkill/* 270 */
.long sys_utimes
.long sys_fadvise64_64
- .long sys_ni_syscall/* sys_vserver */
+ .long sys_vserver
.long sys_mbind
.long sys_get_mempolicy
.long sys_set_mempolicy
Index: linux-2.6.11/arch/xen/i386/kernel/traps.c
===
--- linux-2.6.11.orig/arch/xen/i386/kernel/traps.c
+++ linux-2.6.11/arch/xen/i386/kernel/traps.c
@@ -53,6 +53,7 @@
#include
#include
+#include
#include "mach_traps.h"
@@ -303,6 +304,7 @@ void die(const char * str, struct pt_reg
};
static int die_counter;
+ vxh_throw_oops();
if (die.lock_owner != _smp_processor_id()) {
console_verbose();
spin_lock_irq(&die.lock);
@@ -337,6 +339,7 @@ void die(const char * str, struct pt_reg
bust_spinlocks(0);
die.lock_owner = -1;
spin_unlock_irq(&die.lock);
+ vxh_dump_history();
if (in_interrupt())
panic("Fatal exception in interrupt");
Index: linux-2.6.11/include/asm-xen/asm-i386/page.h
===
--- linux-2.6.11.orig/include/asm-xen/asm-i386/page.h
+++ linux-2.6.11/include/asm-xen/asm-i386/page.h
@@ -167,16 +167,24 @@ extern int sysctl_legacy_va_layout;
#endif /* __ASSEMBLY__ */
-#ifdef __ASSEMBLY__
+#if defined(CONFIG_SPLIT_3GB)
#define __PAGE_OFFSET (0xC000)
-#else
-#define __PAGE_OFFSET (0xC000UL)
+#elif defined(CONFIG_SPLIT_25GB)
+#define __PAGE_OFFSET (0xA000)
+#elif defined(CONFIG_SPLIT_2GB)
+#define __PAGE_OFFSET
Re: [Vserver] [PreRelease] vs2.0-rc2
Herbert Poetzl wrote: > Greetings Community! > > a fortnight after the first one, here is the second > release candidate for the stable 2.6 series ... > > http://vserver.13thfloor.at/Experimental/patch-2.6.11.10-vs2.0-rc2.diff > http://vserver.13thfloor.at/Experimental/patch-2.6.11.10-vs2.0-rc2.diff.bz2 > > please give it some testing, and let me know if there > is anything which requires mending, if nothing is > reported this might become the final 2.0 release ... And for 2.6.12-rc5: http://www.logix.cz/michal/devel/vserver/patch-2.6.12-rc5-vs2.0-rc2.diff (now based on Björn's patch-2.6.12-rc4-vs2.0-rc1.diff) Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vs2.0-rc1 for 2.6.12-rc4
Björn Steinbrink wrote: > Most of the differences are due to the *_mm_counter macros, which I > modified to call the Linux-VServer accounting stuff. That was on my TODO list as well, but I probably wouldn't come up with such a smart "abuse" of preprocessor as you did ;-) #define inc_mm_counter(mm, member) vx_ ## member ## pages_inc((mm)) > There are two or three other small issues, IIRC QUOTA_CTL and rss > accounting, a diff between the ports tells you more ;) How could I have missed the quota thing? Hmmm... But I couldn't find any difference in the rss accounting. > I wondered about that change you did in get_tid_list: > > - tids[nr_tids] = vx_map_pid(tid); > - nr_tids++; > + tids[nr_tids++] = vx_map_pid(tid); > > It looks quite good I'd say, was that a known bug in 2.6.12-rc4? I don't think it is known (not fixed in recent git repository). I'm about to report it. But 'tids' should be !NULL anyway so there is only a small chance to get the counter wrong even without fixing it. Cheers, Michal Ludvig -- * New Zealand: http://kiwi.logix.cz ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] vs2.0-rc1 for 2.6.12-rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, for anyone interested I did a patch of VServer 2.0-rc1 for the linux kernel 2.6.12-rc4. Get here: http://www.logix.cz/michal/devel/vserver/ It compiles, boots and runs two quite loaded vservers without problems. Most of the conflicts were quite easy to solve except for net/sunrpc/auth_unix.c, where some fields were removed from 'struct unx_cred' and I didn't know where to place 'uc_pxid'. So I omitted it completely (yes, I know, that's not a solution, but I don't use NFS anyway ;-) Another issue I had with fs/nfs/inode.c where I didn't know how to initialize clnt->cl_tagxid. The rest was pretty obvious and unless you use NFS on your vserver you should be safe to try this patch. Enjoy but don't complain if it wipes your disk! (you've been warned :-) Michal Ludvig - -- * Personal homepage: http://www.logix.cz/michal -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCjCJoDDolCcRbIhgRAlOgAKDfEAkn796wZoy6eQKkBOzYn9fbRgCeI/sh t8X9JTnWRCg/KJAQkpb9ofg= =vZVC -END PGP SIGNATURE- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] building from savannah CVS
Bodo Eggert wrote: > On Wed, 18 May 2005, Michal Ludvig wrote: > > >>#!/bin/sh > > > set -e > - and - > > >>rm -rf autom4te*.cache >>aclocal -I . -I m4 || exit 1 > > [...] > > remove these "|| exit 1" Good hint, but does it work with non-bash as well? This was my standard bootstrap script that I use in many different projects. I'll give it a try, thanks! Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] building from savannah CVS
Herbert Poetzl wrote: > probably I'm just too dumb to figure it myself, but > how would you build the tools from the savannah CVS? This one works for me on SuSE Linux 9.2: ~/src/utils-vserver-cvs $ cat bootstrap #!/bin/sh rm -rf autom4te*.cache aclocal -I . -I m4 || exit 1 autoheader || exit 1 libtoolize --force --copy || exit 1 automake --foreign --add-missing --copy || exit 1 autoconf|| exit 1 ~/src/utils-vserver-cvs $ Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] ELF Loader Bug exploitable inside a vServer
Herbert Poetzl wrote: > On Thu, May 12, 2005 at 01:43:09PM +0200, Oliver Welter wrote: > >>serious problem: >>I read about the new BufferOverflow in the kernel's ELF Loader - it >>seems that an unprivileged attacker can start process in the kernels >>context.. > > > details? > > - which issue? Core dump privilege escallation. http://isec.pl/vulnerabilities/isec-0023-coredump.txt > - what kernels are affected? Almost all 2.2, 2.4, 2.6 up to the *most* recent. > - how does the 'exploit' look like? Specially crafted ELF binary can be used to overwrite kernel memory on coredump. >>Is it possible to break out of a vServer with this Bug ? > > depends, if you can create kernel processess, they > certainly can circumvent _any_ kernel side protection > so if done probably, I'd say so ... Probably yes. Hotfix as suggested by the paper: disable coredumps. Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] OpenFoundry project for Vserver Utilities
Sam Vilain wrote: > Ola Lundqvist wrote: > >> As I now have the possiblity to apply a number of fixes directly to this >> upstream version I will do so. I need your advice on a number of things >> though. If you do not want me to modify some parts here please tell >> me as I may do it quite soon. :) > > This is wiki-style development; don't even worry too much about the code > compiling. Just make sure that your commits have clear intent. Have trust > in the Version Control System! Don't take it personally as I just wonder - is your effort blessed by current project maintainers? (Herbert, Enrico, ...) Or is it a fork attempt? I'm not sure if you have an experience with development management, but allowing wiki style development seems contraproductive for me. Newcomers may have good ideas but don't know the project enough in details => their solutions could be deeply suboptimal. Very good and proven approach is to let the newbies send their patches to a development list first, where the current maintainers could comment on it, reject, approve... Only after some time when you trust they wouldn't break anything, give them a direct write access. I have participated in many opensource projects and I know how "naive" patches people (incl. me) try to commit at the beginning. They could fix a particular problem they address but without knowing the broader context they'd often break something else. WiKi is good enough for texts, but not for coding. The amount of crap getting in this way would be a real pain in the ass to clean once you're about to make a release. Eh, and one more "proven" thing - set up a mailing list whete all diffs from commits would be automatically posted by svn. If you really allow everyone commit everything you should at least post-examine the changes. > That being said, commits which are untested and don't compile make a bit of > work for others around release time. So be sure to at least hang out in > IRC to receive the flames. Often quite difficult given the different timezones people live in ;-) Just my two cents (admitting I haven't contributed anything to vserver so far :-) Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Starting vserver kills my X session
Benedikt Boehm wrote: > We discovered that /dev/console inside your vserver is evil WRT init. > You can either remove /dev/console or rebuild init with /dev/null as console Removed /dev/console in the vserver but no luck. Also tried to mknod /dev/console as the same device as /dev/tty but neither that helped... Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Starting vserver kills my X session
Paul S. Gumerman wrote: > You might try recompiling the tools without dietlib. That's what I had > to do to make things work in x86_64. > > Until you do that, or use the patch that Herbert supplied, you will have > problems. The patches (dietlibc-0.28-syscall.patch and dietlibc-0.28-vserver.patch) don't seem to do anything that would help with the init killing X-keyboard. Other than that I have no problems with using plain dietlibc on amd64... Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Starting vserver kills my X session
Benedikt Boehm wrote: > We discovered that /dev/console inside your vserver is evil WRT init. > You can either remove /dev/console or rebuild init with /dev/null as console ... or mknod /dev/console as the same device as /dev/tty or /dev/null? Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Starting vserver kills my X session
Herbert Poetzl wrote: > - the tools (util-vserver 0.30.206, + dietlibc 0.28+patches) >emit some stuff, do some things, whatever .. which 'disturbes >the X keyboard ... (unlikely, but possible) > >* make sure that the tools are the latest and dietlibc is > (patched on x86_64) Where can I get the patch? I'm using plain dietlibc 0.28 on amd64 >* check by starting the vserver from a different host > (logged on via ssh, and maybe telnet) Over ssh it works with no problems. However e.g. locally from screen it still dies. > - the init inside the vserver does something which manages >to confuse the X keyboard (would be an isolation issue) > >* try to replace the init with an minit or a different init Replaced with debian woody statically linked init and still the same. >* replace the init by an strace wrapper to dump the syscalls > > - there is an unwanted 'connection' between the X (on the host) >and the vserver which really should not be there > >* check for device nodes in /dev and various other places >* verify that no 'magic' keys are copied from the host What do you mean with magic keys? >* look for pipes (fifos) which run between host and guest It is a fresh SL92 vserver, almost no extra config done. There should be no such fifos. However... I stripped down /etc/rc.d/rc to just running sshd and exit. Still the same. Subsequent vserver halting from the master looks like this: root:~ # vserver popelka stop vkill: vc_ctx_kill(): No such process Vserver '/usr/local/etc/vservers/popelka' still running unexpectedly; please investigate it manually... root:~ # vserver popelka stop vserver 'popelka' is not running Once I exit the dead X session (running e.g. on tty7) I still can't use the keyboard. I must ssh from a different host and with "chvt 1" switch the console. Only after that I could use the keyboard again. When going back to tty7 I can see some binary garbage after "INIT: no more processes left in this runlevel". Not too much of success... Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Starting vserver kills my X session
Hi all, I observe a strange behaviour with SL92/x86 (SuSE Linux 9.2) vserver running on SL92/amd64 host with 2.6.11.5-vs1.95 and util-vserver 0.30.204 (linked with dietlibc 0.28). When starting up the vserver in 'sysv' mode, everything works just fine except that I can't reboot it from inside of the vserver. Reboot fails with: ~# reboot init: timeout opening/writing control channel /dev/initctl So I changed the init method to 'plain' and did 'vserver popelka start'. The host came up in the background, but immediately my keyboard in X (xorg-x11-6.8.1/amd64) died and load came up to 1.00 because the 'X' process ended up eating all the CPU time. Everything else worked - I could use the mouse to exit X and logged in again and it worked fine until I did reboot from inside of the vserver. Now it succeeded, but as soon as the host was about to come up after reboot the keyboard died again. Has anyone else seen this behaviour? I suspect the SuSE init or one of the initscripts run *something* that breaks X/keyboard. N.b. from text console it works with no problems. Is there anyting I should try to avoid this? Or is there any way to allow reboot from inside of the vserver without having 'init' process running? Thanks! Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver and suse 9.3
Dennis Paulisch wrote: > i got a fresh installed suse 9.3 system (x86_64) with gcc 3.3.5 installed > When i try to compile util-vserver 0.30.204 i got this output... until the > compilation... any ideas what could i do? Please do not say to downgrade > the gcc... > > /usr/include/sys/wait.h:103: error: syntax error before numeric constant What is around line 103 in your /usr/include/sys/wait.h? Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Suse Templates
Dennis Paulisch wrote: > just a little question. Have anyone in the List templates with suse? > I just found a Suse 9.2 one but it do not work correctly. Maybe someone > have done a 9.0 and 8.2? I did SUSE vserver with the 'skel' method and then populated that directory with "YaST->Software->Installation into Directory". Some days ago I have also sent a patch for /etc/rc.d/rc here to let it work in vserver. Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
Enrico Scholz wrote: > Herbert Poetzl <[EMAIL PROTECTED]> writes: > >>what if we implement the _syscall3 for all known platforms >>in a proper way, and feed them back to glibc/kernel headers >>as well as integrate them into dietlibc and/or util-vserver? > > > The kernel (resp. projects like [1] which provide sanitized > headers) would be the right place for such changes. But there > will pass much time before you can rely on it. These headers > are/should not be provided by libc implementations. E.g. glibc.rpm from SUSE Linux 9.2 contains _syscall3() for both x86 and amd64. I'm not sure if it was in the original glibc-2.3.3 tarball or only added later by SUSE. Anyway this macro is unlikely to change and could safely be in the headers, why not? Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Problem with util-vserver and dietlibc on x86_64
Herbert Poetzl wrote: > On Mon, Apr 11, 2005 at 10:54:38AM +1200, Michal Ludvig wrote: > >>What is the expected behaviour? With glibc I'm getting: >># ./sysx >>ret = 65573 >> >>However when changed your testcase to use _syscall3() as utils-vserver >>do I'm getting the same output even with dietlibc. > > ah, that's a good hint, probably _syscall3() is present > in your includes, could you upload/post the header file > which contains that (for x86_64)? It is defined in /usr/include/asm-x86_64/unistd.h of glibc-2.3.3 (included from /opt/dietlibc/include/sys/syscall.h -> /usr/include/asm/unistd.h). I guess ENSC_SYSCALL macro in m4/ensc_syscall.m4 doesn't correctly recognize if your system supports "fast" syscalls. Look for 'invocation method' in your config.log. My one looks like this: configure:23736: checking for number of syscall 'vserver' configure:23783: result: 236/glibc configure:23799: checking for syscall(2) invocation method configure:23809: result: auto configure:23814: checking which syscall(2) invocation works configure:23855: gcc -c -g -O2 -std=c99 -Wall -pedantic -W conftest.c >&5 configure:23861: $? = 0 configure:23865: test -z || test ! -s conftest.err configure:23868: $? = 0 configure:23871: test -s conftest.o configure:23874: $? = 0 configure:23893: result: fast Apparently 'fast' = '_syscall3()' Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
Herbert Poetzl wrote: > On Mon, Apr 11, 2005 at 10:29:17AM +1200, Michal Ludvig wrote: > >>Tell me if you need something more. > > > no, thanks I already figured it, the dietlibc needs > patching as the syscall(2) for x86_64 isn't implemented > > .o( I wonder _what_ is running on your machine ;) I guess it was using _syscall3() instead of syscall(). Shouldn't it? Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Problem with util-vserver and dietlibc on x86_64
Herbert Poetzl wrote: > here is an example which simply fails on x86_64 when > compiled with dietlibc (0.27, 0.28, cvs, debian, fc3, suse ;) > > [...] > > $ diet gcc -o sysx sysx.c -lcompat > > $ ./sysx > $ echo $? > 236 What is the expected behaviour? With glibc I'm getting: # ./sysx ret = 65573 However when changed your testcase to use _syscall3() as utils-vserver do I'm getting the same output even with dietlibc. Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
Herbert Poetzl wrote:
>> hmm, I had absolutely no success with the following configs:
>> (on FC3 with util-vserver-0.30.205)
>
>> - gcc 3.4.2, dietlibc-0.28
>> - gcc 3.4.2, dietlibc-0.28, -O0
>> - gcc 3.4.2, dietlibc-0.28, -Os
>> - gcc 3.3.4 (compat), dietlibc-0.28
>> - gcc 3.3.4 (compat), dietlibc-0.28, -O0
>> - gcc 3.3.4 (compat), dietlibc-0.28, -Os
>> - gcc 3.3.4 (compat), your dietlibc src.rpm
>> - gcc 3.3.4 (compat), your dietlibc rpm
>
>> # chcontext --xid 100 true
>> New security context is 100
>> chcontext: execvp("true"): Permission denied
>
>> please could you provide your final rpms so that I can
>> test if it is tools related at all?
I don't have the utils in RPM, but here is a tarball of /usr/local/sbin:
http://tmp.logix.cz/util-vserver-sbin-amd64.tar.bz2
Tell me if you need something more.
Michal Ludvig
--
* Personal homepage: http://www.logix.cz/michal
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Herbert Poetzl wrote: > On Thu, Apr 07, 2005 at 04:18:45PM +1200, Michal Ludvig wrote: > >>I'm running SuSE Linux 9.2 on AMD64 and util-linux-0.30.204 work just >>fine with dietlibc-0.28. Perhaps a compiler issue? My GCC says: >>gcc version 3.3.4 (pre 3.3.5 20040809) > > please could you provide an url to that dietlibc package > from suse, I have several gcc's available and I'll test > once the package is available ... I built the RPM myself. It's dietlibc-0.28 tarball with no additional patches. http://tmp.logix.cz/SuSE-RPMS/dietlibc-0.28/ Try to compile util-vserver without -O2 - it helped when I had problems in SL9.2 on x86 (however on amd64 it works with -O2). Michal Ludvig - -- * Personal homepage: http://www.logix.cz/michal -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVLmiDDolCcRbIhgRAtrNAJwLdyULc+XmEvKvEu/E6/oQ6zjpFACguMBz CfvELXsx6FyIindZjvq1GkY= =0wGH -END PGP SIGNATURE- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
Herbert Poetzl wrote: > ... is not working on at least two platforms: > > x86_64 (aka amd64) > --- > > tried several dietlibc versions > - dietlibc-0.27-4.src.rpm > - self compiled 0.28 release > - cvs release 31.Mar.2005 > - debian 0.28 version > > all on Fedora Core release 3 (Heidelberg) I'm running SuSE Linux 9.2 on AMD64 and util-linux-0.30.204 work just fine with dietlibc-0.28. Perhaps a compiler issue? My GCC says: gcc version 3.3.4 (pre 3.3.5 20040809) Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] 32bit vserver on amd64
Hi all, I'm running a 32bit vserver on AMD64 host, both are SuSE 9.2 Professional (which is obviously irrelevant here ;-) Started with the default config a logged in with SSH I run 'uname -m' which gives me 'x86_64' which is wrong. I want the vserver to believe it is actually running on x86 hardware. The chroot command must be run from 'linux32' wrapper, something like: # linux32 chroot /vserver/whatever /etc/rc.d/rc 3 So I changed: declare -a VSERVER_EXTRA_CMDS=() to declare -a VSERVER_EXTRA_CMDS=(linux32) in vserver.functions and restarted the vserver. Now it's much better - in SSH session to vserver 'uname -m' says 'i686' which is correct. I'd like to have this as a per-vserver config option. Can I do it somehow? The second "problem" (though nothing critical) is that it still reports 'x86_64' when I run 'vserver whatever exec /bin/uname -m' instead of logging there over SSH. Can this be fixed somehow? Thanks! Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] setattr -> Bad address
Michal Ludvig wrote: > Now it's time for dropping the legacy debian vserver and setting up a > native suse one. Just for the record: This may be of some help for anyone trying to run SuSE Linux 9.2 professional in a vserver and experiencing premature exit of the /etc/rc.d/rc script: --- /etc/rc.d/rc.backup 2005-04-05 03:38:17.0 + +++ /etc/rc.d/rc2005-04-05 03:46:10.0 + @@ -17,6 +17,8 @@ # stop that feature. # +test -z "$RUNLEVEL" && RUNLEVEL=$1 + # # Avoid be interrupted by child or keyboard # @@ -177,7 +179,7 @@ # # Set I/O of this script and its childs to console # -exec 0<> $CONSOLE 1>&0 2>&0 +# exec 0<> $CONSOLE 1>&0 2>&0 # # Dummy shell function Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] setattr -> Bad address
Herbert Poetzl wrote: > On Tue, Apr 05, 2005 at 01:32:59PM +1200, Michal Ludvig wrote: > >>I'm now recompiling without optimalizations and with debug symbols. >>BTW it was linked with dietlibc-0.28 > > if possible, try with a non 3.4.x compiler too (if that > fails for whatever reason) Works fine without -O2. I'll send a bugreport to SuSE about their GCC... Now it's time for dropping the legacy debian vserver and setting up a native suse one. Thanks for your help! Michal Ludvig ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] setattr -> Bad address
Herbert Poetzl wrote:
> On Tue, Apr 05, 2005 at 12:41:12PM +1200, Michal Ludvig wrote:
>
>>puck:root:~# /usr/local/sbin/setattr /proc/uptime
>>/proc/uptime: Bad address
>
>
> that is at least unusual ... you sure the kernel was
> compiled with the vserver patch?
Yes, it is. But the binary is somehow broken:
puck:root:~# strace setattr /proc/uptime
execve("/usr/local/sbin/setattr", ["setattr", "/proc/uptime"], [/* 66
vars */]) = 0
[...]
lstat("/proc/uptime", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
SYS_273(0, 0x3f, 0, 0xb51e, 0x1)= 65573
SYS_273(0x26020001, 0, 0xbfff9fe0, 0xb51e, 0x1) = -1 EFAULT (Bad
address)
[...]
_exit(1)= ?
I'm now recompiling without optimalizations and with debug symbols.
BTW it was linked with dietlibc-0.28
>>2) I created a legacy vserver 'hokpok' with debian-newvserver.sh (0.3.4)
>>from http://www.paul.sladen.org/vserver/debian/
>
> I expect the debian users to do such foolish things ;)
> but now the SuSE folks start using debian-newvserver too?
I just wanted to start from somewhere - never been playing with vservers
before :-)
> please don't! use the tools (vserver build ...)
> to create a new vserver, it will get a proper config
> then ...
Can I automagically create only the configs without building the chroot
tree? There is a nice SuSE tool for installing into directory so I have
the tree ready. Just miss the proper configs...
>>However starting this up dies with
>>---
>>[...]
>>New security context is 49169
>>capchroot: chroot(): Operation not permitted
>
>
> make sure that capabilities are compiled into the kernel
> and not as module ... (or if module that they are properly
> loaded at system bootup)
It is loaded. On the next recompilation I can build it in, but I doubt
it will be any different. I guess the problem is in chcontext-legacy.
>>---
>>Then I even added CAP_SYS_CHROOT and CAP_SYS_ADMIN to the S_CAPS list
>>but to no avail.
>
> don't do that, no caps are required there ... if you
> really use an old (legacy) config please leave S_CAPS=""
I thought legacy should work with the old config. Anyway it doesn't work
even if I omit the "--cap CAP_*" switches.
>>I traced it down to:
>>/usr/local/sbin/chbind --ip 192.168.224.22 --bcast 192.168.224.127 \
>>/usr/local/lib/util-vserver/chcontext-compat --cap CAP_NET_RAW \
>>--cap CAP_SYS_CHROOT --hostname hokpok --secure \
>>/usr/local/lib/util-vserver/legacy/save_s_context \
>>/usr/local/var/run/vservers/hokpok.ctx \
>>/usr/local/lib/util-vserver/capchroot . /etc/init.d/rc 2
>>
>>If I replace chcontext-compat with /usr/local/sbin/chcontext it works
>>much better, so I did _CHCONTEXT_COMPAT=$_CHCONTEXT in util-vserver-vars.
>
>
> that's because you have a legacy config! don't change
> or exchange the tools unless you know what you're doing
> (which you are obviously not ;)
No I don't, but it helped a little bit ;-) I wouldn't have digged here
if it worked before :-)
>>I guess all these problems are caused by the "setattr -> Bad address"
>>issue.
>
> no, but I would investigate this anyway, because
> vprocunhide is very simple ...
If it was miscompiled I guess some other tools may be as well. I'll let
you know if it gets better with non-optimized binaries.
>>Any ideas?
>
> yes, start with the testme.sh and see if it passes all
> tests, if not, then either tools or kernel aren't working
> as expected, and we have to investigate this ...
>
> http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh
Will do...
Thanks,
Michal Ludvig
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] setattr -> Bad address
Hi all, I'm trying to set up vserver on my SuSE Linux 9.2 box running 2.6.11.5 kernel with vserver 1.9.5 patch and util-vserver-0.30.204. I met a number of issues, perhaps because this is the first time I play with vservers. 1) vprocunhide (i.e. setattr) spits out a lot of "Bad address" messages. Even a simple setattr behaves the same way: puck:root:~# /usr/local/sbin/setattr /proc/uptime /proc/uptime: Bad address 2) I created a legacy vserver 'hokpok' with debian-newvserver.sh (0.3.4) from http://www.paul.sladen.org/vserver/debian/ However starting this up dies with --- [...] New security context is 49169 capchroot: chroot(): Operation not permitted --- Then I even added CAP_SYS_CHROOT and CAP_SYS_ADMIN to the S_CAPS list but to no avail. I traced it down to: /usr/local/sbin/chbind --ip 192.168.224.22 --bcast 192.168.224.127 \ /usr/local/lib/util-vserver/chcontext-compat --cap CAP_NET_RAW \ --cap CAP_SYS_CHROOT --hostname hokpok --secure \ /usr/local/lib/util-vserver/legacy/save_s_context \ /usr/local/var/run/vservers/hokpok.ctx \ /usr/local/lib/util-vserver/capchroot . /etc/init.d/rc 2 If I replace chcontext-compat with /usr/local/sbin/chcontext it works much better, so I did _CHCONTEXT_COMPAT=$_CHCONTEXT in util-vserver-vars. 3) Now it even seems it boots up: puck:root:~# vserver -v hokpok start [...] Starting OpenBSD Secure Shell server: sshd. Starting deferred execution scheduler: atd. Starting periodic command scheduler: cron. puck:root:~# but I can't see the context was running with vserver-stat, nor I can enter it with 'vserver hokpok enter /bin/bash' which says: puck:root:~# vserver hokpok enter /bin/bash WARNING: can not find configuration, assuming legacy method WARNING: can not access /proc/uptime. Usually, this is caused by procfs-security. Please read the FAQ for more details http://www.linux-vserver.org/index.php?page=Linux-Vserver+FAQ Error: /proc must be mounted To mount /proc at boot you need an /etc/fstab line like: /proc /proc procdefaults In the meantime, mount /proc /proc -t proc Failed to parse ps-output ipv4root is now 192.168.224.22 vcontext: vc_create_context(): Device or resource busy I guess all these problems are caused by the "setattr -> Bad address" issue. Any ideas? Thanks in advance! Michal Ludvig ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
