OpenLDAP Everywhere Reloaded, Part I
Directory services is one of the most interesting and crucial parts of computing today. They provide our account management, basic authentication, address books and a back-end repository for the configuration of many other important applications.
It's been nine long years since Craig Swanson and Matt Lung originally wrote their article "OpenLDAP Everywhere" (LJ, December 2002), and almost six years since their follow-up article "OpenLDAP Everywhere Revisited" (LJ, July 2005).
In this multipart series, I cover how to engineer an OpenLDAP directory service to create a unified login for heterogeneous environments. With current software and a modern approach to server design, the aim is to reduce the number of single points of failure for the directory.
In this article, I describe how to configure two Linux servers to host core network services required for clients to query the directory service. I configure these core services to be highly available through the use of failover pools and/or replication.
Figure 1. An Overall View of Core Network Services, Including LDAP (Note: the image of the hard disk icon in this figure was taken from the Open Icon Library Project: http://openiconlibrary.sourceforge.net.)
Assumptions and Prerequisites
Certain approaches were taken in this design with small-to-medium enterprises (SMEs) in mind. You may wish to custom-tailor the design if you are a small-to-medium business (SMB) or large-scale enterprise.
The servers discussed in this article were installed with the latest
stable version of the Debian GNU/Linux. At the time of this writing, this
was Debian 18.104.22.168 (Squeeze). Although it has not been tested for Ubuntu,
Ubuntu users should be able to log in as root (run
-) and have
As per Figure 1, the fictional local domain name is example.com. Four fictitious subnetworks exist: 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24 and 192.168.4.0/24. Routing between the four subnets is assumed to be working correctly. Where appropriate, please substitute applicable values for your domain name, IP addresses, netmask addresses and so on.
LDAP users are assumed to have home directories in /export/home rather than /home. This allows LDAP credentials to be compatible for operating systems other than Linux. Many proprietary UNIXes, for example, use /export/home as the default home directory. /home on Solaris is also reserved for other purposes (automount directories).
The design assumes that /export/home is actually a shared disk.
This is typically implemented as a mountpoint to an NFS server on a host or NAS; however, the design makes no determination about how to achieve the shared disk, which is beyond the scope of the article, so I'm leaving it to the reader to decide how to implement this.
You can opt not to implement the shared disk, but there are some serious drawbacks if you don't. All LDAP users will need their $HOME directory to be created manually by the administrator for every server to which they wish to log in (prior to them logging in). Also, the files a user creates on one server will not be available to other servers unless the user copies them to the other server manually. This is a major inconvenience for users and creates a waste of server disk space (and backup tape space) because of the duplication of data.
All example passwords are set to "linuxjournal", and it's assumed you'll replace these with your own sensible values.
On both linux01.example.com and linux02.example.com, use your preferred package manager to install the ntp, bind9, bind9utils, dnsutils, isc-dhcp-server, slapd and ldap-utils packages.
Start with Accurate Timekeeping (NTP)
Accurate timekeeping between the two Linux servers is a requirement for DHCP failover. There are additional benefits in having accurate time, namely:
It's required if you intend to implement (or already have implemented) secure authentication with Kerberos.
It's required if you intend to have some form of Linux integration with Microsoft Active Directory.
It's required if you intend to use N-Way Multi-Master replication in OpenLDAP.
It greatly assists in troubleshooting, eliminating the guesswork when comparing logfile timestamps between servers, networking equipment and client devices.
Once ntp is installed on both linux01.example.com and linux02.example.com, you are practically finished. The Debian NTP team creates very sensible defaults for ntp.conf(5). Time sources, such as 0.debian.pool.ntp.org and 1.debian.pool.ntp.org, will work adequately for most scenarios.
If you prefer to use your own time sources, you can modify the lines
server in /etc/ntp.conf. Replace the address with that
of your preferred time source(s).
You can check on both servers to see if your ntp configuration is correct with the ntpq(1) command:
root@linux01:~# ntpq -p remote refid st t when poll reac h delay offset jitter ==================================================== ========================== +warrane.connect 22.214.171.124 2 u 728 1024 377 74.013 -19.461 111.056 +a.pool.ntp.uq.e 126.96.36.199 2 u 179 1024 377 79.178 -14.069 100.659 *ntp4.riverwillo 188.8.131.52 2 u 749 1024 377 76.930 -13.306 89.628 +c122-108-78-111 184.108.40.206 3 u 206 1024 377 78.818 6.485 72.161 root@linux01:~#
Don't be concerned if your ntpq output shows a different set of servers. The *.pool.ntp.org addresses are DNS round-robin records that balance DNS queries among hundreds of different NTP servers. The important thing is to check that ntp can contact upstream NTP servers.
Name Resolution (DNS)
If the LDAP client can't resolve the hostname of the Linux servers that run OpenLDAP, they can't connect to the directory services they provide. This can include the inability to retrieve basic UNIX account information for authentication, which will prevent user logins.
As such, configure ISC bind to provide DNS zones in a master/slave combination between the two Linux servers. The example workstations will be configured (through DHCP) to query DNS on linux01.example.com, then linux02.example.com if the first query fails.
Note: /etc/bind/named.conf normally is replaced by the package manager
when the bind9 package is upgraded.
Debian's default named.conf(5) has an
/etc/bind/named.conf.local statement so that site local zone
configurations added there are not lost when the bind9 package is upgraded.
Stewart Walters is a Solutions Architect with more than 15 years' experience in the Information Technology industry. Amongst other industry certifications, he is a Senior Level Linux Professional (LPIC-3).
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
- Interview with Patrick Volkerding
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Returning Values from Bash Functions
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Managing Linux Using Puppet
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