Part 1: Readability
I know you veterans are probably sick to death of us late-comers asking questions about cn=config. I understand but please hear me out because I feel I have done due diligence; but I still have some concerns with the transition. Workflow has been discussed before, but I suspect it hasn't been fleshed out because the switch from editing schema and ACLs in flat files to LDAP entries reduces readability. I have no problem using cn=config for most configuration attributes, but it gets a lot less user friendly when the value is, what used to be in slapd.conf, a multi-line string. But I could just be missing something. Your help is appreciated.
Attached are some screenshots of editing ACLs and a custom schema via 3 methods: 1. cn=config via ldap client (ie apache directory studio) 2. cn=config via ldif 3. old style slapd.conf
Look at the pictures and pick which method you'd like to use to edit ACLs or a schema:
http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldap.png http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldif.png http://snl.salk.edu/~chiestand/openldap/ACLs-via-slapd.conf.png http://snl.salk.edu/~chiestand/openldap/schema-via-ldap.png http://snl.salk.edu/~chiestand/openldap/schema-via-ldif.png http://snl.salk.edu/~chiestand/openldap/schema-via-slapd.conf.png
I think the choice is clearly old style slapd.conf. Otherwise you miss comments and ordering (until Howard Chu's X-ORDERED ldap extension is implemented), and unlimited whitespace to substantially improve readability.
The LDIF files are a mess because of the way words are split unpredictably by new lines. You can't use a simple search and replace with any hope of it working. Readability would be vastly improved with new lines before keywords (eg to, filter, attrs …) but I don't think it's possible to have ldapsearch output this way.
Editing via an ldap client is easy if you're just editing an attribute here and there, but because of the interacting nature of ACLs and schema elements, poor readability (no newlines) makes editing via an ldap client more difficult (a gui with smart sorting and syntax highlighting could make it better).
Am I just missing workflow techniques or key concepts that improves readability? Or is your advice to just suck it up and get used to it?
Part 2: Deleting entries in cn=config
Quanah Gibson-Mount has said entry deletes are coming in 2.5, is that still the plan? The Roadmap page isn't specific.
What about whole schema deletes? From a sysadmin perspective, I should be able to add, modify, or delete anything from the configuration. For QA reasons, you want to be have the exact configuration you want; not the configuration you want plus legacy boogers.
I understand if this isn't trivial to achieve from the developer perspective. Granted I don't have the whole picture here, but I'd argue that it's worth it.
Lastly, I thank everyone who contributes to OpenLDAP.
--On Monday, March 19, 2012 11:39 AM -0700 Chris Hiestand chiestand@salk.edu wrote:
Part 1: Readability
I know you veterans are probably sick to death of us late-comers asking questions about cn=config. I understand but please hear me out because I feel I have done due diligence; but I still have some concerns with the transition. Workflow has been discussed before, but I suspect it hasn't been fleshed out because the switch from editing schema and ACLs in flat files to LDAP entries reduces readability. I have no problem using cn=config for most configuration attributes, but it gets a lot less user friendly when the value is, what used to be in slapd.conf, a multi-line string. But I could just be missing something. Your help is appreciated.
They were never a multi-line string in slapd.conf, either. You could just format things to pretend they were multi-line strings.
The LDIF files are a mess because of the way words are split unpredictably by new lines. You can't use a simple search and replace with any hope of it working. Readability would be vastly improved with new lines before keywords (eg to, filter, attrs …) but I don't think it's possible to have ldapsearch output this way.
Am I just missing workflow techniques or key concepts that improves readability? Or is your advice to just suck it up and get used to it?
I use Net::LDAP perl module to handle ACL updates. It's quite simple. The same thing could likely be done in python. Plus replacing an entire ACL in cn=config is trivial, since you can delete the existing ACL using the {#} value, and you can insert new ACLs trivially but using a weight of where you want to insert it.
Part 2: Deleting entries in cn=config
Quanah Gibson-Mount has said entry deletes are coming in 2.5, is that still the plan? The Roadmap page isn't specific.
You can optionally enable this at build time in OpenLDAP 2.4.30 for testing. As it is an experimental feature, YMMV.
--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
Hi Quanah-
On Mar 19, 2012, at 2:57 PM, Quanah Gibson-Mount wrote:
I use Net::LDAP perl module to handle ACL updates. It's quite simple. ... Plus replacing an entire ACL in cn=config is trivial, since you can delete the existing ACL using the {#} value, and you can insert new ACLs trivially but using a weight of where you want to insert it.
Would you or the project consider releasing some sample code that demonstrates these things? I think it would be helpful and would likely reduce the number of questions on this subject.
-- dNb
Quanah, all of this is with due respect - I really appreciate how much time you've put into this project.
They were never a multi-line string in slapd.conf, either. You could just format things to pretend they were multi-line strings.
But this is irrelevant within the scope of usability. As far as the sysadmin is concerned, slapd.conf allowed multi-line strings for ACLs and schemas. This yielded great readability as shown in the screenshots in the original message.
I use Net::LDAP perl module to handle ACL updates. It's quite simple. The same thing could likely be done in python. Plus replacing an entire ACL in cn=config is trivial, since you can delete the existing ACL using the {#} value, and you can insert new ACLs trivially but using a weight of where you want to insert it.
I don't think writing a custom ldap client is "simple". Or, as David Blank-Edelman requests, perhaps you have some example code showing how simple it is? I have written ldap scripts in perl, python, and php - so I'm not asking as a newbie. I'm having trouble imagining this being any more user-friendly than a decent LDAP client like Apache Directory Studio - which still isn't as readable as ACL .conf files. One could always pay special attention to the script's output/ui to make it more readable, but that's not trivial; I think something good would require ACL and schema parsing.
You can optionally enable this at build time in OpenLDAP 2.4.30 for testing. As it is an experimental feature, YMMV.
I have seen that in various threads. I'm happy to test it, but primarily I'm interested in cn=config entry deletion being a stable feature eventually. Just my $0.02.
On Mar 19, 2012, at 8:32 PM, Chris Hiestand wrote:
I don't think writing a custom ldap client is "simple". Or, as David Blank-Edelman requests, perhaps you have some example code showing how simple it is? I have written ldap scripts in perl, python, and php - so I'm not asking as a newbie.
So, I should be clear, I'm not trying to get in the middle of your discussion about user interfaces and etc.l with Quanah or express any opinion about it.
I would just love to see some good sample code for OpenLDAP server administration published because I think it would be very helpful to everyone, newbies and people like you and me who have scripted LDAP. I think there are a number of reasons why scripting this stuff can be a bit daunting, especially when it comes to server-specific administration. The Net::LDAP code Quanah references is probably quite simple in form, it is just the details that can be tricky to get right.
To your original point: once those details are clear, I suspect it would be relatively straightforward to write a slapacl command/script that parsed the ACL .conf file format and then used Net::LDAP to twiddle cn=config on a specified server accordingly.
-- dNb
On 20/3/2012 2:32 πμ, Chris Hiestand wrote:
As far as the sysadmin is concerned, slapd.conf allowed multi-line strings for ACLs and schemas. This yielded great readability
Although I also really totally respect project developers and appreciate every single effort for the fine OpenLDAP project, I too believe that there is room for usability improvements in dynamic configuration.
I am mostly using JXplorer for directory edits (including dynamic config), yet there are serious issues with readability and commenting, esp. with ACLs. (One might be interested to see some of my older posts on this matter, e.g.: http://www.openldap.org/lists/openldap-technical/201110/msg00186.html).
Recently, Harry Jede contributed a script to enable better readability (http://www.openldap.org/lists/openldap-technical/201203/msg00191.html), but IMHO this is not the right approach in improving config management. We would greatly appreciate it if the OpenLDAP team could *incorporate* some changes in the dynamic config so as to *help* admins manage the server. Writing custom applications/scripts for this job seems to me a wrong approach; if something causes problems to those exactly for whom it has been designed, then it should be re-evaluated. I am confident that the OpenLDAP people can sense the feelings and experiences of admins providing this feedback. We report with complete trust to the development team.
I don't think writing a custom ldap client is "simple". Or, as David Blank-Edelman requests, perhaps you have some example code showing how simple it is? ... I'm having trouble imagining this being any more user-friendly than a decent LDAP client like Apache Directory Studio - which still isn't as readable as ACL .conf files.
I will have to agree. We can write applications (I use PHP) for directory management (when necessary, e.g. to facilitate complex tasks), but I would kindly request OpenLDAP design and development team to provide some usability features to help us avoid writing applications for configuration management too.
With due respect, Nick
Chris Hiestand wrote:
Part 1: Readability
I know you veterans are probably sick to death of us late-comers asking questions about cn=config. I understand but please hear me out because I feel I have done due diligence; but I still have some concerns with the transition. Workflow has been discussed before, but I suspect it hasn't been fleshed out because the switch from editing schema and ACLs in flat files to LDAP entries reduces readability. I have no problem using cn=config for most configuration attributes, but it gets a lot less user friendly when the value is, what used to be in slapd.conf, a multi-line string. But I could just be missing something. Your help is appreciated.
Attached are some screenshots of editing ACLs and a custom schema via 3 methods:
- cn=config via ldap client (ie apache directory studio)
- cn=config via ldif
- old style slapd.conf
Look at the pictures and pick which method you'd like to use to edit ACLs or a schema:
http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldap.png http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldif.png http://snl.salk.edu/~chiestand/openldap/ACLs-via-slapd.conf.png http://snl.salk.edu/~chiestand/openldap/schema-via-ldap.png http://snl.salk.edu/~chiestand/openldap/schema-via-ldif.png http://snl.salk.edu/~chiestand/openldap/schema-via-slapd.conf.png
I think the choice is clearly old style slapd.conf. Otherwise you miss comments and ordering (until Howard Chu's X-ORDERED ldap extension is implemented), and unlimited whitespace to substantially improve readability.
The LDIF files are a mess because of the way words are split unpredictably by new lines. You can't use a simple search and replace with any hope of it working. Readability would be vastly improved with new lines before keywords (eg to, filter, attrs …) but I don't think it's possible to have ldapsearch output this way.
As an LDAP Admin you're going to have to learn to deal with LDIF anyway. This is the most trivial of complaints and seems to be dealt with every couple of years on these mailing lists.
http://www.openldap.org/lists/openldap-technical/201009/msg00140.html
Editing via an ldap client is easy if you're just editing an attribute here and there, but because of the interacting nature of ACLs and schema elements, poor readability (no newlines) makes editing via an ldap client more difficult (a gui with smart sorting and syntax highlighting could make it better).
The OpenLDAP Project is only concerned with implementing the low level functionality. If you want a GUI, ask the Apache Directory Studio folks.
Am I just missing workflow techniques or key concepts that improves readability? Or is your advice to just suck it up and get used to it?
Part 2: Deleting entries in cn=config
Quanah Gibson-Mount has said entry deletes are coming in 2.5, is that still the plan? The Roadmap page isn't specific.
Not likely.
What about whole schema deletes? From a sysadmin perspective, I should be able to add, modify, or delete anything from the configuration. For QA reasons, you want to be have the exact configuration you want; not the configuration you want plus legacy boogers.
I understand if this isn't trivial to achieve from the developer perspective. Granted I don't have the whole picture here, but I'd argue that it's worth it.
The purpose of cn=config is to support configuration changes on a server without causing any service outage. Supporting Deletes in cn=config is fundamentally opposed to this goal. E.g., deleting an olcDatabase entry cannot be seen as anything other than a service outage - you were serving a database a second ago, now it's gone.
On the other hand, we should certainly provide a slapdelete tool for removing things while slapd is offline. If you have screwed up your configuration so badly that you need to delete something from it, you might as well restart the server anyway.
Lastly, I thank everyone who contributes to OpenLDAP.
On 2012.03.19 14.39, Chris Hiestand wrote:
Editing via an ldap client is easy if you're just editing an attribute here and there, but because of the interacting nature of ACLs and schema elements, poor readability (no newlines) makes editing via an ldap client more difficult (a gui with smart sorting and syntax highlighting could make it better).
i use newlines with apache directory studio just fine:
Le 20 mars 2012 09:32, Nick Milas nick@eurobjects.com a écrit :
On 20/3/2012 2:32 πμ, Chris Hiestand wrote:
As far as the sysadmin is concerned, slapd.conf allowed multi-line strings for ACLs and schemas. This yielded great readability
Although I also really totally respect project developers and appreciate every single effort for the fine OpenLDAP project, I too believe that there is room for usability improvements in dynamic configuration.
I am mostly using JXplorer for directory edits (including dynamic config), yet there are serious issues with readability and commenting, esp. with ACLs. (One might be interested to see some of my older posts on this matter, e.g.: http://www.openldap.org/lists/openldap-technical/201110/msg00186.html).
Recently, Harry Jede contributed a script to enable better readability (http://www.openldap.org/lists/openldap-technical/201203/msg00191.html), but IMHO this is not the right approach in improving config management. We would greatly appreciate it if the OpenLDAP team could *incorporate* some changes in the dynamic config so as to *help* admins manage the server. Writing custom applications/scripts for this job seems to me a wrong approach; if something causes problems to those exactly for whom it has been designed, then it should be re-evaluated. I am confident that the OpenLDAP people can sense the feelings and experiences of admins providing this feedback. We report with complete trust to the development team.
I don't think writing a custom ldap client is "simple". Or, as David Blank-Edelman requests, perhaps you have some example code showing how simple it is? ...
I'm having trouble imagining this being any more user-friendly than a decent LDAP client like Apache Directory Studio - which still isn't as readable as ACL .conf files.
I will have to agree. We can write applications (I use PHP) for directory management (when necessary, e.g. to facilitate complex tasks), but I would kindly request OpenLDAP design and development team to provide some usability features to help us avoid writing applications for configuration management too.
Hi,
As a complement of Apache Directory Studio, I would like to let you know that we are developing an OpenLDAP cn=config web administration interface : http://www.linid.org/projects/linid-om/wiki
You can download it and test it, we would appreciate any feedback on this product. We are of course aware that we still have a lot a features to implement, but the current stable version is already used by some of our customers to manage OpenLDAP configuration.
Clément.
--On Tuesday, March 20, 2012 12:58 AM -0400 "David N. Blank-Edelman" dnb@ccs.neu.edu wrote:
To your original point: once those details are clear, I suspect it would be relatively straightforward to write a slapacl command/script that parsed the ACL .conf file format and then used Net::LDAP to twiddle cn=config on a specified server accordingly.
From one of my scripts, that adjust acls 3, 7, and 8 for anonymous vs user
only read access:
if($options{d}) { @acls=( '{3}to attrs=objectclass by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by dn.base="uid=zmamavis,cn=appaccts,cn=zimbra" read by users read by * none', '{7}to filter="(!(zimbraHideInGal=TRUE))" attrs=cn,co,company,dc,displayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,postalCode,sn,st,street,streetAddress,telephoneNumber,title,uid,homePhone,pager,mobile,userCertificate by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by users read by * none', '{8}to attrs=zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCanonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress,zimbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwardingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus,zimbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeliveryDisabled by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by dn.base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * none', ); }
if ($options{e}) { @acls=( '{3}to attrs=objectclass by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by dn.base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * read', '{7}to filter="(!(zimbraHideInGal=TRUE))" attrs=cn,co,company,dc,displayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,postalCode,sn,st,street,streetAddress,telephoneNumber,title,uid,homePhone,pager,mobile,userCertificate by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read', '{8}to attrs=zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCanonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress,zimbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwardingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus,zimbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeliveryDisabled by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by dn.base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * read', ); }
$mesg = $ldap->modify( $dn, delete => {olcAccess => '{3}'}, ); $mesg = $ldap->modify( $dn, add =>{olcAccess=>"$acls[0]"}, ); $mesg = $ldap->modify( $dn, delete => {olcAccess => '{7}'}, ); $mesg = $ldap->modify( $dn, add => {olcAccess => "$acls[1]"}, ); $mesg = $ldap->modify( $dn, delete => {olcAccess => '{8}'}, ); $mesg = $ldap->modify( $dn, add =>{olcAccess=>"$acls[2]"}, ); $ldap->unbind;
Again, the ability to delete an existing acl by its ordering is invaluable. So is the ability to do inserts in the ACL tables based on the ordering number.
Here's another bit I've done to modify an existing ACL when upgrading between Zimbra versions:
my $entry=$result->entry($result->count-1); my @attrvals=$entry->get_value("olcAccess"); my $aclNumber=-1; my $attrMod="";
foreach my $attr (@attrvals) { if ($attr =~ /zimbraDomainName/) { ($aclNumber) = $attr =~ /^{(\d+)}*/; if ($attr !~ /uid=zmamavis,cn=appaccts,cn=zimbra/) { $attrMod=$attr; $attrMod =~ s/by * none/by dn.base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * none/; } } }
if ($aclNumber != -1 && $attrMod ne "") { $result = $ldap->modify( $dn, delete => {olcAccess => "{$aclNumber}"}, ); $result = $ldap->modify( $dn, add =>{olcAccess=>"$attrMod"}, ); }
--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
On Mar 20, 2012, at 5:18 AM, btb wrote:
On 2012.03.19 14.39, Chris Hiestand wrote:
Editing via an ldap client is easy if you're just editing an attribute here and there, but because of the interacting nature of ACLs and schema elements, poor readability (no newlines) makes editing via an ldap client more difficult (a gui with smart sorting and syntax highlighting could make it better).
i use newlines with apache directory studio just fine:
If I try to add newlines to an existing ACL (say if you were to press "OK" in your screenshot) the ldap server may delete it from the list. At least on my system, an ACL with newlines in Apache Directory Studio, often gets deleted from cn=config in openldap 2.4.30. Apache Directory Studio (ADS) will base64 encode a multiline olcAccess. I suspect this isn't supported by Openldap, and it doesn't work consistently. To reproduce this add a couple entries with newlines and then try to edit one of them. In my case, both get deleted when I edit one of them (after ADS sends a modify, replace). The rest of my (single-line) ACLs remain un-deleted.
On Mar 20, 2012, at 3:53 AM, Howard Chu wrote:
On the other hand, we should certainly provide a slapdelete tool for removing things while slapd is offline. If you have screwed up your configuration so badly that you need to delete something from it, you might as well restart the server anyway.
slapdelete would be a fine compromise since I will not be deleting olc entries often. IMO, this is one issue that should be addressed before slapd.conf support is dropped. A practical benefit of slapdelete is getting users to stop manually deleting entries from slapd.d, which seems to be a common (mal)practice.
On Wed, Mar 21, 2012 at 8:39 PM, Chris Hiestand chiestand@salk.edu wrote:
slapdelete would be a fine compromise since I will not be deleting olc entries often. IMO, this is one issue that should be addressed before slapd.conf support is dropped. A practical benefit of slapdelete is getting users to stop manually deleting entries from slapd.d, which seems to be a common (mal)practice.
What is the correct way to delete a database from olc?
On Mar 21, 2012, at 19.22, Chris Hiestand wrote:
On Mar 20, 2012, at 5:18 AM, btb wrote:
On 2012.03.19 14.39, Chris Hiestand wrote:
Editing via an ldap client is easy if you're just editing an attribute here and there, but because of the interacting nature of ACLs and schema elements, poor readability (no newlines) makes editing via an ldap client more difficult (a gui with smart sorting and syntax highlighting could make it better).
i use newlines with apache directory studio just fine:
If I try to add newlines to an existing ACL (say if you were to press "OK" in your screenshot) the ldap server may delete it from the list. At least on my system, an ACL with newlines in Apache Directory Studio, often gets deleted from cn=config in openldap 2.4.30. Apache Directory Studio (ADS) will base64 encode a multiline olcAccess. I suspect this isn't supported by Openldap, and it doesn't work consistently. To reproduce this add a couple entries with newlines and then try to edit one of them. In my case, both get deleted when I edit one of them (after ADS sends a modify, replace). The rest of my (single-line) ACLs remain un-deleted.
hmm, not sure why it isn't working for you. i've heavily modified all of my acls at one point or another, all of which are multiline, and have not had any issues. data that needs to be base64'd [for whatever reason] is done so consistently [acls or otherwise] and is appropriately represented by the client, and modifications/etc are handled just fine.
have you adjusted apache directory studio to use the text editor rather than the in place editor? this thread discusses that in more detail:
http://www.openldap.org/lists/openldap-technical/201009/msg00103.html
-ben
On Mar 21, 2012, at 5:59 PM, David Arroyo wrote:
What is the correct way to delete a database from olc?
I get the feeling it is frowned upon, but I think you could: 1. "slapcat -s 'cn=config'" > config.ldif 2. edit config.ldif 3. delete or move slapd.d/* 4. slapadd -n0 -F /path/to/slapd.d -l config.ldif
note: ensure slapd.d ends up with appropriate ownership/permissions.
Please correct me if I'm wrong.
-Chris
On Mar 21, 2012, at 22.00, Chris Hiestand wrote:
On Mar 21, 2012, at 5:59 PM, David Arroyo wrote:
What is the correct way to delete a database from olc?
I get the feeling it is frowned upon, but I think you could:
- "slapcat -s 'cn=config'" > config.ldif
- edit config.ldif
- delete or move slapd.d/*
- slapadd -n0 -F /path/to/slapd.d -l config.ldif
note: ensure slapd.d ends up with appropriate ownership/permissions.
Please correct me if I'm wrong.
not frowned upon at all, but i'd amend that process slightly:
1. stop slapd 2. slapcat -b 'cn=config' -l config.ldif 3. mv slapd.d slapd.d.bak 4. mkdir slapd.d 5. edit ldif as desired 6. slapadd -n 0 -F slapd.d/ -l config.ldif 7. slaptest -F slapd.d/ 8. adjust ownership/permissions as appropriate for slapd.d/ 9. start slapd
the order of a few of the steps could vary slightly depending on personal preference, and technically, slapd doesn't necessarily have to be stopped so early on, but for the sake of those to which this topic applies, it keeps things simple.
-ben
On Wed, 21 Mar 2012 22:32:33 -0400, btb@bitrate.net wrote:
i'd amend that process slightly:
Not quite there yet...
Make a habit of always running the slap tools as the user & group slapd runs as, so you'll never screw up file ownerships for slapd. I.e. slapd -u ldap vs su ldap -c 'slapcat'.
- stop slapd
1.5. su ldap Might as well do umask 0077 while you are at it.
- slapcat -b 'cn=config' -l config.ldif
- mv slapd.d slapd.d.bak
- mkdir slapd.d
- edit ldif as desired
- slapadd -n 0 -F slapd.d/ -l config.ldif
- slaptest -F slapd.d/
8. exit # from 'su'
- start slapd
I.e. slapd -u ldap -F /whatever/slapd.d/
the order of a few of the steps could vary slightly depending on personal preference, and technically, slapd doesn't necessarily have to be stopped so early on, but for the sake of those to which this topic applies, it keeps things simple.
On 22/3/2012 3:47 πμ, btb@bitrate.net wrote:
hmm, not sure why it isn't working for you. i've heavily modified all of my acls at one point or another, all of which are multiline, and have not had any issues. data that needs to be base64'd [for whatever reason] is done so consistently [acls or otherwise] and is appropriately represented by the client, and modifications/etc are handled just fine.
have you adjusted apache directory studio to use the text editor rather than the in place editor? this thread discusses that in more detail:
http://www.openldap.org/lists/openldap-technical/201009/msg00103.html
With Apache Directory Studio do you get ACL listing in correct order?
Cos with JXPlorer (as with standard tools) I see string-based and not number-based ordering, for example:
olcAcces: {0}... olcAcces: {100}... olcAcces: {101}... olcAcces: {102}... olcAcces: {103}... olcAcces: {104}... olcAcces: {105}... olcAcces: {106}... olcAcces: {107}... olcAcces: {108}... olcAcces: {109}... olcAcces: {10}... olcAcces: {11}... olcAcces: {12}... olcAcces: {13}... olcAcces: {14}... olcAcces: {15}... olcAcces: {16}... olcAcces: {17}... olcAcces: {18}... olcAcces: {19}... olcAcces: {1}... olcAcces: {20}... ...
Nick
On 22/3/2012 3:47 πμ, btb@bitrate.net wrote:
hmm, not sure why it isn't working for you. i've heavily modified all of my acls at one point or another, all of which are multiline, and have not had any issues.
Hi again,
Please tell me: How do you enter newlines in Apache Dir Studio? You simply type \n or you enter a particular key combination?
Also, which ADS version are you using?
Thanks, Nick
On 2012.03.22 07.45, Nick Milas wrote:
Please tell me: How do you enter newlines in Apache Dir Studio? You simply type \n or you enter a particular key combination?
i press the enter key on my keyboard
Also, which ADS version are you using?
currently, 2.0.0.v20120224. this behavior hasn't changed in as long as i've used it, going back to at least 1.5.0
-ben
On 22/3/2012 2:20 μμ, btb wrote:
i press the enter key on my keyboard
Thanks,
Interestingly, I found that the same is also possible with JXPlorer.
ACLs can be formatted like that and they remain formated. They also function without problems.
Unfortunately, normal listing (all values together), does not show them formatted; I must edit each one separately to view it formatted.
Nick
Le 3/22/12 2:56 PM, Nick Milas a écrit :
On 22/3/2012 2:20 μμ, btb wrote:
i press the enter key on my keyboard
Thanks,
Interestingly, I found that the same is also possible with JXPlorer.
ACLs can be formatted like that and they remain formated. They also function without problems.
Unfortunately, normal listing (all values together), does not show them formatted; I must edit each one separately to view it formatted.
Nick
Guys,
if you have questions about how the Apache Directory Studio is working, or suggestion on how to improve its editor, it would be way better to do it on the Studio mailing list. I'm not pointing any finger on you, I'm just interested, as a member of the Studio team, to get some feedback and suggestion !
Thanks !
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb@bitrate.net Sent: Wednesday, March 21, 2012 10:33 PM To: openldap-technical@openldap.org Subject: Re: Concerns with OLC (cn=config) for editing schema, ACLs, and deleting entries
not frowned upon at all, but i'd amend that process slightly:
1. stop slapd 2. slapcat -b 'cn=config' -l config.ldif 3. mv slapd.d slapd.d.bak 4. mkdir slapd.d 5. edit ldif as desired 6. slapadd -n 0 -F slapd.d/ -l config.ldif 7. slaptest -F slapd.d/ 8. adjust ownership/permissions as appropriate for slapd.d/ 9. start slapd
---- You can avoid those ownership/permissions problems if you just do "sudo -u <ldap user> slapadd whatever"
- Aaron
Nick Milas wrote:
On 22/3/2012 2:20 μμ, btb wrote:
i press the enter key on my keyboard
Interestingly, I found that the same is also possible with JXPlorer.
ACLs can be formatted like that and they remain formated. They also function without problems.
Unfortunately, normal listing (all values together), does not show them formatted; I must edit each one separately to view it formatted.
For the upcoming release I've registered possibly multi-line olc* attribute types with web2ldap's plugin class MultilineText and I could add line breaks manually. (This plugin class is also used for XML data found in config of other directory server products, etc.)
But I wonder whether this is guaranteed to work since slapd rips out line breaks from the values imported from slapd.conf during automatic config conversion. It preserves multiple space chars formerly used for indentation though.
So I'd be interested in hearing one of the core developers confirm that line breaks in those attribute values will always be preserved when added via LDAP.
The attribute types in question all have Directory String syntax. But glancing at the RFC the syntax Directory String allows CR and LF.
Ciao, Michael.
Michael Ströder wrote:
Nick Milas wrote:
On 22/3/2012 2:20 μμ, btb wrote:
i press the enter key on my keyboard
Interestingly, I found that the same is also possible with JXPlorer.
ACLs can be formatted like that and they remain formated. They also function without problems.
Unfortunately, normal listing (all values together), does not show them formatted; I must edit each one separately to view it formatted.
For the upcoming release I've registered possibly multi-line olc* attribute types with web2ldap's plugin class MultilineText and I could add line breaks manually. (This plugin class is also used for XML data found in config of other directory server products, etc.)
But I wonder whether this is guaranteed to work since slapd rips out line breaks from the values imported from slapd.conf during automatic config conversion. It preserves multiple space chars formerly used for indentation though.
So I'd be interested in hearing one of the core developers confirm that line breaks in those attribute values will always be preserved when added via LDAP.
The attribute types in question all have Directory String syntax. But glancing at the RFC the syntax Directory String allows CR and LF.
OpenLDAP stores attribute values verbatim. It always has and always will. You shouldn't even need to ask this question.
Additional white space introduced when displaying as LDIF (e.g. for line-wrapping) is strictly an LDIF concern; it is not part of the actual attribute values.
Howard Chu wrote:
Michael Ströder wrote:
So I'd be interested in hearing one of the core developers confirm that line breaks in those attribute values will always be preserved when added via LDAP.
The attribute types in question all have Directory String syntax. But glancing at the RFC the syntax Directory String allows CR and LF.
OpenLDAP stores attribute values verbatim. It always has and always will.
Thanks for confirming that.
You shouldn't even need to ask this question.
As said the automatic conversion hunks out the line breaks found in in the original slapd.conf and many attributes in back-config gets extra checking anyway. So the question whether some attribute values might get stored sanitized is not that false.
I think you should appreciate client developers clarifying possible interop issues in advance. So there's nothing justifying your arrogant attitude.
Additional white space introduced when displaying as LDIF (e.g. for line-wrapping) is strictly an LDIF concern; it is not part of the actual attribute values.
I already know that very well. This was not the point here.
Ciao, Michael.
On Tuesday, 20 March 2012 12:53:08 Howard Chu wrote:
The purpose of cn=config is to support configuration changes on a server without causing any service outage. Supporting Deletes in cn=config is fundamentally opposed to this goal. E.g., deleting an olcDatabase entry cannot be seen as anything other than a service outage - you were serving a database a second ago, now it's gone.
On a server serving multiple databases, removing one of the databases is not necessarily a service outage. I would prefer (when I can clean up a legacy database, once the last of the legacy software that uses it is migrated) not to have outages on the other 3 databases in use.
Regards, Buchan
Buchan Milne wrote:
On Tuesday, 20 March 2012 12:53:08 Howard Chu wrote:
The purpose of cn=config is to support configuration changes on a server without causing any service outage. Supporting Deletes in cn=config is fundamentally opposed to this goal. E.g., deleting an olcDatabase entry cannot be seen as anything other than a service outage - you were serving a database a second ago, now it's gone.
On a server serving multiple databases, removing one of the databases is not necessarily a service outage.
I wholeheartly agree.
Even when you only have one database removing an overlay attached to that database should be possible.
Ciao, Michael.
Howard Chu wrote:
The OpenLDAP Project is only concerned with implementing the low level functionality. If you want a GUI, ask the Apache Directory Studio folks.
But back-config's schema has a very high influence.
The question is why it's so much easier for GUI clients to directly support tweaking cn=config or similar configuration entries of other directory servers?
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
So I'd be interested in hearing one of the core developers confirm that line breaks in those attribute values will always be preserved when added via LDAP.
The attribute types in question all have Directory String syntax. But glancing at the RFC the syntax Directory String allows CR and LF.
OpenLDAP stores attribute values verbatim. It always has and always will.
Thanks for confirming that.
You shouldn't even need to ask this question.
As said the automatic conversion hunks out the line breaks found in in the original slapd.conf and many attributes in back-config gets extra checking anyway. So the question whether some attribute values might get stored sanitized is not that false.
Your question is pretty imprecise, then. Values stored due to conversion from slapd.conf are not treated exactly the same as values stored by LDAP operations. Everything read from slapd.conf has had excess whitespace stripped (as documented in slapd.conf(5)) when read; that is the normal behavior of the slapd.conf parser and has been since the dawn of time.
I think you should appreciate client developers clarifying possible interop issues in advance. So there's nothing justifying your arrogant attitude.
Michael, you are not a newbie; quit acting like one. You've been associated with this Project for at least the past 12 years. There is nothing arrogant in telling you you should know better by now. *You* *should* know better by now.
Buchan Milne wrote:
On Tuesday, 20 March 2012 12:53:08 Howard Chu wrote:
The purpose of cn=config is to support configuration changes on a server without causing any service outage. Supporting Deletes in cn=config is fundamentally opposed to this goal. E.g., deleting an olcDatabase entry cannot be seen as anything other than a service outage - you were serving a database a second ago, now it's gone.
On a server serving multiple databases, removing one of the databases is not necessarily a service outage. I would prefer (when I can clean up a legacy database, once the last of the legacy software that uses it is migrated) not to have outages on the other 3 databases in use.
And how will you know definitively that all of your legacy clients have been turned off?
Anyway, you can accomplish nearly the same, without deleting the database object, simply by modifying the olcDbDirectory to point to an empty directory. The old pathname will be closed, the new one opened, and there will be no data to serve.
Michael Ströder wrote:
Howard Chu wrote:
The OpenLDAP Project is only concerned with implementing the low level functionality. If you want a GUI, ask the Apache Directory Studio folks.
But back-config's schema has a very high influence.
The question is why it's so much easier for GUI clients to directly support tweaking cn=config or similar configuration entries of other directory servers?
Is it easier? File ITSs on the obvious problem areas then. AFAIK all other directory servers with LDAP-enabled configuration still intend for you to use their custom client for configuration.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
So I'd be interested in hearing one of the core developers confirm that line breaks in those attribute values will always be preserved when added via LDAP.
The attribute types in question all have Directory String syntax. But glancing at the RFC the syntax Directory String allows CR and LF.
OpenLDAP stores attribute values verbatim. It always has and always will.
Thanks for confirming that.
You shouldn't even need to ask this question.
As said the automatic conversion hunks out the line breaks found in in the original slapd.conf and many attributes in back-config gets extra checking anyway. So the question whether some attribute values might get stored sanitized is not that false.
Your question is pretty imprecise, then.
I can't see what's imprecise here.
Values stored due to conversion from slapd.conf are not treated exactly the same as values stored by LDAP operations. Everything read from slapd.conf has had excess whitespace stripped (as documented in slapd.conf(5)) when read; that is the normal behavior of the slapd.conf parser and has been since the dawn of time.
So why does it differ? You could also preserve line breaks during conversion and strip excessive white spaces before using the ACLs within slapd. That's a design decision and so my question is very valid. I'm not judging the decision as right or wrong. I'm just trying to clarify the behaviour and asking for confirmation that it will remain like this in the future.
I think you should appreciate client developers clarifying possible interop issues in advance. So there's nothing justifying your arrogant attitude.
Michael, you are not a newbie; quit acting like one. You've been associated with this Project for at least the past 12 years. There is nothing arrogant in telling you you should know better by now. *You* *should* know better by now.
You're missing the point. I'm thinking one step *ahead* you. IMO there's nothing wrong with bringing to your attention that people *now* assume line breaks to be preserved. Especially since you're not working in the GUI camp at all.
There could be valid reasons in the future to strip white spaces in LDAP requests in a normalization step. So asking for the confirmation that this behaviour will remain in the future is not imprecise or false at all. Especially when looking at 12 years history where sometimes things changed (for valid reasons).
Ciao, Michael.
P.S.: I'm not associated with the OpenLDAP project.
Michael Ströder wrote:
You're missing the point. I'm thinking one step *ahead* you. IMO there's nothing wrong with bringing to your attention that people *now* assume line breaks to be preserved. Especially since you're not working in the GUI camp at all.
There could be valid reasons in the future to strip white spaces in LDAP requests in a normalization step. So asking for the confirmation that this behaviour will remain in the future is not imprecise or false at all. Especially when looking at 12 years history where sometimes things changed (for valid reasons).
In that case, since we cannot make any predictions about the future, the smart thing to do is to make no assumptions whatsoever about what the server will preserve or strip. Treat all values as unformatted data and reformat it in your client whenever presenting to a user.
Howard Chu wrote:
Michael Ströder wrote:
There could be valid reasons in the future to strip white spaces in LDAP requests in a normalization step. So asking for the confirmation that this behaviour will remain in the future is not imprecise or false at all. Especially when looking at 12 years history where sometimes things changed (for valid reasons).
In that case, since we cannot make any predictions about the future, the smart thing to do is to make no assumptions whatsoever about what the server will preserve or strip. Treat all values as unformatted data and reformat it in your client whenever presenting to a user.
Did you read the thread?
Ciao, Michael.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
The OpenLDAP Project is only concerned with implementing the low level functionality. If you want a GUI, ask the Apache Directory Studio folks.
But back-config's schema has a very high influence.
The question is why it's so much easier for GUI clients to directly support tweaking cn=config or similar configuration entries of other directory servers?
Is it easier?
Yes, I think so.
File ITSs on the obvious problem areas then.
Problematic are configuration attributes which might be multi-valued and comma-/space-separated for specifying multiple values at the same time. IIRC this is the case for olcAllow.
Especially the different variants for olcLogLevel are cumbersome at least based on how I understand slapd-config(5). The flexibility does not add any value for the user but makes programming a UI rather difficult. Especially since a generic UI has to preserve the attribute values stored in the entry but represent it in a user-friendly easily editable way guiding the user to do the right thing without restricting what would be valid.
AFAIK all other directory servers with LDAP-enabled configuration still intend for you to use their custom client for configuration.
What the other vendors intend is not relevant for my comparison. My view on the other LDAP server products is solely via web2ldap.
For other LDAP servers I can easily handle a lot of dynamic configuration just by adding some simple LDIF and HTML templates, sometimes a plugin class based on base classes already in web2ldap, e.g. for static or dynamic select lists etc.
Ciao, Michael.
On 22/3/2012 3:56 μμ, Nick Milas wrote:
On 22/3/2012 2:20 μμ, btb wrote:
i press the enter key on my keyboard
Thanks,
Interestingly, I found that the same is also possible with JXPlorer.
ACLs can be formatted like that and they remain formated. They also function without problems.
Hi,
I am returning to an older thread, regarding the formatting of ACLs using Carriage Return (CRs) and spaces.
I have just realized that if we format (using CRs) ACLs stored as olcAccess attr values, then they are exported/stored as ldif in base64 encoded format (by all clients I tried).
Here is an example:
olcAccess: {25}to dn.subtree="ou=dns1,dc=noa,dc=gr" by group/groupOfNames/member.exact="cn=techadmins,ou=groups,dc=noa,dc=gr" write by group/groupOfNames/member.exact="cn=spaceadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=astroadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=geinadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=meteoadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=nestoradmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=guestadmins,ou=groups,dc=noa,dc=gr" read by dn.base="uid=dnsauthusr,ou=system,dc=noa,dc=gr" read olcAccess:: ezI2fXRvIGRuLnN1YnRyZWU9Im91PWtyYmNvbnRhaW5lcixkYz1ub2EsZGM9Z3Ii ICBhdHRycz1jaGlsZHJlbixlbnRyeQogICBieSBkbi5iYXNlPSJ1aWQ9ZG5zYXV0aHVzcixvdT1 zeXN0ZW0sZGM9bm9hLGRjPWdyIiBub25lICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL21lbW Jlci5leGFjdD0iY249dGVjaGFkbWlucyxvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiB3cml0ZSAgC iAgIGJ5IGdyb3VwL2dyb3VwT2ZOYW1lcy9tZW1iZXIuZXhhY3Q9ImNuPXNwYWNlYWRtaW5zLG91 PWdyb3VwcyxkYz1ub2EsZGM9Z3IiIHJlYWQgIAogICBieSBncm91cC9ncm91cE9mTmFtZXMvbWV tYmVyLmV4YWN0PSJjbj1hc3Ryb2FkbWlucyxvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiByZWFkIC AKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL21lbWJlci5leGFjdD0iY249Z2VpbmFkbWlucyxvd T1ncm91cHMsZGM9bm9hLGRjPWdyIiByZWFkICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL21l bWJlci5leGFjdD0iY249bWV0ZW9hZG1pbnMsb3U9Z3JvdXBzLGRjPW5vYSxkYz1nciIgcmVhZCA gCiAgIGJ5IGdyb3VwL2dyb3VwT2ZOYW1lcy9tZW1iZXIuZXhhY3Q9ImNuPW5lc3RvcmFkbWlucy xvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiByZWFkICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL 21lbWJlci5leGFjdD0iY249Z3Vlc3RhZG1pbnMsb3U9Z3JvdXBzLGRjPW5vYSxkYz1nciIgcmVh ZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1hdXRoZW50aWNhdGUsb3U9c3lzdGVtLGRjPW5vYSxkYz1 nciIgcmVhZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1sb2dpbmF1dGhiaW5kLG91PXN5c3RlbSxkYz 1ub2EsZGM9Z3IiIHJlYWQgIAogICBieSBkbi5iYXNlPSJ1aWQ9a2RjLXNlcnZpY2Usb3U9c3lzd GVtLGRjPW5vYSxkYz1nciIgcmVhZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1rcmItYWRtLXNlcnZp Y2Usb3U9c3lzdGVtLGRjPW5vYSxkYz1nciIgd3JpdGUgIAogICBieSAqICswIGJyZWFr
The former, ACL #25, was not formatted and is exported OK. However, the latter should be #26 and the actual value is as follows (copied from the GUI):
{26}to dn.subtree="ou=krbcontainer,dc=noa,dc=gr" attrs=children,entry by dn.base="uid=dnsauthusr,ou=system,dc=noa,dc=gr" none by group/groupOfNames/member.exact="cn=techadmins,ou=groups,dc=noa,dc=gr" write by group/groupOfNames/member.exact="cn=spaceadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=astroadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=geinadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=meteoadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=nestoradmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=guestadmins,ou=groups,dc=noa,dc=gr" read by dn.base="uid=authenticate,ou=system,dc=noa,dc=gr" read by dn.base="uid=loginauthbind,ou=system,dc=noa,dc=gr" read by dn.base="uid=kdc-service,ou=system,dc=noa,dc=gr" read by dn.base="uid=krb-adm-service,ou=system,dc=noa,dc=gr" write by * +0 break
This actually is causing a serious problem (I would even call it a "*hell situation*"), because we can no more export/view our ACLs as ldif in a legible form. Moreover, we cannot edit this exported ldif and import it back to cover several editing needs.
Questions: 1. Is there a way we can export ldif, while automatically removing such formatting so that the ldif content is legible/editable as normal text? 2. Is there a way (some command) to automatically remove all CRs wherever they exist in olcAccess values, to avoid editing one by one (in order to remove all CRs)?
[Note: I have indications (though I have not tested sufficiently) that Apache Directory Studio may have problems in handling correctly ACL modifications when some of the olcAccess values are formatted as above. In one case I totally lost inexplicably all ACLs numbered higher than the olcAccess value I was editing. Just a word of caution, although I don't have enough test data at this time.]
Please advise!
Thanks, Nick
Nick Milas wrote:
I am returning to an older thread, regarding the formatting of ACLs using Carriage Return (CRs) and spaces.
I have just realized that if we format (using CRs) ACLs stored as olcAccess attr values, then they are exported/stored as ldif in base64 encoded format (by all clients I tried).
Yes, because of declaration of SAFE-CHAR in RFC 2849. I also vaguely remember discussions about XML in LDIF (on ietf-ldapext mailing list?).
This actually is causing a serious problem (I would even call it a "*hell situation*"), because we can no more export/view our ACLs as ldif in a legible form. Moreover, we cannot edit this exported ldif and import it back to cover several editing needs.
I think now it's the time to start looking at LDIF processing module in your favourite scripting language. I cannot imagine any other sane way.
BTW: I'd be curious to hear from people who are using my web2ldap to edit entries in back-config. Based on the discussion in this tread these attribute types are pre-registered as multi-line text in recent releases:
syntax_registry.registerAttrType( OlcMultilineText.oid,[ '1.3.6.1.4.1.4203.1.12.2.3.0.1', # olcAccess '1.3.6.1.4.1.4203.1.12.2.3.0.6', # olcAuthIDRewrite '1.3.6.1.4.1.4203.1.12.2.3.0.8', # olcAuthzRegexp '1.3.6.1.4.1.4203.1.12.2.3.2.0.11', # olcSyncrepl ] )
Ciao, Michael.
On 19/5/2012 5:35 μμ, Michael Ströder wrote:
I think now it's the time to start looking at LDIF processing module in your favourite scripting language. I cannot imagine any other sane way.
I guess you are right. In any case, I prefer to have the primitive data (I mean olcAccess attr values) in text rather in base64 form (when exported), so I think I'll have no other option than manually deleting CRs from each and every ACL (using a GUI).
Quite unfortunate...
Additionally, we are always waiting for the implementation of one (or, even better, multiple) olcAccess comments per olcAccess value (numbered identically as olcAccess values, so they can always be synced/coupled with them), i.e.:
olcAccess: olcAccess;x-comment:
or
description;x-olcAccess:
as discussed e.g. here: http://www.openldap.org/lists/openldap-technical/201107/msg00036.html which will allow a much greater readability and flexibility in external scripting (because in comments we can use custom identifiers etc).
Is there any progress towards this? Any ITS filed about it (if not, someone should file one)? Any roadmap?
I also vaguely remember discussions about XML in LDIF (on ietf-ldapext mailing list?).
Any additional info regarding this spec, its validity and adoption would be interesting. Can anyone please provide more details?
Please advise.
Regards, Nick
Nick Milas wrote:
On 19/5/2012 5:35 μμ, Michael Ströder wrote:
mailing list?).
Any additional info regarding this spec, its validity and adoption would be interesting. Can anyone please provide more details?
Searching xml ldif and ietf-ldapext with Google and a couple of clicks lead to:
http://tools.ietf.org/html/draft-sciberras-xed-eldif-04
Not sure whether there are enough implementations to call it a standard though.
Ciao, Michael.
Nick Milas wrote:
On 22/3/2012 3:56 μμ, Nick Milas wrote:
On 22/3/2012 2:20 μμ, btb wrote:
i press the enter key on my keyboard
Thanks,
Interestingly, I found that the same is also possible with JXPlorer.
ACLs can be formatted like that and they remain formated. They also function without problems.
Hi,
I am returning to an older thread, regarding the formatting of ACLs using Carriage Return (CRs) and spaces.
I have just realized that if we format (using CRs) ACLs stored as olcAccess attr values, then they are exported/stored as ldif in base64 encoded format (by all clients I tried).
Here is an example:
olcAccess: {25}to dn.subtree="ou=dns1,dc=noa,dc=gr" by group/groupOfNames/member.exact="cn=techadmins,ou=groups,dc=noa,dc=gr " write by group/groupOfNames/member.exact="cn=spaceadmins,ou=groups,dc=noa,dc=g r" read by group/groupOfNames/member.exact="cn=astroadmins,ou=groups,dc=noa,dc=g r" read by group/groupOfNames/member.exact="cn=geinadmins,ou=groups,dc=noa,dc=gr " read by group/groupOfNames/member.exact="cn=meteoadmins,ou=groups,dc=noa,dc=g r" read by group/groupOfNames/member.exact="cn=nestoradmins,ou=groups,dc=noa,dc= gr" read by group/groupOfNames/member.exact="cn=guestadmins,ou=groups,dc=noa,dc=g r" read by dn.base="uid=dnsauthusr,ou=system,dc=noa,dc=gr" read olcAccess:: ezI2fXRvIGRuLnN1YnRyZWU9Im91PWtyYmNvbnRhaW5lcixkYz1ub2EsZGM9Z3Ii
ICBhdHRycz1jaGlsZHJlbixlbnRyeQogICBieSBkbi5iYXNlPSJ1aWQ9ZG5zYXV0aHVz cixvdT1 zeXN0ZW0sZGM9bm9hLGRjPWdyIiBub25lICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWV zL21lbW Jlci5leGFjdD0iY249dGVjaGFkbWlucyxvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiB3cm l0ZSAgC iAgIGJ5IGdyb3VwL2dyb3VwT2ZOYW1lcy9tZW1iZXIuZXhhY3Q9ImNuPXNwYWNlYWRta W5zLG91 PWdyb3VwcyxkYz1ub2EsZGM9Z3IiIHJlYWQgIAogICBieSBncm91cC9ncm91cE9mTmFt ZXMvbWV tYmVyLmV4YWN0PSJjbj1hc3Ryb2FkbWlucyxvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiB yZWFkIC AKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL21lbWJlci5leGFjdD0iY249Z2VpbmFkbW lucyxvd T1ncm91cHMsZGM9bm9hLGRjPWdyIiByZWFkICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hb WVzL21l bWJlci5leGFjdD0iY249bWV0ZW9hZG1pbnMsb3U9Z3JvdXBzLGRjPW5vYSxkYz1nciIg cmVhZCA gCiAgIGJ5IGdyb3VwL2dyb3VwT2ZOYW1lcy9tZW1iZXIuZXhhY3Q9ImNuPW5lc3RvcmF kbWlucy xvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiByZWFkICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk 5hbWVzL 21lbWJlci5leGFjdD0iY249Z3Vlc3RhZG1pbnMsb3U9Z3JvdXBzLGRjPW5vYSxkYz1nc iIgcmVh ZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1hdXRoZW50aWNhdGUsb3U9c3lzdGVtLGRjPW5v YSxkYz1 nciIgcmVhZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1sb2dpbmF1dGhiaW5kLG91PXN5c3R lbSxkYz 1ub2EsZGM9Z3IiIHJlYWQgIAogICBieSBkbi5iYXNlPSJ1aWQ9a2RjLXNlcnZpY2Usb3 U9c3lzd GVtLGRjPW5vYSxkYz1nciIgcmVhZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1rcmItYWRtL XNlcnZp Y2Usb3U9c3lzdGVtLGRjPW5vYSxkYz1nciIgd3JpdGUgIAogICBieSAqICswIGJyZWFr
The former, ACL #25, was not formatted and is exported OK. However, the latter should be #26 and the actual value is as follows (copied from the GUI):
{26}to dn.subtree="ou=krbcontainer,dc=noa,dc=gr" attrs=children,entry by dn.base="uid=dnsauthusr,ou=system,dc=noa,dc=gr" none by group/groupOfNames/member.exact="cn=techadmins,ou=groups,dc=noa,dc=gr " write by group/groupOfNames/member.exact="cn=spaceadmins,ou=groups,dc=noa,dc=g r" read by group/groupOfNames/member.exact="cn=astroadmins,ou=groups,dc=noa,dc=g r" read by group/groupOfNames/member.exact="cn=geinadmins,ou=groups,dc=noa,dc=gr " read by group/groupOfNames/member.exact="cn=meteoadmins,ou=groups,dc=noa,dc=g r" read by group/groupOfNames/member.exact="cn=nestoradmins,ou=groups,dc=noa,dc= gr" read by group/groupOfNames/member.exact="cn=guestadmins,ou=groups,dc=noa,dc=g r" read by dn.base="uid=authenticate,ou=system,dc=noa,dc=gr" read by dn.base="uid=loginauthbind,ou=system,dc=noa,dc=gr" read by dn.base="uid=kdc-service,ou=system,dc=noa,dc=gr" read by dn.base="uid=krb-adm-service,ou=system,dc=noa,dc=gr" write by * +0 break
This actually is causing a serious problem (I would even call it a "*hell situation*"), because we can no more export/view our ACLs as ldif in a legible form. Moreover, we cannot edit this exported ldif and import it back to cover several editing needs.
I am pretty sure, that after you have added the '\n' you have broken the ldiff format. You may try '\n '.
Questions:
- Is there a way we can export ldif, while automatically removing
such formatting so that the ldif content is legible/editable as normal text?
Best is you don't add additional characters. Here is a script to fix the output. It is based on what and how you have posted to this list. I have disabled "line breaks" in my mailer.
# t=$(echo "ezI2fXRvIGRuLnN1YnRyZWU9Im91PWtyYmNvbnRhaW5lcixkYz1ub2EsZGM9Z3Ii ICBhdHRycz1jaGlsZHJlbixlbnRyeQogICBieSBkbi5iYXNlPSJ1aWQ9ZG5zYXV0aHVzcixvdT1 zeXN0ZW0sZGM9bm9hLGRjPWdyIiBub25lICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL21lbW Jlci5leGFjdD0iY249dGVjaGFkbWlucyxvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiB3cml0ZSAgC iAgIGJ5IGdyb3VwL2dyb3VwT2ZOYW1lcy9tZW1iZXIuZXhhY3Q9ImNuPXNwYWNlYWRtaW5zLG91 PWdyb3VwcyxkYz1ub2EsZGM9Z3IiIHJlYWQgIAogICBieSBncm91cC9ncm91cE9mTmFtZXMvbWV tYmVyLmV4YWN0PSJjbj1hc3Ryb2FkbWlucyxvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiByZWFkIC AKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL21lbWJlci5leGFjdD0iY249Z2VpbmFkbWlucyxvd T1ncm91cHMsZGM9bm9hLGRjPWdyIiByZWFkICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL21l bWJlci5leGFjdD0iY249bWV0ZW9hZG1pbnMsb3U9Z3JvdXBzLGRjPW5vYSxkYz1nciIgcmVhZCA gCiAgIGJ5IGdyb3VwL2dyb3VwT2ZOYW1lcy9tZW1iZXIuZXhhY3Q9ImNuPW5lc3RvcmFkbWlucy xvdT1ncm91cHMsZGM9bm9hLGRjPWdyIiByZWFkICAKICAgYnkgZ3JvdXAvZ3JvdXBPZk5hbWVzL 21lbWJlci5leGFjdD0iY249Z3Vlc3RhZG1pbnMsb3U9Z3JvdXBzLGRjPW5vYSxkYz1nciIgcmVh ZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1hdXRoZW50aWNhdGUsb3U9c3lzdGVtLGRjPW5vYSxkYz1 nciIgcmVhZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1sb2dpbmF1dGhiaW5kLG91PXN5c3RlbSxkYz 1ub2EsZGM9Z3IiIHJlYWQgIAogICBieSBkbi5iYXNlPSJ1aWQ9a2RjLXNlcnZpY2Usb3U9c3lzd GVtLGRjPW5vYSxkYz1nciIgcmVhZCAgCiAgIGJ5IGRuLmJhc2U9InVpZD1rcmItYWRtLXNlcnZp Y2Usb3U9c3lzdGVtLGRjPW5vYSxkYz1nciIgd3JpdGUgIAogICBieSAqICswIGJyZWFr" |fmt_olcAccess |sed -ne 's/ //g;p'|base64 -d); echo "$t"|fmt_olcAccess
{26}to dn.subtree="ou=krbcontainer,dc=noa,dc=gr" attrs=children,entry by dn.base="uid=dnsauthusr,ou=system,dc=noa,dc=gr" none by group/groupOfNames/member.exact="cn=techadmins,ou=groups,dc=noa,dc=gr" write by group/groupOfNames/member.exact="cn=spaceadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=astroadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=geinadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=meteoadmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=nestoradmins,ou=groups,dc=noa,dc=gr" read by group/groupOfNames/member.exact="cn=guestadmins,ou=groups,dc=noa,dc=gr" read by dn.base="uid=authenticate,ou=system,dc=noa,dc=gr" read by dn.base="uid=loginauthbind,ou=system,dc=noa,dc=gr" read by dn.base="uid=kdc-service,ou=system,dc=noa,dc=gr" read by dn.base="uid=krb-adm-service,ou=system,dc=noa,dc=gr" write by * +0 break
- Is there a way (some command) to automatically
remove all CRs wherever they exist in olcAccess values, to avoid editing one by one (in order to remove all CRs)?
[Note: I have indications (though I have not tested sufficiently) that Apache Directory Studio may have problems in handling correctly ACL modifications when some of the olcAccess values are formatted as above. In one case I totally lost inexplicably all ACLs numbered higher than the olcAccess value I was editing. Just a word of caution, although I don't have enough test data at this time.]
Don't use tools for ACL-editing that don't work as expected. I use my self written sed-filter to beautify olcAccess lines.
# cat $(which fmt_olcAccess)
#!/bin/sed -rf # Author: Harry Jede # produce human readable but still machine parseable # olcAccess lines and removes the ordering numbers in {} # because humans don't need them, really.
# disable next line, if you like the numbering s/^(olcAccess: ){[[:digit:]]+}(.*$)/\1\2/ $!{H;d} # add more spaces after the second "\n" to have a greater indend # TWO spaces is the minimum for correct ldif format ${H;g;s/\n //g;s/[[:space:]]+by /\n by /g}
This script does not delete any additional characters.
Please advise!
Thanks, Nick
harry.jede@arcor.de wrote:
Nick Milas wrote:
This actually is causing a serious problem (I would even call it a "*hell situation*"), because we can no more export/view our ACLs as ldif in a legible form. Moreover, we cannot edit this exported ldif and import it back to cover several editing needs.
I am pretty sure, that after you have added the '\n' you have broken the ldiff format.
Harry, as said in this discussion thread: 1. LDAP syntax DirectoryString may contain CR and LF. 2. RFC 2849 defines SAFE-CHAR which does not contain CR and LF
=> a DirectoryString attribute value containing CR or LF has to be base64-encoded when generating LDIF.
There's nothing wrong with that.
You may try '\n '.
Adding \n is a work-around when working with some shell commands. This is not relevant here.
Ciao, Michael.
Michael Ströder wrote:
harry.jede@arcor.de wrote:
Nick Milas wrote:
This actually is causing a serious problem (I would even call it a "*hell situation*"), because we can no more export/view our ACLs as ldif in a legible form. Moreover, we cannot edit this exported ldif and import it back to cover several editing needs.
I am pretty sure, that after you have added the '\n' you have broken the ldiff format.
Harry, as said in this discussion thread:
- LDAP syntax DirectoryString may contain CR and LF.
- RFC 2849 defines SAFE-CHAR which does not contain CR and LF
=> a DirectoryString attribute value containing CR or LF has to be base64-encoded when generating LDIF.
There's nothing wrong with that.
You describe the internal way how a LF in a DirectoryString is handled. I believe that this is all right and that my previous statement "broken ldif" is not really true. But it touches Nicks problem he called "hell situation".
You may try '\n '.
Adding \n is a work-around when working with some shell commands. This is not relevant here.
Indeed it is. If one adds a LF to a DirectoryString like olcAccess via a GUI-Tool one gets beautified olcAccess fields in this GUI-Tool. Fine?
Now, one wishes to export/view/modify the olcAccess lines and get base64 encoded strings, i.e. olcAccess:: ezB9dG8gYXR0cnM9dXNlclBhc3N3b3JkLHNoYWRvd0xhc3RDaGFuZ2UKIGJ5IHNlbG Ygd3JpdGUgYnkgYW5vbnltb3VzIGF1dGgKIGJ5IGRuPSJjbj1hZG1pbixkYz1rcm9ucHJpbnosZGM 9eHgiIHdyaXRlCiBieSAqIG5vbmU=
OK, no problem. We decode it, after we removed '\n ': # echo 'ezB9dG8gYXR0cnM9dXNlclBhc3N3b3JkLHNoYWRvd0xhc3RDaGFuZ2UKIGJ5IHNlbGYgd3JpdGUgYnkgYW5vbnltb3VzIGF1dGgKIGJ5IGRuPSJjbj1hZG1pbixkYz1rcm9ucHJpbnosZGM9eHgiIHdyaXRlCiBieSAqIG5vbmU='| base64 -d {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=kronprinz,dc=xx" write by * none
So, now we have a situation, where we have produced "INVALID LDIF". The right format SHOULD look like this: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=kronprinz,dc=xx" write by * none
The difference is that we have two spaces in front of each by clause. The "first space" is part of the "line continuation". This can be directly added with ldapadd/modify.
What I called "INVALID LDIF" must be base64-encoded before sending to the server (not tested). If one miss this step, ACLs will not work as expected.
And all this trouble is only required to beautify a GUI ;-) . I think that is a wrong approach. GUI-developers should avoid to embed LF in olcAccess fields, even if it is allowed to do. I think a much better approach is to reformat olcAccess fields, so that their content could be easy copied/pasted by users.
Once again, this is readable by humans, may be copied/pasted by humans, and is still accepted from openldaps ldiff parser:
dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=kronprinz,dc=xx" write by * none olcAccess: {1}to dn.base="" by * read
Ciao, Michael.
harry.jede@arcor.de wrote:
Michael Ströder wrote:
Harry, as said in this discussion thread:
- LDAP syntax DirectoryString may contain CR and LF.
- RFC 2849 defines SAFE-CHAR which does not contain CR and LF
=> a DirectoryString attribute value containing CR or LF has to be base64-encoded when generating LDIF.
There's nothing wrong with that.
You describe the internal way how a LF in a DirectoryString is handled.
I'm not sure what you consider "internal". The LDIF exported is the interface format. You have to deal with it in some way. You either don't use CR-LF to format your ACLs to have ediable LDIF or you use LF to format your ACLs. That's what was discussed in this thread before.
Maybe what's needed is an editor for LDIF records which handles all this in case LDAP access is not possible anymore. Much work for just some emergency cases.
Please note that directly editing LDIF of back-config was strongly discouraged by the OpenLDAP developers on this list several times. I'd suggest you should re-read the whole thread in the mailing list archive before your next follow-up.
If one adds a LF to a DirectoryString like olcAccess via a GUI-Tool one gets beautified olcAccess fields in this GUI-Tool. Fine?
Now, one wishes to export/view/modify the olcAccess lines and get base64 encoded strings, i.e. olcAccess:: ezB9dG8gYXR0cnM9dXNlclBhc3N3b3JkLHNoYWRvd0xhc3RDaGFuZ2UKIGJ5IHNlbG Ygd3JpdGUgYnkgYW5vbnltb3VzIGF1dGgKIGJ5IGRuPSJjbj1hZG1pbixkYz1rcm9ucHJpbnosZGM 9eHgiIHdyaXRlCiBieSAqIG5vbmU=
OK, no problem. We decode it, after we removed '\n ':
As said: Better use a decent LDIF parser.
What I called "INVALID LDIF" must be base64-encoded before sending to the server (not tested).
What are you talking about? The on-wire-format for LDAP does not have to be base64-encoded. Please clearly distinguish LDIF from LDAP string format.
If one miss this step, ACLs will not work as expected.
Why don't you simply test it and see what's the result?
And all this trouble is only required to beautify a GUI ;-). I think that is a wrong approach. GUI-developers should avoid to embed LF in olcAccess fields, even if it is allowed to do.
You're completely missing the point: The goal was to make the ACLs more readable for the admin. The GUI just makes it possible for the admin to add the LFs and display the ACL as multiple lines. And now this has the effect that the attributes values in LDIF are base64-encoded. The admin decides whether to add LFs or not.
I think a much better approach is to reformat olcAccess fields, so that their content could be easy copied/pasted by users.
How to reformat them? That's a matter of personal taste. You would have to parse the ACL format.
Once again, this is readable by humans, may be copied/pasted by humans, and is still accepted from openldaps ldiff parser:
dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=kronprinz,dc=xx" write by * none olcAccess: {1}to dn.base="" by * read
Please add it via LDAP and display it in a LDAP client. It will be a single line which was considered to be less readable.
Ciao, Michael.
On 19/5/2012 6:56 μμ, Nick Milas wrote:
Additionally, we are always waiting for the implementation of one (or, even better, multiple) olcAccess comments per olcAccess value (numbered identically as olcAccess values, so they can always be synced/coupled with them), i.e.:
olcAccess: olcAccess;x-comment:
or
description;x-olcAccess:
as discussed e.g. here: http://www.openldap.org/lists/openldap-technical/201107/msg00036.html which will allow a much greater readability and flexibility in external scripting (because in comments we can use custom identifiers etc).
Is there any progress towards this? Any ITS filed about it (if not, someone should file one)? Any roadmap?
Anyone?
Thanks, Nick
On 19/3/2012 8:57 μμ, Quanah Gibson-Mount wrote:
Part 2: Deleting entries in cn=config
Quanah Gibson-Mount has said entry deletes are coming in 2.5, is that still the plan? The Roadmap page isn't specific.
You can optionally enable this at build time in OpenLDAP 2.4.30 for testing. As it is an experimental feature, YMMV.
Obviously you mean "*since* OpenLDAP 2.4.30".
What is the option name, please?
Thanks, Nick
--On Tuesday, May 22, 2012 3:08 PM +0300 Nick Milas nick@eurobjects.com wrote:
On 19/3/2012 8:57 μμ, Quanah Gibson-Mount wrote:
Part 2: Deleting entries in cn=config
Quanah Gibson-Mount has said entry deletes are coming in 2.5, is that still the plan? The Roadmap page isn't specific.
You can optionally enable this at build time in OpenLDAP 2.4.30 for testing. As it is an experimental feature, YMMV.
Obviously you mean "*since* OpenLDAP 2.4.30".
What is the option name, please?
-DSLAP_CONFIG_DELETE
--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
-
Aaron Bennett -
btb -
btb＠bitrate.net
-
Buchan Milne -
Chris Hiestand -
Clément OUDOT -
David Arroyo -
David Blank-Edelman -
David N. Blank-Edelman
-
Emmanuel Lécharny -
Hallvard B Furuseth -
harry.jede＠arcor.de -
Howard Chu -
Michael Ströder -
Nick Milas -
Quanah Gibson-Mount