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
>>>>
>>>>
>>>
>>
>
|