[Freeipa-devel] [PATCH] ldif and acis for config

[Rob Crittenden]

Simo Sorce wrote:
> On Mon, 2007-10-22 at 16:23 -0700, Kevin McCarthy wrote:
>> Simo Sorce wrote:
> 
>>>> +dn: cn=global,cn=config,cn=etc,$SUFFIX
>>>> +changetype: add
>>>> +objectClass: top
>>>> +objectClass: nsContainer
>>>> +objectClass: extensibleObject
>>> ----------------^^^^^^^^^^^^^^^
>>>
>>> /me raise eyebrow, are you *sure* ? :)
>>
>> Nope, definitely not sure.  It would be better if there was some
>> objectClass I could use to store:
>> -name
>> -value
>> -comment
>>
>> so each configuration could have their own entry with a comment.  Do you
>> have any suggestions about how to do that?
> 
> Unfortunately this is a very hard thing with LDAP, and I guess on
> purpose.
> An object class like that could be done, but it would make sense for a
> single conf option, as in LDAP multivalued attributes are not guaranteed
> to keep contents in a specific order.
> 
> objectClass: nameValuePairs
> name: string
> name: number
> name: bool
> value: 1
> value: hey
> value: 42
> comment: my favourite
> comment: the answer
> comment: default
> 
> You see? 
> 
> LDAP is schema, schema is LDAP ...
> 
>>>> +cn: global
>>>> +userSearchFields: uid,givenName,sn,telephoneNumber,ou,title
>>>> +searchTimeLimit: 2
>>>> +maxUidLength: 8
>>>> +passwordExpireNotifyDays: 7
>>> should we keep security policies and GUI configuration in different
>>> entries ?
>> Sure.  Are you thinking
>> cn=policy,cn=config,cn=etc...
>>   and
>> cn=gui,cn=config,cn=etc
>>
>> For me the passwordExpireNotifyDays was a parameter I was going to use
>> in the GUI - for when to show a message at the top of the page.
> 
> This may be policy or both, the problem is defining a decent structure
> for cn=etc, so different components knows what to look at and there is
> no ambiguity.
> 
> Should we also make clear that this tree is for IPA components only ?
> Or should we allow (as a guideline) third party apps to store configs
> there?
> In such case, we should define a clear way to create entries, so that we
> do not have name space conflicts or other ambiguities.
> 
>>>> +aci: (target="ldap:///cn=*,cn=config,cn=etc,$SUFFIX")(version 3.0;
>>>> acl "Enable anonymous access to config"; allow (read, search, compare)
>>>> userdn="ldap:///anyone";)
>>> Is this not readable right now already?
>>> /me can't remember if we are denying anonymous access right now.
>> Don't know.  I haven't written the code to try to read it just yet.
> 
> ldapsearch -x -h localhost -b cn=etc,<basedn>
> 
> Simo.
>

I think what we need is for someone with more LDAP experience to say 
"You need to use the 'foo' objectclass and put it in the tree 'here'."

Kevin and I aren't intimate with all the various object classes nor did 
we design the tree.

So somebody needs to step up and tell us where to put stuff and what to 
put it in. Otherwise we'll keep going through these iterations of us 
trying our best to pick a spot and an OC and getting told on the one 
hand that it won't work but on the other it might but not very nicely.

So the choices are be told how to do this or I'll put it into a flat 
file, and I'm not joking (nor am I particularly cranky, just weary of 
this constant back and forth about object classes and DNs).

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20071023/35975bd9/attachment.bin>