 |
 |
Hi Gregory, I spoke with our DNS people and they said it seems that your NAS boxes have a local entry in the /etc/hosts file that maps the DNS name to "localhost". That's wrong. If their is a DNS entry in the /etc/hosts file it should map to the actual IP address. Could you check? Andy ----- Original Message ----- From: "Gregory Schott" <[log in to unmask]> To: "abh" <[log in to unmask]> Cc: "xrootd mailing list" <[log in to unmask]> Sent: Wednesday, March 23, 2005 2:29 PM Subject: Re: latest xrd crashes on the NAS boxes > Hello, > > This was what I see when checking on babar.gridka.de or babar2.gridka.de > (redirector). When I run from the NAS boxes I see the other NAS boxes the > same way but the one on which I am running the check displays > "localhost.localdomain localhost". > > For example: > > getent hosts 10.65.1.124 works and gives on this NAS box: > 10.65.1.124 f01-001-124.gridka.de > > also if I run: getent hosts f01-001-116.gridka.de > 10.65.1.116 f01-001-116.gridka.de > > but I get: getent hosts f01-001-116 > 127.0.0.1 f01-001-116 localhost.localdomain localhost > > Regards, > Gregory > > > On Wed, 23 Mar 2005, abh wrote: > >> Hi Gregory, >> >> Does "getent 10.65.1.103" work? That the important one since that's >> what's failing in xrootd. Also, did you that command on the actual NAS >> box? If not, could you try that as well? >> >> Andy >> >> ----- Original Message ----- From: "Gregory Schott" <[log in to unmask]> >> To: "abh" <[log in to unmask]> >> Cc: "xrootd mailing list" <[log in to unmask]> >> Sent: Wednesday, March 23, 2005 1:49 AM >> Subject: Re: latest xrd crashes on the NAS boxes >> >> >>> Hello, >>> >>> the DNS entries of all NAS boxes are ok... aren't they? >>> >>> # for n in 03 04 11 15 16 17 18 21 22 24 ; do getent hosts f01-001-1$n >>> 10.65.1.1$n ; done 10.65.1.103 f01-001-103.gridka.de >>> 10.65.1.103 f01-001-103.gridka.de >>> 10.65.1.104 f01-001-104.gridka.de >>> 10.65.1.104 f01-001-104.gridka.de >>> 10.65.1.111 f01-001-111.gridka.de >>> 10.65.1.111 f01-001-111.gridka.de >>> 10.65.1.115 f01-001-115.gridka.de >>> 10.65.1.115 f01-001-115.gridka.de >>> 10.65.1.116 f01-001-116.gridka.de >>> 10.65.1.116 f01-001-116.gridka.de >>> 10.65.1.117 f01-001-117.gridka.de >>> 10.65.1.117 f01-001-117.gridka.de >>> 10.65.1.118 f01-001-118.gridka.de >>> 10.65.1.118 f01-001-118.gridka.de >>> 10.65.1.121 f01-001-121.gridka.de >>> 10.65.1.121 f01-001-121.gridka.de >>> 10.65.1.122 f01-001-122.gridka.de >>> 10.65.1.122 f01-001-122.gridka.de >>> 10.65.1.124 f01-001-124.gridka.de >>> 10.65.1.124 f01-001-124.gridka.de >>> >>> and >>> >>>> bash-2.05a$ nslookup f01-001-115.gridka.de >>>> Note: nslookup is deprecated and may be removed from future releases. >>>> Consider using the `dig' or `host' programs instead. Run nslookup with >>>> the `-sil[ent]' option to prevent this message from appearing. >>>> Server: 10.97.1.191 >>>> Address: 10.97.1.191#53 >>>> >>>> Name: f01-001-115.gridka.de >>>> Address: 10.65.1.115 >>>> >>>> bash-2.05a$ nslookup 10.65.1.115 >>>> Note: nslookup is deprecated and may be removed from future releases. >>>> Consider using the `dig' or `host' programs instead. Run nslookup with >>>> the `-sil[ent]' option to prevent this message from appearing. >>>> Server: 10.97.1.191 >>>> Address: 10.97.1.191#53 >>>> >>>> 115.1.65.10.in-addr.arpa name = f01-001-115.gridka.de. >>> >>> >>> Cheers, >>> Gregory >>> >>> On Tue, 22 Mar 2005, abh wrote: >>> >>>> Hi Gregory, >>>>> >>>>> However is that something you expect with the new versions and not the >>>>> older ones? If I use the older xrootd version then it works fine >>>>> still. >>>> The way the name resolution worked changed between versions with newer >>>> versions returning a null pointer if the lookup failed (older versions >>>> just returned the ip address in character form). Unfortunately, that >>>> had the side-effect of crashing anyone who didn't check foir a null >>>> pointer. The update now prints a nasty error message and exits the >>>> program. I suppose we technically don't need the name and could use the >>>> ascii form of theip address but without a real name the security stuff >>>> gets mucked up. We made the assumption that there really was no reason >>>> to use unregistered machines (well in production practice anyway). You >>>> can, of course, say that is not a reasonable restriction. >>>> >>>> Andy >>>> >>>> >>> >> >