Re: [Vserver] Re: quota probs on centos4 guest with gentoo host
Le Dimanche 1 Octobre 2006 23:45, Chuck a écrit : wow didnt even know mtab could go in there... all ive ever had in any of them was style, mark and depends Well, I learned it in a quota HOWTO that was on the old wiki, but I must admit that I don't know where it lays now. took the gentoo ebuild this time 2.6.15-vs2.0.1-gentoo-r5 Well, I think you'll have to compile 2.0.2 ;-) -- ,, (° Nicolas Costes /|\ IUT de La Roche / Yon ( ^ ) Clé publique: http://www.keyserver.net/ ^ ^ Musique libre: http://musique-legale.info/ - http://www.jamendo.com/?s=concept pgpojrbd0Lv9M.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: quota probs on centos4 guest with gentoo host
On Monday 02 October 2006 03:27, Nicolas Costes wrote: Le Dimanche 1 Octobre 2006 23:45, Chuck a écrit : wow didnt even know mtab could go in there... all ive ever had in any of them was style, mark and depends Well, I learned it in a quota HOWTO that was on the old wiki, but I must admit that I don't know where it lays now. took the gentoo ebuild this time 2.6.15-vs2.0.1-gentoo-r5 Well, I think you'll have to compile 2.0.2 ;-) which means its not in the production distribution yet.. so much for keeping this system 100% production package ... hehe -- ,, (° Nicolas Costes /|\ IUT de La Roche / Yon ( ^ ) Clé publique: http://www.keyserver.net/ ^ ^ Musique libre: http://musique-legale.info/ - http://www.jamendo.com/?s=concept -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] centos64 timing out on stop but no service errors
any idea where to look? evidently something isnt exiting cleanly in the guest but my serial monitor stops showing anything at Starting killall: [ OK ] i suspect its something in the halt script? it stopped ok till my tech decided to run yum update on it! that itself isnt bad, but to make things worse he promptly 'cleaned up' by removing all the rpmsave files! so i had to re-edit everything and think i may have missed something. needless to say he is no longer allowed to touch the servers. valkyrie 0 # vserver cntos64-webmin-tmpl stop A timeout occured while waiting for the vserver to finish and it will be killed by sending a SIGKILL signal. The following process list might be useful for finding out the reason of this behavior: -- -- * CentOS64 template Stopped -- Chuck ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] 2.0.2 on 2.6.18 kernel question
does this now mean guests have a way of using 127.0.0.1 remapped in the system rather than through hosts files? so those packages hardcoded with it will work? CONFIG_VSERVER_REMAP_SADDR: This allows to remap the source IP address of 'local' connections from 127.0.0.1 to the first assigned guest IP. -- Chuck ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] having a routing problem from guests
On Fri, Sep 29, 2006 at 11:23:11AM -0400, Chuck wrote: On Friday 29 September 2006 09:54, Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) 32net is a /23 and the other 3 networks are /24 the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) actually it did not do what i wanted. we sniffed it this morning... the ping packets destined from the 32net guest for an external 39 net host still go out the 39 net card and get echoed back from the external host and the router sends them back to the 32net card since that was the source ip block, and by setting that to 0 it allowed 32net to accept the packet rather than reject it. what i want is no matter if it is an internal ip or not, for all traffic generated by a guest to go out its default port and come back into it directed by the router if a reply is required such as ping. yet at the same time it would be ideal for all guests to be able to route internally to each other as they do now. the way i want to see i suspect would send the packets external and the router would feed them back down the correct network. am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface we use iproute2 and have one table for each of the 4 networks on the machine.. it is extremely probable i dont have routes or rules set up right. it works like this but i just do not know if this internal routing the host kernel does is expected/desired/normal or not. this is a simplified version of our network setup... simplified=cut out 145 ip addresses from 34 net for saving space.. email runs on the host. eth0 differs in that it has an additional default gateway statement to handle unknown networks. # 32net intel e100 10/100 public switchport 3 vlan32 config_eth0=( 64.113.32.2 netmask 255.255.254.0 broadcast 64.113.33.255 ) routes_eth0=( 64.113.32.0/23 src 64.113.32.2 table 32net ) routes_eth0=( default via 64.113.32.1 table 32net ) try to add 'src 64.113.32.2' here ^^ #default gateway for sysem as a catch-all routes_eth0=( default via 64.113.32.1 ) better get rid of the 'default' only gives you wrong decisions rules_eth0=( from 64.113.32.0/23 table 32net ) #pvtnet tigon3 gbE private switch port 2 config_eth1=( 172.30.0.50 netmask 255.255.255.0 broadcast 172.30.0.255 ) routes_eth1=( 172.30.0.0/24 src 172.30.0.50 table pvtnet ) routes_eth1=( default via 172.30.0.1 table pvtnet ) rules_eth1=( from 172.30.0.0/24 table pvtnet ) # 34net tigon3 gbE public switchport 4 vlan34 config_eth2=( 64.113.34.2 netmask 255.255.255.0 broadcast 64.113.34.255 ) routes_eth2=( 64.113.34.0/24 src 64.113.34.2 table 34net ) routes_eth2=( default via 64.113.34.1 table 34net ) rules_eth2=( from 64.113.34.0/24 table 34net ) # 39net realtek rtl8169 gbE card public switchport 5 vlan39 config_eth3=( 64.113.39.3 netmask 255.255.255.0 broadcast 64.113.39.255 ) routes_eth3=( 64.113.39.0/24 src 64.113.39.3 table 39net ) routes_eth3=( default via 64.113.39.1 table 39net ) rules_eth3=( from 64.113.39.0/24 table 39net ) add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 but if that 'works for you' then it is no big deal, as I said, it's usually off by default ... so then this behavior im forcing will not cause security issues? not necessarily, mostly confusion and sometimes strange delays when a router decides to flush a specific
Re: [Vserver] vserver patch breaks fritzcapi on amd64 / 2.6.17
On Sun, Oct 01, 2006 at 11:00:01AM +0200, Oliver Welter wrote: Hi Folks, bougth an AMD 64 X2 and ran into a problem. When I want to build the fritzcapi module (AVM Fritzcard driver) I get an error (see below). System is a gentoo with 2.6.17 kernel patchset. Any ideas yes, we use the tag_t for context tagging, but obviously the external capi module/stuff, uses that too, so probably the simplest way (as I doubt that the capi module needs the context tagging for files :) to get around that is to remove that type from include/linux/types.h temporarily of course, that's a hack and changing all the tag_t-s in the capi source would be a better approach ... HTH, Herbert Oliver make[1]: Entering directory `/usr/src/linux-2.6.17-vserver-2.1.1-rc31' CC [M] /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/main.o CC [M] /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/driver.o In file included from /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/tables.h:31, from /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/driver.c:45: /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/queue.h:32: error: conflicting types for 'tag_t' include/linux/types.h:43: error: previous declaration of 'tag_t' was here In file included from /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/tables.h:31, from /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/driver.h:31, from /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/main.c:45: /var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/queue.h:32: error: conflicting types for 'tag_t' include/linux/types.h:43: error: previous declaration of 'tag_t' was here make[2]: *** [/var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/main.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [/var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src/driver.o] Error 1 make[1]: *** [_module_/var/tmp/portage/fritzcapi-2.6.43/work/usr/src/kernel-modules/fritzcapi/fritz.pci/src] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.17-vserver-2.1.1-rc31' make: *** [fcpci.ko] Error 2 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] 2.0.2 on 2.6.18 kernel question
On Mon, Oct 02, 2006 at 08:23:12AM -0400, Chuck wrote: does this now mean guests have a way of using 127.0.0.1 remapped in the system rather than through hosts files? so those packages hardcoded with it will work? yes and no, it means that on connections originating from inside a network context, a source address of 127.0.0.1 will be remapped to the first assigned guest IP, which might help with some services, but might also cause some services (which check for a src ip of 127.0.0.1 explicitly) to fail, thus it is an option HTC, Herbert CONFIG_VSERVER_REMAP_SADDR: This allows to remap the source IP address of 'local' connections from 127.0.0.1 to the first assigned guest IP. -- Chuck ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] having a routing problem from guests
On Monday 02 October 2006 10:18, Herbert Poetzl wrote: cool thanks... ill make those changes and see how it works :) On Fri, Sep 29, 2006 at 11:23:11AM -0400, Chuck wrote: On Friday 29 September 2006 09:54, Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) 32net is a /23 and the other 3 networks are /24 the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) actually it did not do what i wanted. we sniffed it this morning... the ping packets destined from the 32net guest for an external 39 net host still go out the 39 net card and get echoed back from the external host and the router sends them back to the 32net card since that was the source ip block, and by setting that to 0 it allowed 32net to accept the packet rather than reject it. what i want is no matter if it is an internal ip or not, for all traffic generated by a guest to go out its default port and come back into it directed by the router if a reply is required such as ping. yet at the same time it would be ideal for all guests to be able to route internally to each other as they do now. the way i want to see i suspect would send the packets external and the router would feed them back down the correct network. am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface we use iproute2 and have one table for each of the 4 networks on the machine.. it is extremely probable i dont have routes or rules set up right. it works like this but i just do not know if this internal routing the host kernel does is expected/desired/normal or not. this is a simplified version of our network setup... simplified=cut out 145 ip addresses from 34 net for saving space.. email runs on the host. eth0 differs in that it has an additional default gateway statement to handle unknown networks. # 32net intel e100 10/100 public switchport 3 vlan32 config_eth0=( 64.113.32.2 netmask 255.255.254.0 broadcast 64.113.33.255 ) routes_eth0=( 64.113.32.0/23 src 64.113.32.2 table 32net ) routes_eth0=( default via 64.113.32.1 table 32net ) try to add 'src 64.113.32.2' here ^^ #default gateway for sysem as a catch-all routes_eth0=( default via 64.113.32.1 ) better get rid of the 'default' only gives you wrong decisions rules_eth0=( from 64.113.32.0/23 table 32net ) #pvtnet tigon3 gbE private switch port 2 config_eth1=( 172.30.0.50 netmask 255.255.255.0 broadcast 172.30.0.255 ) routes_eth1=( 172.30.0.0/24 src 172.30.0.50 table pvtnet ) routes_eth1=( default via 172.30.0.1 table pvtnet ) rules_eth1=( from 172.30.0.0/24 table pvtnet ) # 34net tigon3 gbE public switchport 4 vlan34 config_eth2=( 64.113.34.2 netmask 255.255.255.0 broadcast 64.113.34.255 ) routes_eth2=( 64.113.34.0/24 src 64.113.34.2 table 34net ) routes_eth2=( default via 64.113.34.1 table 34net ) rules_eth2=( from 64.113.34.0/24 table 34net ) # 39net realtek rtl8169 gbE card public switchport 5 vlan39 config_eth3=( 64.113.39.3 netmask 255.255.255.0 broadcast 64.113.39.255 ) routes_eth3=( 64.113.39.0/24 src 64.113.39.3 table 39net ) routes_eth3=( default via 64.113.39.1 table 39net ) rules_eth3=( from 64.113.39.0/24 table 39net ) add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 but if that 'works for you' then it is
Re: [Vserver] having a routing problem from guests
On Monday 02 October 2006 10:18, Herbert Poetzl wrote: oops... forgot.. ok so then i would add the statements below with proper ip for each of the 4 interfaces? add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] centos64 timing out on stop but no service errors
Chuck wrote: any idea where to look? evidently something isnt exiting cleanly in the guest but my serial monitor stops showing anything at Starting killall: [ OK ] i suspect its something in the halt script? it stopped ok till my tech decided to run yum update on it! that itself isnt bad, but to make things worse he promptly 'cleaned up' by removing all the rpmsave files! so i had to re-edit everything and think i may have missed something. needless to say he is no longer allowed to touch the servers. valkyrie 0 # vserver cntos64-webmin-tmpl stop A timeout occured while waiting for the vserver to finish and it will be killed by sending a SIGKILL signal. The following process list might be useful for finding out the reason of this behavior: -- -- * CentOS64 template Stopped Is this fully reproducible, i.e. do you get it every time you try to stop that particular guest? If so, would it be possible for you to stop by the IRC channel (#vserver at irc.oftc.net) some time tomorrow (Oct 3rd, I'll probably be around after 11 AM UTC) for some more interactive debugging? -- Daniel Hokka Zakrisson GPG id: 06723412 GPG fingerprint: A455 4DF3 990A 431F FECA 7947 6136 DDA2 0672 3412 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] centos64 timing out on stop but no service errors
On Monday 02 October 2006 18:59, Daniel Hokka Zakrisson wrote: Chuck wrote: any idea where to look? evidently something isnt exiting cleanly in the guest but my serial monitor stops showing anything at Starting killall: [ OK ] i suspect its something in the halt script? it stopped ok till my tech decided to run yum update on it! that itself isnt bad, but to make things worse he promptly 'cleaned up' by removing all the rpmsave files! so i had to re-edit everything and think i may have missed something. needless to say he is no longer allowed to touch the servers. valkyrie 0 # vserver cntos64-webmin-tmpl stop A timeout occured while waiting for the vserver to finish and it will be killed by sending a SIGKILL signal. The following process list might be useful for finding out the reason of this behavior: -- -- * CentOS64 template Stopped Is this fully reproducible, i.e. do you get it every time you try to stop that particular guest? If so, would it be possible for you to stop by the IRC channel (#vserver at irc.oftc.net) some time tomorrow (Oct 3rd, I'll probably be around after 11 AM UTC) for some more interactive debugging? it is every time.. ill try.. i have a huge workload at the moment with 'immediate' requests from the boss.. if i can get those cleaned up i will have time otherwise it will have to be another day. but yes i would like to get this working properly... its not affecting anything other than my sanity at seeing an error :) and taking probably a bit longer due to timeout than normal. to be honest, once i get the template into production guests, they may only get shut down once a year if that so its not a huge issue other than me wanting it perfect. if i can get thru this workload tonight, ill be there otherwise, ill let you know or just show up if you are usually there after that time on a day when i can. -- Daniel Hokka Zakrisson GPG id: 06723412 GPG fingerprint: A455 4DF3 990A 431F FECA 7947 6136 DDA2 0672 3412 ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
