[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Loading LDAP schema files into cn=config

Nick Milas wrote:

On 3/7/2011 2:18 ÏÎ, Howard Chu wrote:


We've been discussing this problem for quite a while. My current
thinking is that somehow we can use attribute options to help.
Visually it might be better to associate the option with the original
attribute, e.g.
     olcAccess:
     olcAccess;x-comment:
This would require defining a new (and strange) type of attribute
option though, since the value with the option has no relation
(syntactically) to the original attribute type.




Thank you for this discussion.

I think it might not matter which of the two is the implementation, as
long as the "description"  (either "olcWhatever;x-comment:" or
"description;x-olcWhatever:") is available and multi-valued for each and
every attribute and if it can easily stay together with the entry
concerned, and easily displayed in relation to it as well (yes, visual
behavior for comments is important!). For example, for olcAccess,
modifying an example from:
http://www.openldap.org/doc/admin24/access-control.html, if we create
the attribute values:

      olcAccess: to attrs=member,entry
           by dnattr=member selfwrite
      description;x-olcAccess: (0) Access rules for attrs: member,entry
      description;x-olcAccess: (0) Entered by Nick on 7/12/2012
      olcAccess: to dn.children="dc=example,dc=com"
           by * search
      description;x-olcAccess: (1) Allow search on children of example.com
      description;x-olcAccess: (1) Entered by Nick on 7/12/2012
      olcAccess: to dn.children="dc=com"
           by * read
      description;x-olcAccess: (2) Allow only read on children of com
      description;x-olcAccess: (2) Entered by Nick on 7/12/2012
Interleaved values such as above may never be returned by an LDAP Search operation. Whether it's desirable for a client to reorganize the data to display as such, I have no opinion.
I note that the accesslog overlay already allows you to track the history of individual changes to attributes, so recording an "Entered by <name> on <date>" comment seems both redundant and vague. 


we should be able to easily display:

      olcAccess: {0}to attrs=member,entry
           by dnattr=member selfwrite
      description;x-olcAccess: (0) Access rules for attrs: member,entry
      description;x-olcAccess: (0) Entered by Nick on 7/12/2012
      olcAccess: {1}to dn.children="dc=example,dc=com"
           by * search
      description;x-olcAccess: (1) Allow search on children of example.com
      description;x-olcAccess: (1) Entered by Nick on 7/12/2012
      olcAccess: {2}to dn.children="dc=com"
           by * read
      description;x-olcAccess: (2) Allow only read on children of com
      description;x-olcAccess: (2) Entered by Nick on 7/12/2012

I assume, all the above should be easier and more intuitive to achieve
using the "olcAccess;x-comment:" approach (even if it's more difficult -
as you say - to implement).


--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/