-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Debian etch Linux, Amanda v 2.5.1p1 from a debian package.
The 2 clients on the DMZ don't respond; on the LAN all is well. The amanda server is on the LAN, there's a pix between the LAN and the DMZ, and this install / configuration has worked in the past (or maybe I should say 'a configuration pretty close to this one'). Amcheck says they time out waiting for an ACK; tcpdump shows packets arriving at the DMZ client, but nothing leaving (on a working host, there are several packets going back and forth); tcpdump on the server sees many packets running around the LAN, some going to the DMZ, and nothing coming back; disabling the iptables packet filters on the server and the client makes no difference; an entry in the client's daemon log says amandad was contacted; .amandahosts is valid, DNS works both ways, a reverse lookup of the server IP gives exactly the same text as is in .amandahosts, and emptying the file has no effect; when I run amcheck on the server, ps on the client shows amandad running for 30 seconds or so, then stopping, same as it does on a working client; running amandad by hand as the amanda user does the same thing (nothing) on a working or non-working client; if I delete /tmp/amanda, the directory is re-created after an amcheck, but it's empty; nagios successfully checks tftp on the DMZ client with no problems, the pix can write its config file to it, and both the pix and the border router do ntp with the server on the DMZ, so I'm fairly certain about UDP through the pix; I can get to ftp on the DMZ client from the amanda server (also run by inetd and watched over by tcpwrappers); ps shows inetd is running; the modification dates for amandad, tcpd, and inetd are well in the past; reinstalling the amanda client does nothing; rebooting makes no difference; and the hosts on the DMZ are running the same kernel as on the LAN. If this sounds familiar, it is. I had a very similar problem 2 or 3 weeks ago, and that turned out to have happened because I didn't check inetd well enough. I don't think it's inetd this time. I've tried the suggestions I could find via google (and in the responses from the list last time). No joy. Since the LAN works and the DMZ doesn't, it's 'obviously' the pix between them. But there's lots of evidence of packets getting through the pix from the server to the client (and of amandad starting up there). If the pix were blocking the return, I'd expect tcpdump to show packets leaving the DMZ client. But it doesn't, and iptables doesn't see any either. It looks like amandad never tries to answer. Any thoughts? Is there such a thing as a talking amandad? Just thought of something, but tar's mod date is in 2006... - -- Glenn English [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG2gMw04yQfZbbTLYRAh5rAJ4uV4vR96S3d3B/q4kpPVdyRi/oYQCeKwGm PonC1MpFAe6ZYWQxsGrfq5k= =z1yC -----END PGP SIGNATURE-----
