> writing a simple test application/scenario > which show this specific issue in a way I > can reproduce ... (proftpd isn't an option, > as this works for me too ;) No problem, here goes:
The problem: usr:/home# perl -le 'use IO::Socket::INET;$s=IO::Socket::INET->new(Proto=>"tcp",Listen=>5,LocalAddr=>"192.168.168.168");print $s;print $s->sockport()' Can't call method "sockport" on an undefined value at -e line 1. The workaround: usr:/home# chbind --ip 192.168.168.168 perl -le 'use IO::Socket::INET;$s=IO::Socket::INET->new(Proto=>"tcp",Listen=>5,LocalAddr=>"192.168.168.168");print $s;print $s->sockport()' ipv4root is now 62.233.189.138 IO::Socket::INET=GLOB(0x81f38e4) 57749 voile'a. And a probable solution as to why muddleftpd and other ftpds are working fine in this situation - They are buggy! proftpd opens socket for a client only on IP on which that client came from, if they open socket on ALL IPs, vserver reacts as expected: usr:/home# perl -le 'use IO::Socket::INET;$s=IO::Socket::INET->new(Proto=>"tcp",Listen=>5);print $s;print $s->sockport()' IO::Socket::INET=GLOB(0x81f3830) 58418 although I initially filed a bug against proftpd for that, it seems like there's some problem in vserver/ctx, and another one in muddleftpd. I think I just written something that qualifies for vserver regress testing;) -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Namagumi namagomi namagoroshi _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
