On 05/27/2016 03:17 PM, Bob Hinton wrote: > Hi Martin, > > On 27/05/2016 14:01, Martin Kosek wrote: >> On 05/25/2016 09:51 PM, Bob Hinton wrote: >>> Hello, >>> >>> We are trying to get Zenoss login authentication to use freeipa over >>> LDAP. Group mappings don't currently work and we think this is because >>> Zenoss requires the groupOfUniqueNames object class. >>> >>> I managed to add the object class to a test VM using >>> vsphere_groupmod.ldif taken from >>> http://www.freeipa.org/page/HowTo/vsphere5_integration - >>> >>> content of vsphere_groupmod.ldif - >>> >>> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >>> changetype: modify >>> add: schema-compat-entry-attribute >>> schema-compat-entry-attribute: objectclass=groupOfUniqueNames >>> - >>> add: schema-compat-entry-attribute >>> schema-compat-entry-attribute: >>> uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2") >>> - >>> >>> apply with - >>> >>> ldapmodify -x -D "cn=Directory Manager" -f vsphere_groupmod.ldif -W >>> >>> However, the following command seemed to freeze - >>> >>> ipa permission-mod "System: Read Group Compat Tree" --includedattrs >>> uniquemember >>> >>> and I had to kill it then subsequent ldapsearch commands froze. >> That's... strange. Looks like a DS bug. > I tried this on one of the three live servers after using ipa-backup on > each of them and it completed without hanging so this suggests a problem > with my test VM rather than a bug. > >> >>> Rebooting the VM seemed to fix things and the groupOfUniqueNames object >>> class appeared in the schema. >>> >>> I'd like to apply this to our live system which uses a master and two >>> replicas running IPA v4.2.0 on RHEL 7.2. >>> >>> Do I need to make the same change to all three servers ? >> Changes in cn=config needs to be done on all servers as the tree is not >> replicated. Normal permission changes are replicated (unless the permission >> is >> about cn=config tree). > Yes. I've now spotted that the change is confined to the single live > server. I'll apply it to the other two when we've got the connectivity > with Zenoss working. >>> Can I leave the >>> replicas connected or do I need to break the replication and >>> re-establish it? >> I do not see reason why you would need to break the replication between >> replicas. >> >>> Do I need the "ipa permission-mod" if so then how do I >>> avoid it freezing ? >> I think the freeze is a bug, I would try reproducing with the latest and >> greatest 389-ds-base (I do not know what version you are using), the bug may >> be >> already fixed (there were some bugs fixed). > My test VM is quite old, since it didn't happen on the live server and > that is more up to date, it suggests either a bug that has been fixed or > a problem with the test VM.
Ok, thanks for info. It looks like you are in a "green state" then :-) Martin >> >> And yes, the command is needed, so that the new attribute is allowed to be >> served. >> >> HTH, >> Martin >> . >> > Thanks > > Bob > -- 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
