 |
 |
Hi Gregory, Hmmm, ok that would seem to explain the problem. When xrootd tries to look up its name it gets a 127.0.0.1 address which actually can't be translated backwards. Weird. I don't know how one manages to force that kind of response (you will probably notice that looking up your workstation's name on your workstation does not produce that kind of result). Not sure what to do about that at the . Can you ask your admins why the NAS box can't resolve it's own name other than to localhost? 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 >>>> >>>> >>> >> >