From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408 Description of problem: The documentation for setting up LVS for passive ftp is incomplete. The ftp server needs to be configured to report the IP of the service and not the IP of the real server in order for passive ftp connections to work Version-Release number of selected component (if applicable): rhl-ig-as-x86(EN)-2.1-HTML-RHI (2002-03-22T11:09-0400) How reproducible: Always Steps to Reproduce: 1. configure ftp as described in chapter 8 2. connect to the service 3. switch to passive mode 4. issue an ls command Actual Results: unable to connect to IP of real server Expected Results: passive connection to the floating IP for the FTP virtual server Additional info: this setting needs to be done on the ftp server. for wu-ftpd one needs to add the following lines to /etc/ftpaccess: passive address <real IP> <localnet> passive address 127.0.0.1 127.0.0.0/8 passive address <virtual IP> 0.0.0.0/0 e.g. floating IP is 172.16.10.1 and virtual IP is 192.168.1.1 netmask for both networks is 255.255.255.0 passive address 192.168.1.1 192.168.1.0/24 passive address 127.0.0.1 127.0.0.0/8 passive address 172.16.10.1 0.0.0.0/0 this reads as: clients from 192.168.1.0/24 are told to connect to 192.168.1.1 clients from 127.0.0.0/8 are told to connect to 127.0.0.1 clients from anywhere else are told to connect to 172.16.10.1
What topography are you using? NAT routing, right? I'll comment further on this later today after some testing. Thanks, J
My bad, should have stated this. I'm using NAT.
It's okay. I figured so because that's usually when this problem crops up. I am not sure how I managed to *not* mention this. I believe we were trying to figure out a way to do it for all backend FTP servers (instead of just wu-ftp) using /proc/sys/net/ipv4/ip_conntrack_ftp. Unfortunately, during those very hectic days, it didn't happened and I somehow managed to forget to tell the user *at all* about how to assign the proper "return address" to the real FTP servers :-( Today I am working with QA to get an ipv4 workaround up and running. Failing that, I will post your comments and a general overview of the issue as an errata. Thank you so much for the catch! Johnray p.s. We did not ship vsftpd w/ AS, but there is now a way to do this in the vsftp config file as well, thanks to a patch by Mike McClean (a.k.a. super-genius)
Okay, so we found an even better way of doing FTP that makes the whole process embarassingly simple (embarassing for me at least, since I wrote the docs). I will have to post it tommorrow as QA is testing it now, but I'll leave you with this tidbit: insmod /lib/modules/KERNEL-VERSION/kernel/net/ipv4/ipvs/ip_vs_ftp.o This module may obsolete the arcane iptables approach outlined in the manual. It also frees you to use whatever type of FTP server you want and whatever platform you want on the backend w/ no extra configuration. K, more tomorrow. Johnray
I am adding Mike M to this bug as he will have some great feedback :-) J
okay, so the beta cycle wooped our butts. It looks like detailed documentation on the best procedure is about two weeks out. I am leaving this open until then. However, for now you should be able to insmod /lib/modules/KERNEL-VERSION/kernel/net/ipv4/ipvs/ip_vs_ftp.o And flush iptables rules and things should work. Let me know if they don't. This will help with our testing. Thanks for the feedback and I will let you know when we post the final docs on this. Johnray
insmod generally finds the right module: % insmod ip_vs_ftp
Okay, so I posted an errata on the following Web page in regards to this bug: http://www.redhat.com/docs/errata/RHEL-2.1-Manual/ I leaving the bug open, however as a reminder for the next revision of the docs. Thanks again, Johnray
John -- It looks like Johnray left this bug open to as a reminder to propagate this change into a later release. If this has been done, then this bug can be closed.
Looks like this has been covered in the errata for 2.1AS.