Subject: Re: [vserver] chbind the init process of the host (/sbin/init)
From: Manfred Heubach <entwicklung@heubach-edv.de>
Date: Tue, 02 Sep 2008 22:27:03 +0200
Tue, 02 Sep 2008 22:27:03 +0200
Hello Gyu, hello Herbert,

well - o.k. as I cannot restrict the init process to certain IPs and use
different IPs for the guests at the same time -  I will think this all over.
I have once written a script which checks all init scripts and wraps
them if necessary. I just have to adjust this script to wrap them into
e.g. --nid 2.
netstat -l will not show the sockets in --nid 2
chbind --nid 2 netstat -l will *only* show those in --nid 2
So if I want to get a quick overview what's listening I will end up with
2 commands (I can build an alias for that).

Maybe it's better to forget about the wrapper and configure the services
to bind only to the right IPs. I will still have a problem with services
that don't offer such an option - but these are hopefully none of which
I need :-)

Is someone interested in a script which checks that services on the host
aren't bound to *:port. I think about this as a sanity check before
starting a vserver - so a misconfigured host won't mess up the guests.
This won't be bullet proof. You can still stop a service in the guest,
then restart the same service on the host and you end up with the host
bound to the IP of a guest. But it seems to be a good way not to shoot
yourself in the foot in the first place ;-)

Some comments follow below.

Thanks
Manfred

PÁSZTOR György schrieb:
> Hi,
>
> "Manfred Heubach" <entwicklung@heubach-edv.de> írta 2008-09-02 14:12-kor:
>   
>> PÁSZTOR György schrieb:
>>     
>>> Hi!
>>>
>>> "Manfred Heubach" <entwicklung@heubach-edv.de> írta 2008-09-02 09:07-kor:
>>>   
>>>       
>>>>> 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?
>>>>     
>>>>         
>>> I don't understand your attitude. Why do you want to run services on the
>>> host, if you use vserver?
>>>
>>>   
>>>       
>> I use vserver mainly for server consolidation. This is why I have some
>> more services on the host itself (syslog-ng, mta, bacula, raid-console,
>> ssh, snmp, ...).
>>     
> Yepp, so do I.
>
> But with some differences:
>
> syslog-ng -> I run it on a dedicated management server. If the host
> dies we still have its logs.
>   
see below - no extra hardware :-(
> MTA -> I don't understand why do you want MTA on the host. On Special
> vservers, which purpose is not to handle the mails I run nullmailer to let
>   
Hey - great stuff - I didn't know about nullmailer until now - and this
after 10 years of Linux with postfix, courier and all the lot.
> my error reports reach it's destination. I have some vservers which runs
> backround service, and don't have public IP but an internal for interchange
> data between servers have. Those nullmailers sends it's message to the
> management host, and that delivers to the sysadmins.
> For the "corporate" mailing I use a vserver, which handles our mails, and
> another vserver which runs webmail things.
>
> Bacula -> I run bacula-fd on the host. But I don't need any other bacula
> things in the guests.
>
> I don't know raid-console. What it is?
>   
It's just the web management console of e.g. 3ware raid controllers (3dm)
> ssh -> I wrote it already: Yes, the (almost) only thing you may want also
> on the host.
>
> snmp -> I collect the traps on the mentioned management machine. What do
> you want to run on the host? I don't trust in snmp things, so I won't allow
> to run snmpd on the host, neither on the guests.
>   
I use snmp for performance and health monitoring - does a great job
together with nagios or munin. Read only and restricted to management
IPs it cannot do much harm.
> ... -> So... Basic approach: Just run sshd (and bacula-fd) on the host.
> Everything else in the guests. If you do the consolidate like this you will
> have easy job, when you have to move a vserver to another host, because of
> decrease the load of a host, etc.
>   
I have customers with only one server (hardware) - so all has to go on
one machine.
> Cheers,
> gyu
>   


Hello Gyu, hello Herbert,

well - o.k. as I cannot restrict the init process to certain IPs and use different IPs for the guests at the same time -  I will think this all over.
I have once written a script which checks all init scripts and wraps them if necessary. I just have to adjust this script to wrap them into e.g. --nid 2.
netstat -l will not show the sockets in --nid 2
chbind --nid 2 netstat -l will *only* show those in --nid 2
So if I want to get a quick overview what's listening I will end up with 2 commands (I can build an alias for that).

Maybe it's better to forget about the wrapper and configure the services to bind only to the right IPs. I will still have a problem with services that don't offer such an option - but these are hopefully none of which I need :-)

Is someone interested in a script which checks that services on the host aren't bound to *:port. I think about this as a sanity check before starting a vserver - so a misconfigured host won't mess up the guests.
This won't be bullet proof. You can still stop a service in the guest, then restart the same service on the host and you end up with the host bound to the IP of a guest. But it seems to be a good way not to shoot yourself in the foot in the first place ;-)

Some comments follow below.

Thanks
Manfred

PÁSZTOR György schrieb:
Hi,

"Manfred Heubach" <entwicklung@heubach-edv.de> írta 2008-09-02 14:12-kor:
  
PÁSZTOR György schrieb:
    
Hi!

"Manfred Heubach" <entwicklung@heubach-edv.de> írta 2008-09-02 09:07-kor:
  
      
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?
    
        
I don't understand your attitude. Why do you want to run services on the
host, if you use vserver?

  
      
I use vserver mainly for server consolidation. This is why I have some
more services on the host itself (syslog-ng, mta, bacula, raid-console,
ssh, snmp, ...).
    
Yepp, so do I.

But with some differences:

syslog-ng -> I run it on a dedicated management server. If the host
dies we still have its logs.
  
see below - no extra hardware :-(
MTA -> I don't understand why do you want MTA on the host. On Special
vservers, which purpose is not to handle the mails I run nullmailer to let
  
Hey - great stuff - I didn't know about nullmailer until now - and this after 10 years of Linux with postfix, courier and all the lot.
my error reports reach it's destination. I have some vservers which runs
backround service, and don't have public IP but an internal for interchange
data between servers have. Those nullmailers sends it's message to the
management host, and that delivers to the sysadmins.
For the "corporate" mailing I use a vserver, which handles our mails, and
another vserver which runs webmail things.

Bacula -> I run bacula-fd on the host. But I don't need any other bacula
things in the guests.

I don't know raid-console. What it is?
  
It's just the web management console of e.g. 3ware raid controllers (3dm)
ssh -> I wrote it already: Yes, the (almost) only thing you may want also
on the host.

snmp -> I collect the traps on the mentioned management machine. What do
you want to run on the host? I don't trust in snmp things, so I won't allow
to run snmpd on the host, neither on the guests.
  
I use snmp for performance and health monitoring - does a great job together with nagios or munin. Read only and restricted to management IPs it cannot do much harm.
... -> So... Basic approach: Just run sshd (and bacula-fd) on the host.
Everything else in the guests. If you do the consolidate like this you will
have easy job, when you have to move a vserver to another host, because of
decrease the load of a host, etc.
  
I have customers with only one server (hardware) - so all has to go on one machine.
Cheers,
gyu