On 04/19/2010 07:03 AM, Daniel Maher wrote: > On 04/16/2010 06:39 PM, Nathan Kinder wrote: > > >> The document you are using off of the wiki is an feature design document >> that was used while developing DNA. Not everything mentioned in there >> is in the plug-in. The ability to use multiple dnaType attributes in >> the same range is one of these things that is not implemented at this time. >> > Fair enough. I assumed that the document entitled ? DNA Plugin Proposal > ? was the design document, and that ? DNA Plugin ? was the proper > documentation. :/ > > >> You can set up two separate ranges, one for the uidNumber attribute and >> another for the gidNumber attribute. While this doesn't guarantee that >> uidNumber == gidNumber for a user, the values will indeed be the same if >> you configure the ranges the same and always let DNA generate the values >> for those attributes. The main issue to deal with to ensure the values >> are the same would be to use a different range of gidNumbers for >> posixGroup entries. >> > It should be as easy as creating two separate entries and then > integrating them both, yes ? ex. : > > dn: cn=UID, cn=DNA > ... > dnatype: uidNumber > dnamagicregen: 99999 > dnanextvalue: 1000 > dnafilter: (objectclass=posixAccount) > ... > > AND > > dn: cn=GID, cn=DNA > ... > dnatype: gidNumber > dnamagicregen: 99999 > dnanextvalue: 1000 > dnafilter: (objectclass=posixGroup) > ... > > Or, should i be creating the two separate entries, but using the > combined filter range (i.e. > (|(objectclass=posixAccount)(objectclass=posixGroup)) ), as you indicate > below ? > You do want two separate config entries. One of them needs to be like your "cn=UID" example above. You have a choice with the second config entry for groups. You can either have one range of GID values for user private groups (the gidNumber attribute in posixAccount entries) and a separate range of GID values to be used for posixGroup entries, OR you can have a single range of GID values that spans across both posixAccount and posixGroup entries. For the former, you would actually have 3 separate config entries. They would look like your above "cn=UID" and "cn=GID" examples with the third entry assigning a separate range of "gidNumber" values with a filter of "(objectclass=posixAccount)". Just be sure to make the range of values for both gidNumbers different. You would do this by putting a cap on the range with the dnaMaxValue setting and setting dnaNextValue appropriately. For making a range of gidNumber values span across posixAccount and posixGroup entries, replace the filter in your above "cn=GID" example with "(|(objectclass=posixAccount)(objectclass=posixGroup))". > >> If you don't care if your gidNumber user private groups match the user's >> uidNumber, you can just create a single gidNumber range with a filter of >> "(|(objectclass=posixAccount)(objectclass=posixGroup))" to have your >> range span your user and group entries. >> > Is that not what i attempted to do (and what is outlined in the spec > doc) ? : > > >> # cat dna_conf > >> dn: cn=UID and GID numbers,cn=Distributed Numeric Assignment > >> Plugin,cn=plugins,cn=config > >> objectClass: top > >> objectClass: extensibleObject > >> cn: UID and GID numbers > >> dnatype: uidNumber > >> dnaType: gidNumber > >> dnamagicregen: 99999 > >> dnafilter: (|(objectclass=posixAccount)(objectclass=posixGroup)) > >> dnascope: dc=example,dc=com > >> dnanextvalue: 1000 > > Note the dnafilter line, which contains the range you specified above. > Yes, but the multiple dnaType settings are the problem here. The DNA plugin does not support this, so the second value (gidNumber) is not loaded. What I was describing would be the above example with the "dnaType: uidNumber" value removed. This would span a range of gidNumber values across both posixAccount and posixGroup entries. You would still need a separate range configured for uidNumber values in posixAccount entries. > In any case, thanks for your commentary and input on this topic thus > far. In our environment, the DNA plugin is the ? killer app ? that we > needed in order to get a Directory Server deployment going. :) > > >
