Re: Loading LDAP schema files into cn=config
Chan Wilson wrote:
On Wed, Jun 29, 2011 at 5:26 AM, Mark Cave-Ayland
mark.cave-ayl...@siriusit.co.uk mailto:mark.cave-ayl...@siriusit.co.uk
wrote:
Hi all,
Having started to look at the changes required to migrate from a
slapd.conf setup to a cn=config setup, one of things I'm struggling with
is how to load new LDAP schemas into cn=config.
There's a certain mindset to be achieved in understanding cn=config / RTC, for
sure.
I'm happening to be building up an updated config for an N-way multi-master
setup, and having the occasion to revisit the OpenLDAP manual, the Zytrax LDAP
book/site, and the ever-useful test suites in the source, I can say there's
lots of good documentation out there... but it could always be better.
One item I can highly recommend is that once you convert to RTC format, don't
ever touch the files on disk. Oh, you can, for sure, but if you ever think
about replication, there's so many lovely ways to shoot your servers it's
crazy. Been there, learnt that.
Which is one (of many) reasons why I continue to flame people for ever
suggesting it.
Let me be clear - I've been administering Unix installations for over 25
years. I am the last person anyone needs to convince about the value of
human-readable and editable config files. In fact this was one of my principle
requirements for cn=config when it was being developed, and I stated it many
times during the early days:
http://www.openldap.org/lists/openldap-devel/200503/msg00038.html
Those of you who pipe up about this topic today without having done your
homework and read the background of this design are, to be blunt, both
ignorant and simply preaching to the choir; neither of which is ever appreciated.
The ability to do manual disaster-recovery/emergency config changes is
crucial. But you also have to understand that going this route is for
*emergencies* - it is not the way to go for routine administrative tasks.
Regarding bootstrap -- the test suites show nicely how minimal it can be --
one slapadd to create the base cn=config and olcDatabase{0}config,cn=config,
and then start up the server and do the remaining configuration, including
adding the schemas (presuming you've got them in .ldif format already.)
One
rough edge not so obviously logged is the server (as of 2.4.25) needs a
restart after adding an (hdb) database object/branch.
That is certainly not true, as test050 does this and much more.
Replication has its own
pointy edges as well along with TLS; I've spent hours chasing obscure TLS
issues due to O/S dependent behaviors.
Regarding schemas -- it's a straightforward perl 1-liner to translate from
.schema to .ldif format. Then import and edit via ldapmodify as needed.
Hope this helps,
--Chan
I've seen the guides similar to this one here:
http://blogger.ziesemer.com/__2011/01/ldap-authentication-__for-samba.html
http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html
which suggest hacking together a temporary slapd.conf file containing just
the include directives, run slaptest, and then hack the output so that it
can be loaded into cn=config using ldapadd.
Given that this is a quite a common task, is there no way of generating
the LDIF directly to be loaded into the directory, e.g.
slaptest -s /etc/ldap/schema/myschema.__schema [ -n schemanum ] -l
myschema.ldif
Or then again, is this functionality already there but I just haven't
managed to find it yet? I'd be grateful if someone could point me in the
right direction and/or give me some hints as to the best way to manage
schemas in the new regime.
Many thanks,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063 tel:%2B44%20870%20608%200063
Sirius Labs: http://www.siriusit.co.uk/labs
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Loading LDAP schema files into cn=config
Il 02/07/2011 00:47, Christopher Wood ha scritto: What stops you from checking the ldif of cn=config into revision control before and after a change? Complexity, because you have to add more steps to have less informations. I don't think there are comments inside cn=config, and those are very important when you have to document and track tens of different installations. Simone
Re: Loading LDAP schema files into cn=config
Christopher Wood wrote: What stops you from checking the ldif of cn=config into revision control before and after a change? Nothing. But it's more cumbersome. Also comments are lost. Normally I comment everything and describe for which requirement in the concept the ACLs, constraints, etc. are for. Also the schema with X-ORDERED is cumbersome. There's no LDAP client which really supports it. You have to do too much manually. There's no mechanism like include. Etc. Ciao, Michael. On Fri, Jul 01, 2011 at 07:20:14PM +0200, Michael Ströder wrote: Simone Piccardi wrote: Having text configuration files (that can be commented and put under a revision system) is a major strength for an Unix system, and giving it away is very bad. Amen. Ciao, Michael.
Re: Loading LDAP schema files into cn=config
On 2/7/2011 2:53 μμ, Simone Piccardi wrote: ... I don't think there are comments inside cn=config, and those are very important when you have to document and track tens of different installations. Indeed, it seems that the config schema does not include a description (or similar) attribute which can be used freely in any config DIT entries for documentation purposes. If this is truly the case, wouldn't it be advisable to add such support to the config schema? Of course, this means that all objectclass definitions should include: ...MAY (... $ description ) ... Or, are there any other suggestions on how to include documentation in the config DIT? Documenting entries has proved very valuable in practice. Usually, in our DIT (which includes mainly people, mail alias, other accounts, and DNS data) we use single-valued or multi-valued (per entry) description attributes (as defined in RFC 4519) which serve very well our documentation needs. These are already included in the objectClasses we use (based on account, person, domain etc. objectClasses ). In some cases, we format these description values in very specific ways so as to allow automatic processing of various attributes from external scripts, based on data provided in the description attribute values. This use of description attribute values might be unconventional (?) but it suits our needs well and it has been a quite flexible tool. Regards, Nick
Re: Loading LDAP schema files into cn=config
Nick Milas wrote: On 2/7/2011 2:53 μμ, Simone Piccardi wrote: I don't think there are comments inside cn=config, and those are very important when you have to document and track tens of different installations. Indeed, it seems that the config schema does not include a description (or similar) attribute which can be used freely in any config DIT entries for documentation purposes. If this is truly the case, wouldn't it be advisable to add such support to the config schema? Of course, this means that all objectclass definitions should include: ...MAY (... $ description ) ... While description may help a little bit you cannot add comments for each configuration directive for example ACLs. Usually, in our DIT (which includes mainly people, mail alias, other accounts, and DNS data) we use single-valued or multi-valued (per entry) description attributes (as defined in RFC 4519) which serve very well our documentation needs. These are already included in the objectClasses we use (based on account, person, domain etc. objectClasses ). I also use 'description' quite a lot especially since my web2ldap displays it as bubble help in the browser. But it's not sufficient in this case. Ciao, Michael.
Re: Loading LDAP schema files into cn=config
--On Saturday, July 02, 2011 1:36 PM -0500 Chan Wilson chanwil...@gmail.com wrote: And recognizing that emergencies *do* happen, and having a Plan of Action is key to responding to emergencies correctly, what *is* the proper way to manually edit cn=config? Particularly in a replicated RTC setup? I figure it's something like - shut off slapd - edit the ldif. - remove | edit one or more of the operational attributes - turn on slapd slapmodify would be the correct thing to use (Currently only in HEAD). Oddly, I followed the test050 procedure in creating my bootstraps and based from that did expect it to work. I do this routinely to set up replication, and it works fine for me without a restart. That's with 2.4.21, 2.4.23, 2.4.25 and 2.4.26. --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
Re: Loading LDAP schema files into cn=config
Chan Wilson wrote: The ability to do manual disaster-recovery/emergency config changes is crucial. But you also have to understand that going this route is for *emergencies* - it is not the way to go for routine administrative tasks. One item I've always wondered about the RTC design -- with all the other details being tracked, where's the checksum of the entry? See 2.4.26. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Loading LDAP schema files into cn=config
Michael Ströder wrote: Nick Milas wrote: On 2/7/2011 2:53 μμ, Simone Piccardi wrote: I don't think there are comments inside cn=config, and those are very important when you have to document and track tens of different installations. Indeed, it seems that the config schema does not include a description (or similar) attribute which can be used freely in any config DIT entries for documentation purposes. If this is truly the case, wouldn't it be advisable to add such support to the config schema? Of course, this means that all objectclass definitions should include: ...MAY (... $ description ) ... While description may help a little bit you cannot add comments for each configuration directive for example ACLs. 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. The other alternative is to add a generic description attribute, and tag it with the attribute that a comment refers to: description;x-olcAccess: blah blah blah This is a lot simpler for us to implement. Usually, in our DIT (which includes mainly people, mail alias, other accounts, and DNS data) we use single-valued or multi-valued (per entry) description attributes (as defined in RFC 4519) which serve very well our documentation needs. These are already included in the objectClasses we use (based on account, person, domain etc. objectClasses ). I also use 'description' quite a lot especially since my web2ldap displays it as bubble help in the browser. But it's not sufficient in this case. Ciao, Michael. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
