--On Thursday, March 31, 2005 6:09 PM -0700 Glenn English <[EMAIL PROTECTED]> wrote:
From 'amcheck sls':
Amanda Backup Client Hosts Check -------------------------------- ERROR: server.slsware.dmz: [addr 192.168.20.237: hostname lookup failed] ERROR: log.slsware.dmz: [addr 192.168.20.237: hostname lookup failed] Client check: 5 hosts checked in 10.049 seconds, 2 problems found
If the lookups failed, where did the IPs come from? They are indeed wrong, but the 192.168.20 part is right. There is nothing at 237. It's in the middle of a DHCP pool the PIX firewall uses when the lan wants to talk to the dmz.
tape server appeared to clients as 192.168.0.237, clients attempt to do reverse DNS on server, and either get an answer that has no A records, mismatched A records or don't get an answer at all. I know, the error is a bit cryptic, but less so when you look at it and realise the error came FROM the clients in the dmz.
The pix isn't at fault, lack of rDNS is. get your in-addr.arpa's straightened out and you'll be good to go.
host server.slsware.dmz gives 192.168.20.218 host log.slsware.dmz gives 192.168.20.30
Both are right. The IPs are right in /etc/hosts, too. I ssh to them all the time. And the DNS server is on the same network as the amanda server. The 3 hosts that did not have problems are also on the lan. It's gotta be a pix problem, but I don't understand how amanda could be coming up with that IP. Where does amanda go to do its DNS?
-- Glenn English [EMAIL PROTECTED] GPG ID: D0D7FF20
-- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat
