On Tue, Sep 02, 2008 at 09:07:29AM +0200, Manfred Heubach wrote: > > Herbert Poetzl schrieb: > > On Tue, Sep 02, 2008 at 12:31:44AM +0200, Manfred Heubach wrote: > > > >> Hello, > >> > >> I'm experimenting with chbind in order to force the init process > >> (/sbin/init) into a network context with 2 IPs (localhost and a single > >> private IP). > >> > >> I call a script at systemboot called /sbin/vinit (via init=/sbin/vinit) > >> > >> #!/bin/sh > >> exec /usr/sbin/chbind --nid 2 --ip 192.168.2.24 \ > >> --ip 127.0.0.1 -- /sbin/init $@ > >> > >> When using --nid 1 the script is working but the binding to the > >> addresses doesn't work. The processes bind to any available IP. > >> > > > > that's expected, the nid=1 is the spectator network > > context, which is supposed to see all network addresses > > and doesn't restrict the user in any way > > > ok. I expected something like that :-) > > > >> When using --nid 2 the init process stops with the line telling me > >> about it's usage (like when you give the wrong number of arguments) > >> and I am ending up with a kernel panic. > >> > > > > this is most likely due to the fact that init isn't > > the first process in your setup, e.g. it doesn't > > get the 'magic' pid=1 assigned, and as init is written > > in such way (most inits are, although there is no real > > reason for that) that it check for its own pid, and > > works differently (like telinit) when that pid is not > > one ... > > > > > >> Is it actually possible to use chbind on the init process? > >> > > > > yes, that _is_ possible, if done properly > > > > the question is, why would you want to do that? > > > I'm looking for a convenient and reliable way to bind my services on the > host to a single IP and loopback. In the last years i sometimes had the > problem that after an upgrade my wrapper script of e.g. postfix was > overwritten by the orginal init script of the package maintainer. As a > result the mta bound itself to all IPs (which was quite fun as all mail > for the guests was now relayed to the host - which bounced it all - and > having no way to relay himself - well something like a black hole was > the result ...) > > I hope you are aware that all your services, including > > those to logon to the machine would be restricted to > > those IPs for all ethernity ... i.e. it would be similar > > to giving only those IPs to the host in the first place > > > That won't be a problem as long as it is still possible to run the > guests with their own IPs. no, it won't as the script starting the guests, or the sshd, which you use to logon, is already restricted. that is, why I consider 'init' the wrong place :) best, Herbert > >> Otherwise I could build wrappers for my init scripts - > >> I used them with earlier versions - but it's always been a > >> bit improvised. > >> > > > > putting that into 'the' rc script or into separate > > scripts seems to me like the logical choice, as you > > then could allow e.g. terminal logons or even ssh > > logons to administrate the guests > > > > > >> To have the complete root server bound to a network context > >> and only bound to localhost and one ip address would be quite > >> handy. > >> > > > > well, why not just 'restrict' the host to those two > > addresses and be done? > > > Well, i *want* to restrict the host to those two addresses - but how? > > HTC, > > Herbert > > > > > >> Any ideas? > >> > >> The output of vserver-info is below. > >> > >> Best regards > >> Manfred > >> > >> --------------------------- > >> Versions: > >> Kernel: 2.6.26-1-vserver-686 > >> VS-API: 0x00020303 > >> util-vserver: 0.30.215; Jun 1 2008, 21:56:10 > >> > >> Features: > >> CC: gcc, gcc (GCC) 4.1.2 20061115 (prerelease) > >> (Debian 4. 1.1-21) > >> CXX: g++, g++ (GCC) 4.1.2 20061115 (prerelease) > >> (Debian 4. 1.1-21) > >> CPPFLAGS: '' > >> CFLAGS: '-Wall -g -O2 -std=c99 -Wall -pedantic -W > >> -funit-at- a-time' > >> CXXFLAGS: '-g -O2 -ansi -Wall -pedantic -W > >> -fmessage-length=0 - > >> funit-at-a-time' > >> build/host: i486-pc-linux-gnu/i486-pc-linux-gnu > >> Use dietlibc: yes > >> Build C++ programs: yes > >> Build C99 programs: yes > >> Available APIs: v13,net,v21,v22,v23,netv2 > >> ext2fs Source: e2fsprogs > >> syscall(2) invocation: alternative > >> vserver(2) syscall#: 273/glibc > >> crypto api: beecrypt > >> > >> Paths: > >> prefix: /usr > >> sysconf-Directory: /etc > >> cfg-Directory: /etc/vservers > >> initrd-Directory: $(sysconfdir)/init.d > >> pkgstate-Directory: /var/run/vservers > >> vserver-Rootdir: /var/lib/vservers > >>