When we want to do some non-trivial re-engineering in ACLs, on-line configuration using ldapmodify might be cumbersome.
So I think we could slapcat the config database, change ACLs in the output, and slapadd it while the server is offline.
So, if we have a set of >100 ACL rules and we want to add one ACL rule after, say, 22, would we have to *manually* renumber all the ACLs after the new 23 so that they are numbered n+1? Or, when the config db is read, is OpenLDAP able to resolve such conflicts (two ACLs with the same number) and renumber automatically? If so, what is the logic?
(Maintenance of ACLs in the dynamic configuration remains one of my concerns.)
Thanks, Nick
--On Friday, January 13, 2012 11:11 PM +0200 Nick Milas nick@eurobjects.com wrote:
When we want to do some non-trivial re-engineering in ACLs, on-line configuration using ldapmodify might be cumbersome.
So I think we could slapcat the config database, change ACLs in the output, and slapadd it while the server is offline.
So, if we have a set of >100 ACL rules and we want to add one ACL rule after, say, 22, would we have to *manually* renumber all the ACLs after the new 23 so that they are numbered n+1? Or, when the config db is read, is OpenLDAP able to resolve such conflicts (two ACLs with the same number) and renumber automatically? If so, what is the logic?
If you use online modification of ACLs, no, you don't have to manually renumber anything. It will renumber the ACLs for you if you do it correctly. It is also trivial to delete existing ACLs via the online method as well. Doing this via slapcat is going to be much more cumbersome.
For example, if I wanted to delete ACL {21}, and replace it with a new value, I could simply do:
dn: <whatever> changetype: modify delete: olcAccess olcAccess: {21}
dn: <whatever> changetype: modify add: olcAccess olcAccess: {21} my new acl txt
Significantly, you can delete an existing ACL purely by its ACL #. I can also insert ACLs by access number. cn=config takes care of the rest for you.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org