On Fri, 22 Feb 2019, TomK via FreeIPA-users wrote:
On 2/20/2019 10:58 PM, TomK wrote:
>On 2/20/2019 10:13 PM, Rob Crittenden via FreeIPA-users wrote:
>>TomK via FreeIPA-users wrote:
>>>Getting a scenario where the hostname doesn't resolve to the new IP if
>>>the VM is recreated multiple times against an IPA server.
>>>I've tried clearing the caches on the clients but no luck.?? I have to
>>>allow a specific amount of time to pass before I can use the DNS name
>>>that now points to a different (new) IP that was assigned via DHCP.
>>>This apparently also impacts the automounter and it won't work until
>>>much later either.?? I won't be able to use the NFS mount configured
>>>until then.?? On initial login users need to wait about 5 minutes before
>>>they can login with home folder set to / instead as a result:
>>>Using username "abc.123\sam".
>>>Using keyboard-interactive authentication.
>>>Creating home directory for abc.123\sam.
>>>Last login: Wed Feb 20 02:39:18 2019 from 192.168.0.76
>>>Could not chdir to home directory /n/abc.123/sam: No such file
>>>Has anyone seen this scenario before and have a general high level idea
>>>where I could start to poke??? Seems to me like a DNS Cache Refresh or
>>>Timeout but not sure about the specifics.
>>>/n/abc.123/sam exists and mount works off of other hosts that have been
>>>around for a while.
>>I'd guess it is the DNS TTL. You'd need to lower that in the DNS server.
>>I assume this is some sort of dev or qe box that is re-provisioned
Fixed. At least the above immediate issue. Ended up restarting the
client and the NFS services on the NFS cluster one by one.
I notice now as well that the ID assigned to AD users has changed in
the latest versions of SSSD / IPA. The UNIX Attributes that were
always set in the AD DC are now being respected:
OLD SSSD / IPA:
# id sam(a)abc.123
uid=155601104(sam(a)abc.123) / gid=155601107(nixgrp(a)abc.123)
NEW SSSD / IPA:
# id sam(a)abc.123
uid=10000(sam(a)abc.123) / gid=10000(nixgrp(a)abc.123)
This is probably due to you not forcing a specific ID range type when
creating the trust so it picked up what was able to autodetect, eg.
posix attributes in AD.
Would the ID's on the old IPA / SSSD setup be retained if the old
cluster were to be upgraded?
The change only applies when you are removing trust to
AD and existing
ID ranges. Otherwise it should not change at all.
Show your 'ipa idrange-find' output.
>>FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>To unsubscribe send an email to
>>Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland