Georg Rehfeld wrote:
Hi Kurt, John and all others,
Kurt Yoder wrote:
John Dalbec said:
So the dumper immediately reports 'connection refused' when attempting to connect to the taper process. Wrong permissions?
Wrong permissions on what? It's a TCP connection over the loopback. What permissions could possibly affect that? John
Perhaps a dumb question: did you add the amanda server pieces to your inetd.conf file and then restart inetd? "Connection refused" sounds like the amanda server ports aren't open at all.
I guess John has done the (x)inetd part correctly, as his Amanda setup backs up all other partitions. Only the 'directly to tape' ones are affected.
In that case inetd isn't involved at all, Amanda starts a taper and a dumper on the tape-server, the taper tells a listening port and the dumper attempts to connect to that port on localhost, both initiated and dumper pointed to the right port by the Amanda driver.
My (wrong) impression was, that one or both of the processes had to be setuid root, but this isn't neccessary.
From the dumper message 'Connection refused' one knows, that there was some process answering to the incoming request on that port and then actively issuing "no, don't accept you". An inetd misconfig would result in a timeout, a typical firewall action (of dropping packets) too.
Firewalls should typically not interrupt communication between 2 processes on the very same box (as of PORT.USAGE).
My current guess is a misconfigured packet filter on the tape host, but it would be nice, if some network expert jumps into this problem.
regards Georg
It just occurred to me that maybe this is a side effect of /etc/hosts cache poisoning (courtesy of Red Hat Linux 7.3 NSCD). We've been getting e-mail from a netblock in Vietnam that reverse-resolves to "localhost". NSCD caches the reverse lookup and resolves "localhost" to a machine in Vietnam. Does amanda use gethostbyname("localhost") when connecting a dumper to a taper? Would upgrading to the current version change this?
Thanks,
John
