Learn more about these different git repos.
Other Git URLs
Currently a change in an override is only in the compat tree after a restart of 389ds.
There seems to be a possibility to improve this and make the changes available at runtime.
A test case is following:
# sss_cache -u administrator@ad.ipa.cool # ldapsearch -x -b cn=compat,dc=xs,dc=ipa,dc=cool -LLL -o ldif-wrap=no '(&(objectclass=posixaccount)(uid=administrator@ad.ipa.cool))' dn: uid=administrator@ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool cn: Administrator objectClass: posixAccount objectClass: top gidNumber: 967000500 gecos: Administrator uidNumber: 967000500 homeDirectory: /home/ad.ipa.cool/administrator uid: administrator@ad.ipa.cool # sss_cache -u administrator@ad.ipa.cool # ipa idoverrideuser-add 'Default Trust View' administrator@ad.ipa.cool --gecos=FooIsBaX -------------------------------------------------- Added User ID override "administrator@ad.ipa.cool" -------------------------------------------------- Anchor to override: administrator@ad.ipa.cool GECOS: FooIsBaX # ldapsearch -x -b cn=compat,dc=xs,dc=ipa,dc=cool -LLL -o ldif-wrap=no '(&(objectclass=posixaccount)(uid=administrator@ad.ipa.cool))' dn: uid=administrator@ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool cn: Administrator objectClass: posixAccount objectClass: top gidNumber: 967000500 gecos: Administrator uidNumber: 967000500 homeDirectory: /home/ad.ipa.cool/administrator uid: administrator@ad.ipa.cool
Expected result is that a change from ID override in Default Trust View would update entry of that user/group in the compat tree. E.g.
# sss_cache -u administrator@ad.ipa.cool # ldapsearch -x -b cn=compat,dc=xs,dc=ipa,dc=cool -LLL -o ldif-wrap=no '(&(objectclass=posixaccount)(uid=administrator@ad.ipa.cool))' dn: uid=administrator@ad.ipa.cool,cn=users,cn=compat,dc=xs,dc=ipa,dc=cool cn: FooIsBaX objectClass: posixAccount objectClass: top gidNumber: 967000500 gecos: FooIsBaX uidNumber: 967000500 loginShell: /bin/bash homeDirectory: /home/ad.ipa.cool/administrator uid: administrator@ad.ipa.cool
Metadata Update from @abbra: - Issue assigned to abbra
Metadata Update from @abbra: - Issue set to the milestone: 0.56.2
Metadata Update from @abbra: - Custom field Red Hat buzilla adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1473572
A proposed patchset. Includes few more changes to allow building the package too.
<img alt="slapi-nis-id-overrides-update.patch" src="/slapi-nis/issue/raw/files/45c31cea8c8fbefb0bab9bfa0029c19ec114bff9733b3a81327b0fb541398aaa-slapi-nis-id-overrides-update.patch" />
Metadata Update from @abbra: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1473572
@abbra, the patch is really great and I have very few comments about it
In your final patch it is looking like you do not need to rename backend_build_dn into format_build_dn. I am missing something ? If not you could avoid that change.
backend_entry_is_add_related (called on MOD/ADD/DEL) basically checks if the target entry is an AD user/group and remove the related ID_overwrite entry from the map. I do not like the name I would prefer that something like 'backend_entry_del_idoverwrite'. Also the return code is only tested to log a message if the overwrite entry was or not found in the map. Why not logging the message into backend_entry_del_idoverwrite and just return void.
@tbordaz, thanks for the review. Regarding the second part, I think we are going to add more helpers like these. Right now, there is no need for returning a code that would be analyzed by a caller. However, for generic use, the caller would need to perform a certain operation in case there was no action performed by those callbacks. Thus a choice of the non-void return code.
I changed method name to backend_entry_evict_if_related(). This would be more appropriate than what you proposed because we aren't deleting the ID override itself. Instead, we are removing backend entry from a map cache.
backend_entry_evict_if_related()
I'll drop the first patch from this patchset -- it is needed for logically unifying code in upstream but not for this particular fix.
Login to comment on this ticket.