Alhough this site will stay up for awhile, I won't be making any new posts here.
For the latest from "Eldapo" you'll need to go to
eldapo.lembobrothers.com
which is a new subdomain of mine set up on a shared host.
I'm still going through all the articles I recently exported from here to that new site, laboriously fixing the formatting of the substantial chunks of source code that are the real treasure this site has to offer, but after completing the conversion of another site this weekend I've decided that there's no time like the present to pick up and continue the work started here over there.
Hope you'll visit soon, and that the content made available there is useful to you.
from blogger to wordpress
Today was the day I decided to import this blog from Blogger into a copy of WordPress I have running on my new personal site, under the URL eldapo.lembobrothers.com.
While the import itself went smoothly (thanks to a slight hack to the blogger.php file under wp-admin/import (an instance of www2.blogger.com needed to be changed to www.blogger.com), after looking over the formatting of my articles I was disappointed to see that almost every section of text wrapped in the <code> and <pre> tags had been seriously screwed up. Some of the problem was due to the new application trying to be "helpful", completing tags before the code block was, well, complete. It also seemed to have a great deal of trouble getting linebreaks right. Given that eldapo.blogspot.com goes back around 3 years, with a total of 69 mostly code heavy pieces, this means that I’m going to have to go in a reformat almost every article by hand.
Now the thing is, that rendering big chunks of source code in Blogger was never a picnic. In fact, it's been downright aggravating. Unfortunately, it doesn’t look like WordPress is going to be any easier. In fact, I’ve already experienced some of WP’s own eccentricities in this regard and I’m not pleased. There's something to be said for handcoding your own HTLM pages (sorry, I meant to say "XHTML").
Oh joy. Just what I needed. So much for easier, faster, better.
All applications suck. Blogging applications suck most.
(and my current theme in WP does full justification, and a really crummy job of it to boot -- kind of like WordStar for CP/M or IBM DisplayWrite on an old XT clone with a Hercules graphics card ... yuck!)
While the import itself went smoothly (thanks to a slight hack to the blogger.php file under wp-admin/import (an instance of www2.blogger.com needed to be changed to www.blogger.com), after looking over the formatting of my articles I was disappointed to see that almost every section of text wrapped in the <code> and <pre> tags had been seriously screwed up. Some of the problem was due to the new application trying to be "helpful", completing tags before the code block was, well, complete. It also seemed to have a great deal of trouble getting linebreaks right. Given that eldapo.blogspot.com goes back around 3 years, with a total of 69 mostly code heavy pieces, this means that I’m going to have to go in a reformat almost every article by hand.
Now the thing is, that rendering big chunks of source code in Blogger was never a picnic. In fact, it's been downright aggravating. Unfortunately, it doesn’t look like WordPress is going to be any easier. In fact, I’ve already experienced some of WP’s own eccentricities in this regard and I’m not pleased. There's something to be said for handcoding your own HTLM pages (sorry, I meant to say "XHTML").
Oh joy. Just what I needed. So much for easier, faster, better.
All applications suck. Blogging applications suck most.
(and my current theme in WP does full justification, and a really crummy job of it to boot -- kind of like WordStar for CP/M or IBM DisplayWrite on an old XT clone with a Hercules graphics card ... yuck!)
openldap with an old-style root dn (o=example,c=US)
I needed to do this during testing of an OpenLDAP proxy, and since examples were so difficult to find, thought I'd post it here.
To make this work your slapd.conf must have an include line for the core.schema (in addition to any others you might need for user entries, like cosine, inetorgperson and nis schemas).
In slapd.conf, under your database line (e.g. database dbd), you need to put a suffix directive like:
Then when you create your db load file for slapadd to create the database, make sure you include your root dn at the top:
Notice that there is no 'c' attribute or value in the body of the entry. Under the "standard" organization schema (contained in core.schema) countryName or 'c' is not an allowed attribute. The attribute may be used in a distinguished name, however. DN values are not subject to the schema in the same ways as other attributes within an entry.
To make this work your slapd.conf must have an include line for the core.schema (in addition to any others you might need for user entries, like cosine, inetorgperson and nis schemas).
In slapd.conf, under your database line (e.g. database dbd), you need to put a suffix directive like:
database dbd
suffix "o=Example,c=US"
Then when you create your db load file for slapadd to create the database, make sure you include your root dn at the top:
dn: o=Example,c=US
objectclass: top
objectclass: organization
o: Example
Notice that there is no 'c' attribute or value in the body of the entry. Under the "standard" organization schema (contained in core.schema) countryName or 'c' is not an allowed attribute. The attribute may be used in a distinguished name, however. DN values are not subject to the schema in the same ways as other attributes within an entry.
openldap as a metadirectory
Now that I've got some experience using the OpenLDAP proxy backend, I've moved on to sttuggling with getting the meta backend ("slapd-meta" or "back-meta", the former how it's looked up in the man pages, the latter how it's referred to in the doc and on the mail lists).
The doc is really sparse on this. Actually, it doesn't really address it at all. The man pages are, well, man pages. So this is going to be a real "adventure". There's not much on the lists either, for the most part pleas for concrete examples are met with "what are you trying to do" or "why would you want to do that" from various quarters.
Very interesting.
Anyway, I've started off by building my own custom OpenLDAP server from the latest stable source. Here's my configure syntax:
In the list above only ldap, meta and rewrite should be essential. After some initial experimentation, I found that my efforts to merge together two or more directory trees were only successful after I compiled in the glue overlay.
If you look at my description below of where I'm going with this, I think it will become obvious why I'm including the other modules/overlays listed (except for rwm, that overlay is supposed to replace rewrite in future, so I want to try it out now).
I'm also going to try some different config variations from the slapd-meta man page, which so far hasn't gone so well.
Before I start in earnest though, let me set out what I'm looking for.
One of the big problems that all directory admins have to deal with is the insane amount of data importing, conversion and outright munging necessary to maintain a centralized directory service that's going to be of any use by anyone. While proxying and caching results can help, the most vexing issue remains how to most efficiently consolidate needed information into the directory.
There are other, rather simple, solutions to this dilema. The one most recommended in the early years of LDAP was to use the referral feature to have queries get redirected to another directory that would have the data the inquirer was looking for. Of course, if data were spread out over several different directories (or relational databases with LDAP listeners), that would force an application to make multiple queries and consoliate the information for itself.
What really is needed is a consolidated "view" of multiple sources of data into a single LDAP directory record for a user, all nicely massaged and normalized for use by any application that needs it. That's why I've also compiled in support for the sql backend (an ODBC manager and it's source, like unixODBC and unixODBC-devel are required to compile), proxycache, attribute uniqueness, referential integrity and dynamic groups.
This is my quest. To follow that star. No matter how hopeless. No matter how far.
I hope along the way we'll all learn a few things we can actually use "back at the shop", as my Dad used to say.
The doc is really sparse on this. Actually, it doesn't really address it at all. The man pages are, well, man pages. So this is going to be a real "adventure". There's not much on the lists either, for the most part pleas for concrete examples are met with "what are you trying to do" or "why would you want to do that" from various quarters.
Very interesting.
Anyway, I've started off by building my own custom OpenLDAP server from the latest stable source. Here's my configure syntax:
./configure --prefix=/opt/openldap/meta \
--enable-ldap \
--enable-meta \
--enable-sql \
--enable-rewrite \
--enable-rwm
--enable-proxycache \
--enable-glue \
--enable-unique \
--enable-refint \
--enable-dynlist
In the list above only ldap, meta and rewrite should be essential. After some initial experimentation, I found that my efforts to merge together two or more directory trees were only successful after I compiled in the glue overlay.
If you look at my description below of where I'm going with this, I think it will become obvious why I'm including the other modules/overlays listed (except for rwm, that overlay is supposed to replace rewrite in future, so I want to try it out now).
I'm also going to try some different config variations from the slapd-meta man page, which so far hasn't gone so well.
Before I start in earnest though, let me set out what I'm looking for.
One of the big problems that all directory admins have to deal with is the insane amount of data importing, conversion and outright munging necessary to maintain a centralized directory service that's going to be of any use by anyone. While proxying and caching results can help, the most vexing issue remains how to most efficiently consolidate needed information into the directory.
There are other, rather simple, solutions to this dilema. The one most recommended in the early years of LDAP was to use the referral feature to have queries get redirected to another directory that would have the data the inquirer was looking for. Of course, if data were spread out over several different directories (or relational databases with LDAP listeners), that would force an application to make multiple queries and consoliate the information for itself.
What really is needed is a consolidated "view" of multiple sources of data into a single LDAP directory record for a user, all nicely massaged and normalized for use by any application that needs it. That's why I've also compiled in support for the sql backend (an ODBC manager and it's source, like unixODBC and unixODBC-devel are required to compile), proxycache, attribute uniqueness, referential integrity and dynamic groups.
This is my quest. To follow that star. No matter how hopeless. No matter how far.
I hope along the way we'll all learn a few things we can actually use "back at the shop", as my Dad used to say.
What ever happened to x.500? Or, can we get real for a second about "standards"?
The ubiquitous "dc=example,dc=com" root context hasn't always been the "standard" for LDAP directories. In the beginning (1987), influenced by the .x500 standard, most directories used something like "o=example,c=US" for their directory root. Those were different times, when it looked like networks, the Internet most of all, was going to be big, global, and most of all corporate.
A funny thing happened on the way to the millenium though. As the developers of LDAP had predicted, x.500 and the DAP (Directory Access Protocol) that accompanied it, were too inflexible, too complex, for even the largest companies to cost-justify implementation. The dream of an interconnected, fully interoperable, world-wide directory passed into history. What we were left with was the simpler, more nimble and still barely structured LDAP (Lightweight DAP) protocol and servers to provide standalone directory services for organizations and individuals, first from the University of Michigan team that invented the protocol, and then Netscape and others after these developers moved out into the commercial market.
The "dc=example,dc=com" root dn format, where the "dc" is short for "domainComponent", is only the most visible sign of this shift to a different approach to directory services.
There are many systems that still default to the old x.500 root dn, most notably IBM's Lotus Domino product. This should be a tip-off that things might not work exactly like other directory products that sport the "dc-example,d=com" format. And they don't. This isn't always a good litmus test though. Microsoft has used the new format in it's Active Directory product from the beginning, but AD very definitely has some un-LDAP like qualities that become painfully apparent very soon after you begin working with it.
As they are wont to do, commercial vendors often equate the Internet standard LDAP v3 protocol with it's implementation by one or more vendors. An application written to interface with Lotus Domino may claim to be "LDAP compliant" but in reality it's interoperability with other LDAP servers may be less than seamless. Another may claim "LDAP compatibility" and then give you a choice between Microsoft Active Directory and Sun (often "iPlanet") Directory.
A close look at their code will usually reveal a custom interface for each directory. The MS interface using (or, inexcusably not using) Simple Paged Results Control to page results from deep searches that would otherwise get truncated or fail because of AD's aggressive limits on search results (default 200 entries, hard of 2,000). The Sun interface might instead use Sun's proprietary Virtual List View (again, or not) to achieve the same result. Sometimes you see really stupid, embarressingly stupid, parameters hardcoded in like requiring a single dn for person entries and only providing a level 1 search (one level down from the base given, so searches won't recurse down into subcontainers) -- making the product useless where your DIT (Directory Information Tree) either nests user entries several levels down, or spreads them out several branches across.
A funny thing happened on the way to the millenium though. As the developers of LDAP had predicted, x.500 and the DAP (Directory Access Protocol) that accompanied it, were too inflexible, too complex, for even the largest companies to cost-justify implementation. The dream of an interconnected, fully interoperable, world-wide directory passed into history. What we were left with was the simpler, more nimble and still barely structured LDAP (Lightweight DAP) protocol and servers to provide standalone directory services for organizations and individuals, first from the University of Michigan team that invented the protocol, and then Netscape and others after these developers moved out into the commercial market.
The "dc=example,dc=com" root dn format, where the "dc" is short for "domainComponent", is only the most visible sign of this shift to a different approach to directory services.
There are many systems that still default to the old x.500 root dn, most notably IBM's Lotus Domino product. This should be a tip-off that things might not work exactly like other directory products that sport the "dc-example,d=com" format. And they don't. This isn't always a good litmus test though. Microsoft has used the new format in it's Active Directory product from the beginning, but AD very definitely has some un-LDAP like qualities that become painfully apparent very soon after you begin working with it.
As they are wont to do, commercial vendors often equate the Internet standard LDAP v3 protocol with it's implementation by one or more vendors. An application written to interface with Lotus Domino may claim to be "LDAP compliant" but in reality it's interoperability with other LDAP servers may be less than seamless. Another may claim "LDAP compatibility" and then give you a choice between Microsoft Active Directory and Sun (often "iPlanet") Directory.
A close look at their code will usually reveal a custom interface for each directory. The MS interface using (or, inexcusably not using) Simple Paged Results Control to page results from deep searches that would otherwise get truncated or fail because of AD's aggressive limits on search results (default 200 entries, hard of 2,000). The Sun interface might instead use Sun's proprietary Virtual List View (again, or not) to achieve the same result. Sometimes you see really stupid, embarressingly stupid, parameters hardcoded in like requiring a single dn for person entries and only providing a level 1 search (one level down from the base given, so searches won't recurse down into subcontainers) -- making the product useless where your DIT (Directory Information Tree) either nests user entries several levels down, or spreads them out several branches across.
second openldap directory on the same server
If you don't need a second, distinct slapd process (e.g. no need for the directory to run on a different port, listen on a different interface, or use a separate logfile) this actually pretty easy. All you have to do is add another "database" line and define a different suffix than any of the database definitions that came before.
So, if your first database was defined as:
... with whatever indexing and other command you've got, the next database would be defined with,
That's all there is to it. You'll connect to this new db using the same port as your other db, but with a different context. So instead of
you'd use
Keep in mind that when initializing the new db, you need to specify it's context as one of the parameters for slapadd
Your new db files will get created in /var/lib/ldap2, or whatever directory you specified within your new database definition.
Don't forget that you must specify indexes, time and size limits for each database defined, even if these will be the same as those already set for previous databases.
Also, when you combine two or more databases in the same slapd.conf, operations from both will get logged together. If you want separate logs you'll need to set up a second slapd.conf and invoke slapd a second time with this new slapd.conf as the config file. Something like this:
In the above line I've set a different syslog facility for my log (and defined it in syslog.conf to write to a different log file than my main slapd, which is running on LOCAL4), I'm also starting it up on a different port (10389).
So, if your first database was defined as:
database dbd
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap
... with whatever indexing and other command you've got, the next database would be defined with,
database dbd
suffix "dc=sample,dc=org"
rootdn "cn=Manager,dc=sample,dc=org"
rootpw secret
directory /var/lib/ldap2
That's all there is to it. You'll connect to this new db using the same port as your other db, but with a different context. So instead of
ldapsearch -x -LLL -b "dc=example,dc=com" -s sub "objectclass=*"
you'd use
ldapsearch -x -LLL -b "dc=sample,dc=org" -s sub "objectclass=*"
Keep in mind that when initializing the new db, you need to specify it's context as one of the parameters for slapadd
slapadd -s /etc/openldap/slapd.conf -b "dc=sample,dc=org" -l sample.ldif
Your new db files will get created in /var/lib/ldap2, or whatever directory you specified within your new database definition.
Don't forget that you must specify indexes, time and size limits for each database defined, even if these will be the same as those already set for previous databases.
Also, when you combine two or more databases in the same slapd.conf, operations from both will get logged together. If you want separate logs you'll need to set up a second slapd.conf and invoke slapd a second time with this new slapd.conf as the config file. Something like this:
slapd -n slapd2 -l LOCAL6 -f /etc/openldap/slapd2.conf -h \
ldap:///:10389 -u ldap -g ldap
In the above line I've set a different syslog facility for my log (and defined it in syslog.conf to write to a different log file than my main slapd, which is running on LOCAL4), I'm also starting it up on a different port (10389).
Subscribe to:
Posts (Atom)