LDAP? Whats That?
Explore a new HP 3000 feature, and see how a little LDAPll do ya
By Curtis Larsen
When you think of LDAP, what do you think of? Youve probably heard about it something to do with directories, right? but youre not quite sure. Youve heard some industry buzz about it here and there, read a paper or two, but perhaps you still dont quite know what it can do for you, or how it could work with an HP e3000 system. Hopefully this article will de-mystify it a bit for you, and spark some ways you could use it in your own organization.
MPE currently has limited support for LDAP, but the support is growing. Aside from the OpenLDAP source ported by Lars Appel, HP offers an LDAP C Software Development Kit for writing HP e3000 code to access directories, er, directly.
LDAP stands for Lightweight Directory Access Protocol. In a nutshell, it allows you to create directories of information similar to what you would see in a telephone book. Any information you want to store for later quick retrieval: names, telephone numbers, conference room capacities, addresses, directions even picture or sound files. Using directories such as these is an incredible time-saver (cant you think of company applications for one already?), but LDAP can do so much more. The directories you create are wholly up to you, so the skys the limit.
At this point you might be saying Great, but why not use a database for this stuff? Thats an excellent question, and in truth, there is some overlap in what you might want stored in a database versus being stored in a directory. The first and foremost difference between them is that a directory is designed for high-speed reading (and searching) not writing. The idea is that, generally speaking, a directory doesnt change much, but quickly reading its information is a must. Understand that this doesnt mean that directory writes are at all bad theyre just not structurally designed to be as fast as reads are.
Databases also require more in the way of overhead: high-powered servers and disks, (usually) high-priced Database Management Systems which one will be best for you? and highly-skilled, highly-paid DBAs to keep it all happy. (Our DBA said I had to mention that part.)
LDAP directories are generally simpler and faster to set up and manage. LDAP is (also) a common client-server access standard across many different systems. You dont have to deal with the outrageous slings of one DBMS, or the delightful syntax variations in SQL or ODBC implementations. LDAP directories can even be replicated. Copies of directories, or just sections of larger directories, can be stored on different servers and updated (or cross-updated) periodically. This can be done for security (mirrored directories one here, one elsewhere), performance (all queries against local entries on a local server), or both.
Lets dig more into what LDAP directories can do. I wont get into any real technical details about syntax, history, specifications, etc. Better explanations of these things have already been written by folks far more knowledgeable than I am. Youll find some links at the end of this article that you can use to understand more.
Practical LDAP ideas
For most, adding all the different network and systems logons can be a tedious task. Add to that the different options on each system (like VESoft security on e3000s) and you have a necessary, but time-consuming chore. With an LDAP directory maintained by your Human Resources folks, regular batch jobs can query that directory and perform the add/change/delete maintenance automatically. The jobs can even update the directory with the new logon information.
Wouldnt it be nice to have different batch jobs send various e-mail (or faxes, or pages, or ) to different folks about something? Using that same HR LDAP directory, any job can look up someones current contact info and send them that message, page, fax, etc. Your Admins, Ops, and Help Desk folks are now on to bigger things, and no more need for maintaining separate KSAM or Image tables on the HP system.
Heres a bit of a mind-bender: How about personalized printing? Same as the last example, but what if an LDAP directory stored the list of printers your new hire will (generally) use as well? Now all your systems e3000 included - can direct printed output based upon a person not a destination. If they change locations, just change the directory entry. We can get even more esoteric and say logical entity instead of person. Suddenly, you have the ability to address output to groups of people (Accountings printer, fax or e-mail addresses), other computer systems, etc. Get a little wilder and you can even have the LDAP directory describe the format for the addresses used. (Batch job to LDAP server: I have this color print file on legal paper for Bob where should I send it?) Really, its just a small step past device classes.
Interesting stuff, eh? All of these things are possible this very instant. Yes, they do require some preparation and support work (but then every new technology does). Lets try another idea:
You say you want system-wide variables? How about enterprise-wide variables? Using LDAP, practically any type of system can share information with any other system. You would want those variables to be fairly static (that reads are better thing), but certainly a central repository for something like cross-system daily scheduling information (dates dont change much) or summary totals could be a handy thing. Variable states can be retained as long as needed, too.
Okay, lets explain a little more about that last one. LDAP directories are made up of basically three things: containers, variables and values. Containers can hold either variables or other containers, and variables have values. (Theres a little more to it than this, but it will hold us for now.) Using those elements, the LDAP directory you create looks very much like the classic tree structure used in most file systems (like DOS, Unix, etc.) or even DNS.
An example of this might be a root container for your company, holding a container object named USA,, holding one named New York. In New York is a dept. container named Accounting, and in that is one named P. Strings. That object type might be person, and it, in turn holds all sorts of contact information. You could just as easily have a container named Jobs, holding one named Schedule X, wherein we could find lots of information on Schedule X, like its completion time and status.
For the object-oriented among you, you can also think of a container as an object, and variables as properties of that object. This makes LDAP very workable with OOP. Perl likes it, Python likes it shucks, even C++ thinks it has class.
This idea is a bit stretched, but: persistent, cross-platform objects/object classes. You can use an LDAP directory as a base class template library and retrieve certain directory sections into a program for later use. Use them as a library of other things as well. LDAP directories fit DOM fairly well, so you can use LDAP to store DTDs and other work with XML. (Does anyone know where the DTD for getting EDI XML data from Foobar, Inc. is? Yeah, Its the LDAP directory under DTDs, EDI, Foobar, or just do a search for Foobar, Inc..
Where LDAPs in use
Finally, I should mention that major products and projects do use LDAP:
Novells NDS uses it heavily, as does Microsoft Windows 2000.
E-mail applications such as Microsoft Exchange Server and Novell Groupwise both permit LDAP access and searches of addresses, etc. Sendmail can/will use LDAP for authentication.
One big upcoming use of LDAP will be in the next major version of Samba. Using an LDAP directory, Samba will be able to authenticate connections to shares and services without requiring the allowed user to be an actual user ID. This is a very big deal, and finally means authentication to one source. (You can see some of these not-quite-used settings now in some of the latest Samba books.)
Many Internet-access-enabled colleges, and businesses allow LDAP access.
There are LDAP-to-web gateways, and Kerberos encryption availability (for authenticating your LDAP logon), etc.
I certainly hope you found this article useful, and that it gives you some thoughts about what you might want to do with an LDAP server or two accessed by your HP e3000. LDAP, like Samba and Apache before it, is yet another example of innovative technology working upon the rock-solid stability of the HP e3000 system. File and print server, web server, and now LDAP who says the e3000 cant share?
Find out more at LDAP links
Curtis Larsen has been working
with HP 3000s for over 10 years, and believes that, given enough
time, any application can be written using the CI. He currently works
for Covance Laboratories, in Madison, Wis.
Copyright The 3000 NewsWire. All rights reserved.