-----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
ghe AT slsware DOT com
-----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-----
|
