|
On Fri, 22 Dec 2006, Robinson, Eric wrote:
I discovered that the real problem was a bug in ldirectord
where it was using -a to add a rule where it should have
been using -e to edit an existing one.
yes I remember this now. The bug was elsewhere, it wasn't
that you were using the wrong option.
Horms patched ldirectord and I've been happy as a clam
ever since. That is, until I recently realized what was
going on with FTP-DATA connections not being NATed.
so how have clients been getting back their ftp-data packets
till now?
So I read sections 4 and 13 again just now, but I'm no
closer to understanding what to do next. You must admit,
those sections or the HOWTO are pretty fragmented and
difficult to digest.
quite agree. LVS isn't easy, the HOWTO is difficult to read
and people have more trouble with the ftp helper than just
about anything else with LVS.
As far as I can tell, everything is configured correctly.
I'm not using passive FTP (it is not an option) so the ftp
helper question is moot. Also, vsftp running on my
RealServers is using source port 20 for FTP-DATA, just as
it should, so problems related to using unpriviledged
ports are also ruled out.
OK.
I don't have any good ideas from here. This is just a
routine set of checks
o do you have the port=20 option (forget syntax) when
loading your ftp helper?
o you have no iptables rules on the director/realservers?
o does passive ftp work, even if not an option for
deployment?
o on the realservers, do you see the ftpd attempt to
open the ftp-data connection?
o if so, do you see the ftp-data connection in the output of
ipvsadm with the options which show the connections (don't
have ipsvadm with me here).
o if so, do you see the ftp-data packets on the director
with tcpdump.
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
|
