LDAP Series Part VI - Directory Service Modeling
LDAP services exist in a TCP/IP context. It's an Internet service that uses daemons, requires an administrator, configuration files and structure. In some ways LDAP resembles a Linux file system with a root, limbs instead of directories, etc. Unlike the directory configuration of an operating system, LDAP is flexible in its structuring. That flexibility translates into a design makeup you can simply create. We call the hierarchical model a Directory Information Tree (DIT). Whoever designs the DIT needs to know something about how to model data.
After this, you may find the subject floating over your head, but stay with me for a while. I have compared a typical information model of LDAP to an organizational chart of an enterprise. For example, the limbs of a DIT often correspond to departments referred to in LDAP terms as an organizational unit (ou). The head or root of the tree corresponds to an organization's Internet domain name. We call that a domain component (dc).
If you have had the pleasure of constructing your own directory server, then you know we start with a root that looked like this:
dc=examle,dc=org. If you wanted to set up a department called accounting, your name space would look like this: ou=accounting,ou=people,dc=example,dc=org.
That seems a cumbersome, odd and confusing way to name entries in your directory. So, now you know. LDAP as a subject in the open source space requires familiarity and even mastery of a significant body of knowledge. Novell and Microsoft have simplified the design and management of LDAP using eDirectory and Active Directory.
Like many subjects in the various areas of Linux administration you will run into jargon and terminology unique to the application. Rather than attempt to explain every concept and nuance of LDAP's terms, let’s use a chart that you can reference as you begin to see DITs in practice.
The originators of LDAP Tim Howes, Steve Kille and Wengyik Yeong set up a data model arranged hierarchically. At the top of their DIT they depicted their directory root identified by server name. You can see an early model used in the explanation of LDAP:
| dc=servername, dc=yourdc, dc=com | | / \ / \ / \ / \ ou=Department ou=Corporate / \ / \ cn=Jeff Skilling cn=Ken Lay
In this simplified example, the root of the DIT contains domain components. Below the root you can see the organizational units then the people that populate each ou. In this case, Jeff and Ken (no relation) are the users. They use the notation of cn for their name space. CN stands for common name.
What if you wanted to build a simple white page directory for people in an organization that had several departments such as executives, human resources, accounting, IT, sales, shipping, etc. You would typically create an organizational unit for each department and then put users in each department. You could also create a DIT based on geographic components like New York, Seattle, Hong Kong, Paris, etc. The geographic DIT could also have organizational units under other organizational units.
We might want to call each geographical unit a site and build departments within each site. So, you could have a site called New York and a department called accounting with an organizational unit below that called payroll or accounts payable.
Now, you need to populate the directory. Using OpenLDAP, for example, you need to create a text file called a Lightweight Directory Interchange Format (LDIF) file to create entries in your directory. You also will use commands to add the entries to your directory. Let’s peak at this some of this.
First, here’s the format of the file you would use to create an ou:
dn: ou=people,dc=example,dc=org ou: people description: All employees objectClass: organizationalUnit dn: ou=auth,dc=example,dc=org ou: auth description: services objectClass: organizationalUnit
On the first line you have what we call a distinguished name (dn). In this case the people organizational unit’s name space is
You would use this notation to create any ou.
To put this data model into the directory, you would use a command line expression such as:
># ldapadd -x -D "cn=people,dc=ldap,dc=example,dc=org" -W -f ou.ldif Enter LDAP Password: adding new entry "uid=People,ou=people,dc=example,dc=org" >#
Now, someone may attempt to convince you that using ldif files and complex command line statements is cool. But, I’m not buying it. If you want to add a user, for example, your LDIF file might look like this:
dn: ou=it,ou=people,dc=example,dc=org ou: it description: Information Technology mail: email@example.com maildrop: firstname.lastname@example.org objectClass: CourierMailAlias objectClass: organizationalUnit dn: ou=staff,ou=people,dc=example,dc=org ou: staff description: Knowledge Workers mail: email@example.com maildrop: firstname.lastname@example.org objectClass: CourierMailAlias objectClass: organizationalUnit dn: ou=marketing,ou=people,dc=example,dc=org ou: marketing description: Sales mail: email@example.com maildrop: firstname.lastname@example.org objectClass: CourierMailAlias objectClass: organizationalUnit
If you only had to model your directory one time, you might consider using complex data objects as a necessary evil. But, that’s not the case. Anytime you need to add, change or delete users or move them from one department to another, you have to use this somewhat archaic method.
I can understand the necessity of using the methods above eight or ten years ago, but not today. Tools exist to help you and in a commercial context, you might find the simplicity of modeling a directory surprising.
In the next installment, we’ll stay with the command line model and build a SMB directory. You’ll find this useful, especially if you would like to create a samba infrastructure.
Until then, you might look around again at the documentation for LDAP on the web.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Interview with Patrick Volkerding
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide