On Tue, Sep 02, 2008 at 10:27:03PM +0200, Manfred Heubach wrote: > 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). try chbind --nid 1 netstat -l (nid=1 is the spectator context, like xid=1 for processes :) > 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 :-) a good way (for certain services) is to use something like the v* runlevel wrappers we had (and maybe still have?) somewhere ... i.e. make a separate runlevel script called v<service> which only does the chbind and then hand over the real stuff to the <service> script this way, you'll keep them on updates, while benefiting from the changes/upgrades to the wrapped scripts (which you simply disable) > 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 ;-) I think a warning script might be interesting for some folks, but I also think it would be much better to fix most of the runlevel scripts, which report 'success' while the service actually failed (like klogd, ssh, ...) best, Herbert > 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 > >