Subject: Re: [vserver] chbind the init process of the host (/sbin/init)
From: Manfred Heubach <entwicklung@heubach-edv.de>
Date: Tue, 02 Sep 2008 09:07:29 +0200
Tue, 02 Sep 2008 09:07:29 +0200

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.
>> 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
>>     



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.

  
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