Re: [Vserver] test and cowlinks
Jörn Engel wrote: In that case, you can ignore the hashes anyway. Do a direct comparison, nothing lost. I eat my (unquoted) words on this issue; http://www.mail-archive.com/[EMAIL PROTECTED]/msg02554.html http://www.freedom-to-tinker.com/archives/000661.html -- Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] UDP port forwarding bug
At 12:49 Uhr +0200 16.08.2004, Herbert Poetzl wrote: > So, the net effect is: If you configure your vservers to use two ip's (for example: one for "localhost" purposes, and a second for public local host 'purposes' is a bad idea anyway, because linux-vserver networking does some stuff to replace the local '127.0.0.1' by the primary address (which makes using lo completely obsolete) I'm putting "localhost" in into quotes since the localhost string in /etc/hosts is mapped to that ip. I've already learned that vserver has this 127.0.0.1 => primary ip mapping. This suggests that the "locahost" ip (something like 10.0.1.1) should be the primary address - then if some library has 127.0.0.1 hardcoded it is translated by the kernel to the primay address which is then the correct 10.0.1.1 in my example. > access), and use UDP port forwarding from the NAT'ing host, and be so > unlucky that the order how the two ip's are fed to chbind during the vserver startup is that the first ip is *not* the target ip of the forwarding, you're 'sol'. If the utils (I'm currently using alpha utils 0.29.211) would provide a way to tell the order of the ip's, one could at least work around the problem once being aware of it. BTW it does not matter whether you additionally have SNAT rules for outgoing traffic or not. this is expected behaviour because: - the 'first' ip associated with a vserver is considered the 'primary' ip, used for outgoing traffic, if the source ip can no be determined - if you would have copied the output from the netcat -v option, everybody would see that the netcat without -s binds to 0.0.0.0 [any] - current networking (not ngn once finished) can not allow to bind to arbitrary IPs, so it _has_ to decide for one (the primary) in this case ... After some discussion with Herbert on the IRC, I've learned a bit more: - The issue has been brought up by Herbert already half a year ago: http://archives.linux-vserver.org/200311/0470.html - What is the implementation today? Suggestion b) from the above mail has never been implemented. Today, as Herbert says, <<(the kernel) does a good efford on guessing what the right ip should be; it does this mainly based on routing decisions; unfortunately udp binds to 0.0.0.0 do not contain any routing information>>. That explains why TCP port forwarding doesn't show any problem. The solution I'm using now is to use the "localhost" ip of the vservers as target ip in port forwardings. This way (leaving the order of the ip's as is, with the "localhost" as the primary), 127.0.0.1 is still correctly mapped. Christian. ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Problem entering a vserver
On Mon, Aug 16, 2004 at 10:38:38AM +0200, Mike Fischer wrote: > Greetings, > > I set up a new one: > # testme.sh > Linux-VServer Test [V0.07] (C) 2003-2004 H.Poetzl > chcontext is working. > chbind is working. > Linux 2.4.26-vs1.28 i686/0.30/0.30 [E] > --- > [001]# succeeded. > [011]# succeeded. > [031]# succeeded. > [101]# succeeded. > [102]# succeeded. > [201]# failed. > [202]# failed. should not happen ... Linux-VServer Test [V0.07] (C) 2003-2004 H.Poetzl chcontext is working. chbind is working. Linux 2.4.26-vs1.28 i686/0.30/0.30 [E] --- [001]# succeeded. [011]# succeeded. [031]# succeeded. [101]# succeeded. [102]# succeeded. [201]# succeeded. [202]# succeeded. > # vserver test01 enter > ipv4root is now 141.12.26.105 > Host name is now libra-iv > New security context is 49166 > Can't chroot to directory . (Operation not permitted) maybe the result of the broken kernel/userspace? maybe just a simple permission issue on the vserver directory? what does ls -lad /path/to/vserver give? best, Herbert > Any help anyone? > > Kind regards, > Mike Fischer > -- > Fraunhofer Gesellschaft e.V. > IPSI.ITI > > Dolivostr. 15 > 64293 Darmstadt > Telefon: 06151 / 869 - 845 > > ___ > Vserver mailing list > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] UDP port forwarding bug
On Mon, Aug 16, 2004 at 07:38:31AM +0200, Christian Jaeger wrote: > Hello Herbert and Enrico > > There is a problem with UDP port forwarding from a host doing NAT into > vservers which have multiple ip adresses. Depending on the order how > the ip addresses are fed to chbind, the forwarding will work or > not. TCP port forwarding is not affected. > > Steps to reproduce: > > You need two machines, > [H]= vserver- and NAT-enabled host (I'm using 2.4.27 and vs1.3.9) with > netcat. > [R]= remote host; no vserver needed, with netcat. > > Setup on [H]: > (no vservers running and no active iptables rules) > ifconfig eth0 1.2.3.4 > ifconfig lo 127.0.0.1 > ifconfig lo:1loc 10.0.0.1 up > ifconfig lo:1pub 192.168.0.1 up > iptables -t nat -A PREROUTING -i eth0 -d 1.2.3.4 -p udp --dport 666 > -j DNAT --to 192.168.0.1 > > Then: > > Test 1: getting in touch with the problem: > on.. type this.. > [H] netcat -n -l -u -v -p 666 > [R] netcat -n -u 1.2.3.4 666 > bla1 > bla2 > (type two lines of text; the first is getting through to [H], the > second not - netcat terminates, since a "port unreachable" packet is > sent back from H to R upon receiving the second packet.) > > This test just shows that the kernel can behave somewhat strange if > the listener binds to * (0.0.0.0) when a NAT rule is forwarding to a > second address - looks like the kernel is getting confused > somehow. This happens also on a vanilla 2.4.27 kernel. > > Test 2: making the problem disappear using -s flag: > [H] netcat -n -l -u -v -p 666 -s 192.168.0.1 > [R] netcat -n -u 1.2.3.4 666 > bla1 > bla2 > bla3 > ... > You can type as many lines you want, it's all getting through, and any > typing on H is sent to R. > "Kernel is somehow not confused anymore", since netcat is listening > only on the target ip of the DNAT rule. > > Test 3: making the problem disappear using chbind: > [H] chbind --ip 192.168.0.1 netcat -n -l -u -v -p 666 > [R] (same as above) > > The effect is the same as with test 2. > > Test 4: making the problem appear again: > [H] chbind --ip 10.0.0.1 --ip 192.168.0.1 netcat -n -l -u -v -p 666 > [R] netcat -n -u 1.2.3.4 666 > bla1 > bla2 > (netcat stops again) > > Test 5: and making it disappear again: > [H] chbind --ip 192.168.0.1 --ip 10.0.0.1 netcat -n -l -u -v -p 666 > [R] (as always) > Note the reversed order of the ip's. > Connection works again correctly. > > So, the net effect is: If you configure your vservers to use two ip's > (for example: one for "localhost" purposes, and a second for public local host 'purposes' is a bad idea anyway, because linux-vserver networking does some stuff to replace the local '127.0.0.1' by the primary address (which makes using lo completely obsolete) > access), and use UDP port forwarding from the NAT'ing host, and be so > unlucky that the order how the two ip's are fed to chbind during the > vserver startup is that the first ip is *not* the target ip of the > forwarding, you're 'sol'. If the utils (I'm currently using alpha > utils 0.29.211) would provide a way to tell the order of the ip's, > one could at least work around the problem once being aware of it. > > BTW it does not matter whether you additionally have SNAT rules for > outgoing traffic or not. this is expected behaviour because: - the 'first' ip associated with a vserver is considered the 'primary' ip, used for outgoing traffic, if the source ip can no be determined - if you would have copied the output from the netcat -v option, everybody would see that the netcat without -s binds to 0.0.0.0 [any] - current networking (not ngn once finished) can not allow to bind to arbitrary IPs, so it _has_ to decide for one (the primary) in this case ... so it's not a bug, it's a feature ;) HTH, Herbert > Cheers > Christian. > ___ > Vserver mailing list > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Problem entering a vserver
Greetings, I set up a new one: # testme.sh Linux-VServer Test [V0.07] (C) 2003-2004 H.Poetzl chcontext is working. chbind is working. Linux 2.4.26-vs1.28 i686/0.30/0.30 [E] --- [001]# succeeded. [011]# succeeded. [031]# succeeded. [101]# succeeded. [102]# succeeded. [201]# failed. [202]# failed. # vserver test01 enter ipv4root is now 141.12.26.105 Host name is now libra-iv New security context is 49166 Can't chroot to directory . (Operation not permitted) Any help anyone? Kind regards, Mike Fischer -- Fraunhofer Gesellschaft e.V. IPSI.ITI Dolivostr. 15 64293 Darmstadt Telefon: 06151 / 869 - 845 ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
