On Wed, Sep 03, 2008 at 09:30:33AM +0200, Manfred Heubach wrote: > > Herbert Poetzl schrieb: > > 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 :) > > > > > Then maybe this is a bug. > chbind --nid 1 netstat -l neither shows sockets without any > nid nor sockets in nid 2 all sockets have a nid (host nid=0, spectator=1) [root]$ nc -l -p 100 & [root]$ chbind --nid 2 --ip 127.0.0.1 -- nc -l -p 200 & [root]$ lsof -ni COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nc 259 root 3u IPv4 102 TCP *:100 (LISTEN) [root]$ chbind --nid 1 -- lsof -ni COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nc 259 root 3u IPv4 102 TCP *:100 (LISTEN) nc 264 root 3u IPv4 107 TCP *:200 (LISTEN) [root]$ chbind --nid 2 -- lsof -ni COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nc 264 root 3u IPv4 107 TCP *:200 (LISTEN) note: if you have CONFIG_VSERVER_PRIVACY=y then the spectator context is disabled in most cases including the network information > (Why does the output below show 0.30.215 when actually 0.30.216 is > installed - strange ...) > > --------------------------- > Versions: > Kernel: 2.6.26-1-vserver-686 > VS-API: 0x00020303 > util-vserver: 0.30.215; Jun 1 2008, 21:56:10 well, I'd say it is 0.30.215 at least at heart :) maybe you installed two competing versions of util-vserver in different locations? HTH, Herbert > 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 > > > >> 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 > >>> > >>>