On 2012-04-13, at 4:25 PM, Rob Crittenden wrote:

> Kelvin Edmison wrote:
>> 
>> On 2012-04-13, at 1:18 PM, Rob Crittenden wrote:
>> 
>>> Kelvin Edmison wrote:
>>>> 
>>>> On 2012-04-13, at 1:09 PM, Rob Crittenden wrote:
>>>> 
>>>>> Kelvin Edmison wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> When troubleshooting what I thought was an NFS4 issue, I have found what 
>>>>>> looks to be a bug in ipa-client-install.
>>>>>> 
>>>>>> On a CentOS 5.8 machine, I ran
>>>>>> ipa-client-install --no-ntp --force --hostname=kelvin-c5.<dnsdomainname>
>>>>>> and successfully bound to the domain.
>>>>>> 
>>>>>> I am now trying to get nfs4 up and running, and found that idmapd was 
>>>>>> not starting.  I traced that back to an empty /etc/sysconfig/network 
>>>>>> file, and ipa-client-install looks to be the cause.
>>>>>> 
>>>>>> [root@kelvin-c5 ~]# ls -al /etc/sysconfig/network 
>>>>>> /etc/sysconfig/network.orig /var/lib/ipa-client/sysrestore/*-network
>>>>>> -rw------- 1 root root  0 Apr 13 11:58 /etc/sysconfig/network
>>>>>> -rw-r--r-- 1 root root 54 Aug 12  2011 /etc/sysconfig/network.orig
>>>>>> -rw-r--r-- 1 root root 54 Aug 12  2011 
>>>>>> /var/lib/ipa-client/sysrestore/477d00fd6ff85634-network
>>>>>> 
>>>>>> I looked back on another CentOS 5 machine we have, and the same problem 
>>>>>> exists there.
>>>>>> 
>>>>>> I was surprised to see that most network services were working when the 
>>>>>> file was empty.  It turns out that many network services start properly 
>>>>>> with an empty /etc/sysconfig/network file, but some do not.  It appears 
>>>>>> to be down to the structure of the test in the init scripts; e.g.
>>>>>> [ "${NETWORKING}" = "no" ]&&    exit 0
>>>>>> vs.
>>>>>> [ "${NETWORKING}" != "yes" ]&&    exit 6
>>>>>> 
>>>>>> So, is this a bug in ipa-client-install?
>>>>>> Can I just copy my network.orig back into place in order to get 
>>>>>> rpcidmapd and friends to run correctly?
>>>>> 
>>>>> Yes, it should be safe to copy that file back. What we try to do is 
>>>>> ensure that the hostmae provided to ipa-client-install is reflected in 
>>>>> /etc/sysconfig/networking.
>>>>> 
>>>>> What rpm version of ipa-client-install are you using?
>>>> 
>>>> ipa-client-2.1.3-1.el5
>>> 
>>> Hmm, strange. I don't think this is specific to el5, you were just the 
>>> lucky contestant to find this bug. Can you provide the contents of the 
>>> original network file? It is probable that our replacement function isn't 
>>> doing the right thing.
>>> 
>> Gladly.
>> 
>> [root@kelvin-c5 ~]# cat /etc/sysconfig/network
>> NETWORKING=yes
>> NETWORKING_IPV6=yes
>> HOSTNAME=kelvin-c5
>> [root@kelvin-c5 ~]#
>> 
>> The hostname is not a FQDN because we are growing from an environment where 
>> the domainname is assigned via DHCP.
> 
> Ok, I'll open a ticket on this. It may be that we assume that the hostname is 
> always found.

Some info that may help reproducing the issue:
On that host, I found that dnsdomainname was returning nothing, which is 
unusual in our environment.  
It turned out that was because the bare hostname (kelvin-c5) was in the 
/etc/hosts for 127.0.0.1.  This was different than other machines we have, and 
deleting the kelvin-c5 from the 127.0.0.1 entry actually made dnsdomainname 
work again.

Regards,
  Kelvin

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to