On (17/03/17 13:52), Bob Hinton wrote:
>On 17/03/2017 12:48, Lukas Slebodnik wrote:
>> On (17/03/17 10:40), Bob Hinton wrote:
>>> On 17/03/2017 08:41, Jakub Hrozek wrote:
>>>> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote:
>>>>> Morning,
>>>>>
>>>>> We have a collection of hosts within prod1.local.lan. However, the
>>>>> domain section of the shadow netgroups for the hosts is
>>>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these
>>>>> hosts unless they specify all hosts -
>>>>>
>>>>> -sh-4.2$ getent netgroup oepp_hosts
>>>>> oepp_hosts           
>>>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan)
>>>>> -sh-4.2$ hostname
>>>>> oeppredis001.z4.prod1.local.lan
>>>>> -sh-4.2$ nisdomainname
>>>>> local.lan
>>>>> -sh-4.2$ domainname
>>>>> local.lan
>>>>>
>>>>> The VMs associated with these hosts have recently been migrated and
>>>>> re-enrolled against a new IPA server. The originals all had netgroup
>>>>> domains of local.lan so something must have gone wrong in the migration
>>>>> process. Is there a way to correct the netgroup domains of these hosts,
>>>>> or is the only option to run ipa-client-install --uninstall followed by
>>>>> ipa-client-install to reattach them ?
>>>> Did you remove the sssd cache after the migration?
>>>>     rm -f /var/lib/sss/db/*.ldb
>>>>
>>>> (please make sure the clients can reach the server or maybe mv the cache
>>>> instead of rm so you can restore cached credentials if something goes
>>>> wrong..)
>>>>
>>> Hi Jakub,
>>>
>>> I've now tried removing the sssd cache on one of the offending servers
>>> and it's not made any difference.
>>>
>>> getent netgroup oepp_hosts
>>>
>>> when run from any host enrolled to the new IPA servers, including the
>>> IPA masters themselves produces the results with "mgmt.prod" included
>>> and the same thing run on any of the pre-migrated servers that are still
>>> commissioned produces them without, so I assume that the netgroup domain
>>> information is coming from the IPA masters rather than the local host.
>>>
>> Could you provide content of LDIF from IPA server?
>> For this netgroup/hostgroup
>>
>> LS
>
>Hi Jakub,
>
>I extracted the following from the userRoot ldif produced by "ipa-backup
>--data".
>
>It appears to have the incorrect domain set against nisDomainName. Could
>this be changed with ldapmodify ?
>
>Thanks
>
>Bob
>
># entry-id: 1485
>dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan
>ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b
>modifyTimestamp: 20170222163643Z
>createTimestamp: 20170222163643Z
>modifiersName: cn=Managed Entries,cn=plugins,cn=config
>creatorsName: cn=Managed Entries,cn=plugins,cn=config
>mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
>description: ipaNetgroup oepp_hosts
>memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
>cn: oepp_hosts
>nisDomainName: mgmt.prod.local.lan
And value of this attribute is an explanation to your question
why there is a different domain in netgroups.

>objectClass: ipanisnetgroup
>objectClass: ipaobject
>objectClass: mepManagedEntry
>objectClass: ipaAssociation
>objectClass: top
>nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to