Hi,
My amanda server is having problems connecting to a client. It's working great with a
number of other clients, but this one client keeps trying to frustrate me.
I have developed a little step by step procedure for installing amanda clients on my
servers so I can quickly copy/paste most things to avoid mistake. Let me preface this
by saying I used the same self-made guide for setting up a bunch of other clients, as
well as this problem client... and the other ones are working great (one RedHat 7.1
servers, multiple RedHat 9 servers, and a few RedHat 7.3 servers as well).
There are 2 firewalls inbetween the client and the server. The client (a RedHat 7.3
box) was running iptables, but since we have it behind a hardware firewall I've even
tried doing "iptables --flush" and the problem remains with iptables wide open (the
default is set to ACCEPT).
In the server's firewall, I've turned on full logging and doing see anything being
logged at all. If I try a client-side-restore (even though the client has never been
backed up before), it works ok and lets me connect to the server, and I see
appropriate entries in the server's firewall's logs.
However every time I try doing amcheck, the client's self check times out.
Here's what I see in the client's firewall's logs when I attempt to amcheck it. (the
public IP's have been changed)
Date/Time: 2003-07-28 15:26:16
Source Address/Port: 1.2.3.4:694
Translated Address/Port: 1.2.3.4:694
Destination Address/Port: 192.168.250.120:10080
Service: UDP PORT 10080
Duration: 3 sec.
Bytes Sent: 163
Bytes Received: 191
Every time it's the same.. 163 bytes sent, 191 bytes received, but still the amcheck
says "host down?"
Here is the ./configure I'm using on the clients: ./configure --with-user=amanda
--with-group=amanda --with-amandahosts --prefix=/usr/local --with-config=Daily
--without-server --with-tcpportrange=44200,44209 --with-udpportrange=790,799
On the client, /etc/hosts has an entry for the server, "theisland"... /etc/hosts.allow
is set up properly (amanda : theisland : ALLOW), /etc/services contains all of my
custom UDP and TCP ports as well as the defaults of 10080 (tcp/udp), 10082 and 10083
(tcp)...
This is my xinetd.conf entry for amanda:
service amanda
{
socket_type = dgram
protocol = udp
user = amanda
server = /usr/local/libexec/amandad
wait = yes
}
(I've heard some people suggest putting "disable = no" in there but when I do, the
system complains that it's not a valid entry, so I've removed it)
lsof shows that amanda is listening... though I don't recognize the numbers, it
shouldn't really matter since the firewalls are currently set up to allow all traffic
between the amanda server and this client.
xinetd 876 root 5u IPv4 1393 UDP *:amanda
I can run amandad as the amanda user and it doesn't give me any errors. When I run it,
it does create a /tmp/amanda/amandad.*.debug file... However when I try to run amcheck
on the server, it doesn't ever create any /tmp/amanda/ debug files. amanda:amanda does
own /tmp/amanda and has permission to create files there..
I did "service xinetd reload" "service xinetd restart".. as well as rebooted the
entire machine..
No error messages in /var/log/messages or /var/log/secure that I can see.
/home/amanda/.amandahosts is set up... "theisland amanda"
/home/amanda's permissions are correct.. as are the permissions in
/usr/local/var/amanda
On the server I do see a lot of these entries in /var/log/messages:
Jul 28 05:47:51 theisland kernel: (see the NOTES section of 'man 2 wait'). Workaround
activated.
Jul 28 05:55:16 theisland kernel: application bug: dumper(20085) has SIGCHLD set to
SIG_IGN but calls wait().
Jul 28 05:55:16 theisland kernel: (see the NOTES section of 'man 2 wait'). Workaround
activated.
However I've done some Google searches and these appear to be harmless, plus the fact
that the other servers are being backed up just fine, so I'm not too worried about
that.
I've read through the Amanda FAQ many times, including the multiple entries about the
"selfcheck timeout, host down?" message, but still haven't had any luck.
Just to make sure it wasn't a hardware firewall issue I completely opened up traffic
between the server and this problematic client on both firewalls (with full logging
turned on) and haven't noticed anything more in the logs compared to when I had it
restricted to specific ports (tcp 44200-44300 10080 10082 10083, and udp 10080 /
790-799).
Any ideas of other things to try? Thanks!
Jeremy Martin
