Aleksandar, I would go for groupOfUniqueNames. We are all conscious of the problem of uniqueMember being mandatory and everybody adopts a different solution for it. My own solution is to use an attribute value of "dummy", but other solutions can be good as well. The advantage of groupOfUniqueNames is that everybody expect it to be a colletion of DNs. This is not true for posixGroup which is a collection of uid restricting the field of application mostly to NIS replacement.
Best regards Giovanni -----Ursprüngliche Nachricht----- Von: Aleksandar Milivojevic [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. Juli 2006 19:13 An: [email protected] Betreff: [ldap] posixGroup vs groupOfUniqueNames Are there any recomendations should I use posixGroup or groupOfUniqueNames for new installations? I found some info on the web about posixAccount being deprecated, and that groupOfUniqueNames should be used instead. However, looking at definition of groupOfUniqueNames object class, the uniqueMember attribute is mandatory. Which makes it impossible to define an empty group (group with no members). Or to remove the last member of the group, but still keep the group for future use. This might be serious problem for migrating data from standard Unix /etc/group file. OK, I could use tricks to go around that (like having dummy member in all groups or using extensibleObject, or defining my own object class). But still. On the other hand, I found info about posixGroup being deprecated (true? false?) and also info that some utilities do not work nicely with posixGroup (for example, Fedora Directory Server seems to work better with groupOfUniqueNames). Or should I maybe try to define both by using a custom objectclass, something like this (to allow me to define both memberUid and uniqueMember attributes). objectclass ( assign-new-oid-here NAME 'myGroup' DESC 'My Group' SUP ( posixGroup $ groupOfUniqueNames ) ) and than define group like: dn: cn=test,ou=group,dc=example,dc=com objectClass: myGroup objectClass: posixGroup objectClass: groupOfUniqueNames cn: test gidNumber: 123 memberUid: user uniqueMember: uid=user,ou=people,dc=example,dc=com Or maybe something like this to go around problem of empty groups: objectclass ( assigne-new-oid-here NAME 'myGroup' DESC 'My Group' SUP top AUXILIARY MAY ( uniqueMember ) ) and define group like (can be empty, eh): dn: cn=test,ou=group,dc=example,dc=com objectClass: myGroup objectClass: posixGroup cn: test gidNumber: 123 Or maybe simply using extensibleObject instead of defining my own object class to acomplish above. -- See Ya' later, alligator! http://www.8-P.ca/ --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message. --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
