Disruptive Library Technology Jester » Gentoo

DLTJ In a State of Flux

Peter Murray — Tue, 28 Dec 2010 16:45:54 +0000

DLTJ is in a bit of flux now. After updating some underlying packages on my 9-year-old Gentoo-based personal server, I’m finding that I can’t start the web server process without the 1-minute load average climbing to roughly 60 in the span of about 5 minutes. (Translation: the machine is working very hard but getting nowhere fast.) Increasingly, the server has also been hard to update — lots of strange errors, etc. — so after 9 years, it is clearly time to rebuild it. In the interim, I’m in the process of moving the blog over to an Amazon EC2 cloud computing instance. If you see this post, you are reading it on that virtual server. The DNS entries should catch up with the migration in a couple of hours.

Because this wasn’t necessarily planned, you’ll see things change a lot. I’m still working on theme changes, for instance. But all the content is migrated over. If this goes well, perhaps I’ll leave DLTJ in the cloud…

Gentoo Abandons WordPress in Portage

Peter Murray — Tue, 07 Aug 2007 14:43:05 +0000

I don’t think this has been widely announced, but while waiting for an update to Gentoo‘s portage entry for WordPress to cover the latest security and bug fixes, I discovered in the comments of a bug in Gentoo’s bugzilla database that they are making no effort to support WordPress on Gentoo. I think this is really a poor move on Gentoo’s part. As one of the bug commenters noted, “WordPress is, in general, a good product with an extremely active user community and good upstream maintenance.” ¹

A GLSA was issued for WordPress vulnerabilities in March — problems that have since been fixed — with this ‘resolution’:

Due to the numerous recently discovered vulnerabilities in WordPress, this package has been masked in the portage tree. All WordPress users are advised to unmerge it.

Now I’ll admit that I should not be expecting updates to packages that have been hard masked, but really — is this any way to treat the world’s most popular blogging software? In any case, I’ve abandoned Gentoo’s ebuild for WordPress and have reverted to the Subversion method for updating a WordPress installation. So here is a heads-up to do something similar should you find yourself in the same situation.

[20070812T2046 update: The portage keepers bumped the version of WordPress to 2.2.2 in Portage yesterday.]

Footnotes

Comment #16 on bug #168529 from Stephen Ulmer dated 2007-03-17 16:09:26 0000

Killing Off Runaway Apache Processes

Peter Murray — Mon, 26 Feb 2007 22:03:10 +0000

Well, something is still going wrong on dltj.org — despite previous performance tuning efforts, I’m still running into cases where machine performance grinds to a halt. In debugging it a bit further, I’ve found that the root cause is an apache httpd process which wants to consume nearly all of real memory which then causes the rest of the machine to thrash horribly. The problem is that I haven’t figured out what is causing that one thread to want to consume so much RAM — nothing unusual appears in either the access or the error logs and I haven’t figured out a way to debug a running apache thread. (Suggestions anyone?)

Found it! It was a WordPress plug-in plus a change to the PHP configuration that was causing the problem. The fix for the fundamental cause of the problem came from a comment timestamped February 8th, 2007 at 3:55 pm on the Footnotes 0.9 Plugin for WordPress 2.0.x page. An infinite loop was consuming both CPU cycles and RAM, and this was exacerbated by a change I made to the maximum CPU execution time for PHP scripts that was required in order to play with the IP City Cluster plug-in. With the patch to the Footnotes plug-in, dltj.org has gone 12 hours without a run-away apache process.

In any case, I whipped up this little ditty that is running every five minutes in cron as a way to gloss over the problem for the moment. Running as root, it looks into all of the processes in the virtual /proc file system, specifically in the ‘stat’ file, and using awk looks to see if the second space-delimited value is the name of the httpd process (this is the Gentoo Linux distribution, so the name of the process is apache2) and the 23rd space-delimited value (the virtual size of the process) is bigger than 800MB. If so, it prints out the PID of the process (the first value in the stat file) at which the bash script unceremoniously sends it a kill (‘-9′) signal. The script looks like this:

#!/bin/bash
 
for i in `/bin/ls -d /proc/[0-9]*`; do
        if [ -f $i/stat ]; then
                pid=`/bin/awk '{ if ($2 == "(apache2)" && $23 > 800000000) print $1}' $i/stat`
                if [ "$pid" != "" ]; then
                        echo "Killing $pid because of load average: `awk '{print $1}' /proc/loadavg`"
                        kill -9 $pid
                fi
        fi
done

If anyone has any suggestions as to how to narrow down what the problem might be, I’d appreciate hearing from you. I’ve tried eliminating WordPress plugins, recompiling WordPress and Apache, and attempted to catch the behavior with a network traffic sniffer, but have come up empty so far.

WordPress/MySQL Tuning

Peter Murray — Thu, 22 Feb 2007 18:56:45 +0000

dltj.org runs on a relatively tiny box — a Pentium III with 512MB of RAM. I’m running a Gentoo Linux distribution, so I actually have a prayer of getting useful work out of the machine (it server is actually a recycled Windows desktop), but the performance just wasn’t great. As it turns out, there are several easy things one can do to dramatically improve life.

The Configuration

The box is both a mail server (IMAP) and a WordPress server. A rough eyeball at the process accounting on the server shows that it spends about 40% of the time doing mail (mostly taken up by Clamscan virus scanning and spam checking) and another 40% doing MySQL and web stuff. Since there isn’t much dynamic content on the box and nothing else using the database but WordPress, I’m fairly confident that blog traffic is almost all of that 40%. I’m using MySQL 5.0.x, Apache 2.0.x and WordPress 2.0.x with about two dozen plugins.

Taking PHP Up A Notch

PHP is an interpreted programming language, meaning that each time a script runs it needs to be translated into something closer to machine code (called the ‘opcode’). (As opposed to compiler languages like C and Java where you compile the source code into an executable in one step and then run that executable in a second step.) For an application like WordPress, where the source code is not changing, this translation causes a lot of overhead. Fortunately, there is a PHP plug-in called the Alternative PHP Cache that will saved the translated opcode the first time the script runs and use it for subsequent invocations. Getting this set up is pretty easy (these are Gentoo-specific commands, your Linux distribution will vary and I am glossing over a number of distribution-specific details like how to install packages and where the configuration files will reside):

emerge -aDNtuv pecl-apc will download and install PHP APC and its dependencies (yep — that easy…I love Gentoo)
Change the configuration defaults in /etc/php/apache2-php5/ext/apc.ini. I’ve found that one shared segment of 20MB is enough, so I set apc.shm_size="20". The rest of the settings are as they came in the distribution.
Restart your web server: /etc/init.d/apache2 restart

APC comes with a nifty PHP page that will give you cache statistics and details. If you copy /usr/share/php5/apc/apc.php into your ‘htdocs’ somewhere and execute that page from a browser, you’ll see what I mean. (This is how I learned that 20MB of opcode cache space was fine for my application.)

Kicking MySQL Into Gear

Database tuning focuses a great deal on memory management. Your RAM will always be an order of magnitude faster than reading blocks off a disk. RAM, of course, costs more per MB than disk, though, so you have to select memory management strategies carefully. WordPress is, of course, a read-intensive operation. In other words, the majority of SQL statements are SELECTs rather than INSERTs, UPDATEs, or DELETEs. With that in mind, we tune MySQL with a read-intensive strategy. I found some of the best guidance in Peter Zaitsev’s “What to tune in MySQL Server after installation” and the ez.no documentation on Optimizing for read performance.

The changes I made to my MySQL configuration file, in the [mysqld] section are:

key_buffer = 6M ; (Actually, a decrease from the default since I didn't seem to need as much)table_cache = 512max_connections = 25thread_cache = 16query_cache_type = 1query_cache_limit = 1Mquery_cache_size = 20M

The 20MB query cache limit seems to be just about the right size for me. I seem to get very close to the edge of that buffer, but never seem to go over.

Finishing Up with a WordPress Plug-in

One more thing is needed to make this all come together: Mark Jaquith’s Post Query Accelerator. As Mark points out on his blog, WordPress “always ask[s] for posts with post_date_gmt <= ‘$now’ where $now is set to the current time, to prevent posts in the future from showing up.” If one turns on cache querying as described above, the “problem with $now is that it changes [with each query], so the query is never exactly the same again and the cache doesn’t help.” Mark’s plug-in “freezes” the value of $now to 15 minute increments or to whenever a post is added/updated, which ever comes first. That makes the query cache useful again and all is well.

Simply download the plug-in from Mark’s page and enable it in WordPress. Note that this plug-in is not needed for WordPress 2.1 and higher as the core developers have solved the “$now” problem with the “future” post status.

Managing a Gentoo Linux Server Configuration with Subversion, GLCU, and Trac

Peter Murray — Fri, 22 Dec 2006 17:49:00 +0000

Keeping track of configuration changes to servers is a tough job made tougher when some of the sysadmins work from home. Questions of who did what when and why can be exacerbated by the lack of physical proximity — in other words, I can’t simply yell over the cubical wall to the colleague down the hall to ask him about the new package installed on the server. Besides, that oral history tradition is difficult to maintain and harder to sustain as the number of machines grows. This essay describes a practice for maintaining a Gentoo Linux distribution using GLCU, Subversion, and Trac that is lightweight (doesn’t impose a large burden on the sysadmin staff), effective (although it is lightweight it better documents and makes accessible the state of our systems over the oral history tradition), and cheap (no operating budget dollars were harmed in the creation of this process — only staff time overhead).

Create an All-Encompassing Configurations Directory

The first step is to put the system configuration files into a revision control system (RCS). An RCS allows us to track the history of files by storing information about changes such as the date/time a change was made, what the change was, who made it, and a free-text field explaining why the change was made. RCS systems are common for software development shops as a way to track changes to source code. In this circumstance we are tracking changes to the text configuration files that make up the operating system and its components. We are using the Subversion RCS, but the same concepts apply whether you are using other systems (such as CVS or Arch).

The RCS will want to act on a single directory tree, but in most cases our configuration files are spread out over the file system. Most are in /etc, but others exist elsewhere. (The portage “world” file, a record of everything installed on your system, for instance, is in /var/lib/portage.) What we do is create a directory called /server-rcs that will be managed by the RCS, and in that directory is copies or links to all of the configuration files on the system.

Putting /etc (or any other directory) Under Version Control

One of the things we’re going to want to do, obviously, is put the entire /etc directory into the RCS. Ideally, we would simply put a link to /etc in /server-rcs. Unfortunately, we can’t use the simple filesystem-based linking methods (soft links and hard links) because a) our RCS is smart enough to see the soft link and records it as a soft link in the revision control database rather than following the link to the contents of that directory; and b) one cannot make a hard link to a directory:

/server-rcs # ln ../etc .
ln: `../etc': hard link not allowed for directory

What we need to do instead is a trick using the ‘mount‘ command to bind one portion of the file system to another part. From the mount MAN page:

Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
mount --bind olddir newdir
After this call the same contents is accessible in two places. One can also remount a single file (on a single file).

So we can bind the entire /etc directory into our RCS space with this command:

mount --bind /etc /server-rcs/etc

Better yet, we put this in our /etc/fstab file (also adding the /var/spool/cron directory as well):

/etc                            /system-rcs/etc                         none    bind/var/spool/cron/crontabs        /system-rcs/var-spool-cron-crontabs     none    bind

Since the /etc directory (and other directories) already exist, we’re going to have to play some games to get them into the repository. For the trick do to this with Subversion, see the FAQ entry on in-place imports.

Handling Individual Files Under Version Control

Not everything we want to track is in /etc or neatly packaged into directories. Some application-specific configuration files, most notably web applications, exist somewhere else in the directory structure. We want to track things like the ‘phpmyadmin’ configuration file, for instance.

We could use the mount ‘bind’ trick to put individual files into the /server-rcs space, but that seems overly complicated. Our servers are generally configured with few filesystems, so in many cases the files we need to track in the RCS are within the same filesystem and we can use hard links to put them into the /server-rcs directory. Another alternative is to write a cron job to copy configuration files into the /server-rcs directory, but then realize that this kind of revision control is one way — if we restore a previous version of a file from the RCS, we need to manually copy it back to the original location.

(On the other hand, using the mount ‘bind’ method is a form of self-documenting the otherwise invisible hard links to files in the same filesystem. For that reason, it might be worth considering that option.)

Special Case: /var/lib/portage/world

One special case is the portage ‘world‘ file. This file records all of the user-specified (e.g. non-profile) packages that have been installed on your Gentoo system. Unfortunately, each time ‘emerge‘ runs, the world file is rewritten and the order of package names is seemingly random. This wrecks havoc with the ‘diff’ function of the RCS — it seems like a lot more has changed than just the addition or removal of a package or two.

What we do instead is patch into a hook of the ‘emerge’ command that will save a sorted copy of the world file into /server-rcs. This patch goes into /etc/portage/profile/profile.bashrc:

if [ "${EBUILD_PHASE}" == "setup" ]
then
        sort /var/lib/portage/world &gt; /server-rcs/misc/var-lib-portage-world
fi

Every time ‘emerge’ goes through the ‘setup’ mode when installing a package, it will run this sort command. Note that there is no file locking going on here, so there is a remote chance that the /server-rcs version (but not the /var/lib/portage version) could get corrupted. Such a problem is minor, though, and easily fixed.

Importing into Subversion

With the /server-rcs directory prepared, we now just need to get it into the RCS. These are Subversion commands:

svn add --force /server-rcs
svn checkin --message "Importing the configuration files for the server" /server-rcs https://svn.repository.url/svn/configurations/server

Because of the in-place import problem for pre-existing directories (described earlier), we likely had to create some of the repository directory structure already. (In this example, we would have executed a svn mkdir https://svn.repository.url/svn/configurations/server/etc command already to “prime the pump” for adding /etc to the repository.) In line #1, the –force option makes the ‘svn add’ command continue the recursive directory parse to add files and directories to the RCS structure even if some component of those paths were already in the RCS structure. Line #2 checks in our completed /server-rcs directory.

Daily Usage

With all of this setup done, it is finally time to make use of this configuration management infrastructure. Doing so is pretty easy — work as you normally do when installing packages and making changes to configuration files. (As you do so, you also have the added safety net of svn revert filename should you make a mistake and want to go back to the previous version of a file.) When you’ve done a defined chunk of work, simply run this command:

svn status /server-rcs
svn checkin /server-rcs -m "Free-text description of why you made the changes."

The first line will show you the files modified since the last check-in &mdash hopefully only the files you intended to modify, although this is a good point to check to make sure an inadvertent change didn’t happen. The second line will copy changes to the /server-rcs directory into the RCS along with the free-text note describing why you made the change.

Isn’t this great? It is sort of self-documenting. Not only to you have your brief description of what you did but you also have the exact changes made to the configuration files. If a change doesn’t work out, you have easy access to past configurations that allow you to revert back to a previous state. (Note, though, that we’re not saving actual applications in the RCS — you may have to recompile and install older versions of applications to get back to the previous state.)

Portage Updates with GLCU

We can make our system management lives even easier by using the semi-automated tool Gentoo Linux Cron Update (GLCU). This script breaks up the process of updating packages into two pieces. The first that runs in the off-hours via cron that syncs the local portage copy, download and compiles updated packages, and stages ready-to-install binary distributions of those updates. The second piece has the human interface: seeing the list of updated packages in the staging area, selecting which to install, and prompting the sysadmin to install any updates as a result of Gentoo Linux Security Announcements (GLSAs).

See the project on SourceForge for all of the details on installing, configuring and running GLCU. We make one tweak to the GLCU configuration to prompt the sysadmin to complete all of the housekeeping chores: running dispatch-conf to merge changes to configuration files and revdep-rebuild to make sure all of the applications using updated linked libraries are properly recompiled. To do this, add a line to /etc/conf.d/glcu:

updatetc: dispatch-conf && revdep-rebuild -X -pv

A typical update for us looks like:

# glcu /tmp/glcuUpdate-23112****************************************>> Welcome to glcu's easy update featurePrebuilt packages:------------------(  1 ) [binary     U ] app-editors/nano-2.0.1 [1.3.12-r1] USE="ncurses nls spell unicode  -debug -justify -minimal -slang"(  2 ) [binary     U ] media-libs/libsdl-1.2.11 [1.2.8-r1] USE="X esd* -aalib -alsa -arts  -dga -directfb -fbcon -ggi -libcaca -nas -noaudio -noflagstrip -nojoystick -novideo  -opengl -oss -svga -xinerama -xv (-pic%)" Do you want to install the prebuilt package(s) [Y/n]   (or you can either install only specified package number(s) #,     or NOT install package with -# and use i# for injecting)> y[...pre-compiled packages are installed...]>>> Auto-cleaning packages...>>> No outdated packages were found on your system. * GNU info directory index is up-to-date.* IMPORTANT: 1 config files in /etc need updating.* Type emerge --help config to learn how to update config files.glsa's:  ['200612-03'](  1 ) 200612-03 [N] GnuPG: Multiple vulnerabilities ( app-crypt/gnupg ) Do you want to fix all glsa's now? [Y/n]    (or you can either install only specified glsa number(s) #,     or NOT install glsa with -# and use i# for injecting)> y[...packages related to the GLSA are downloaded, compiled and installed...] Do you want to run dispatch-conf && revdep-rebuild -X -pv now? [Y/n] > y[...dispatch-conf and revdep-rebuild are run...]

With the system nicely updated, we can check in all of the changes to the RCS with a note about what we did:

svn ci -m "After running 'glcu' to update app-editors/nano, media-libs/libsdl, and GLSA for app-crypt/gnupg"

Tracking Configuration Changesets and Trouble Tickets with Trac

So far we’ve done quite a lot to document changes to the configuration of our server. What we’re missing is a nice way to view and track those changes over time. Since everything is in the Subversion RCS, one way to accomplish this is to put a web interface (like ) on top of Subversion repository. For just a little bit more effort and complexity, though, we can have a very nice documentation and issue tracking system bundled with the display of our configuration changes repository by using Trac.

Trac is an open source wiki and issue tracking system for software development projects. Its stated mission is to “help developers write great software while staying out of the way.” In this case we’ll be using it to help sysadmins manage complex systems while staying out of the way. Trac is a web-based tool that “allow wiki markup in issue descriptions and commit messages, creating links and seamless references between bugs, tasks, changesets, files and wiki pages. A timeline shows all … events in order, making the acquisition of an overview of the [state of the system] and tracking progress very easy.”

Trac is synchronized with our Subversion source code repository, so the timeline of changes (demo) shows each check in to the Subversion RCS (demo), which can be tied to an issue ticket (demo) for a problem or task that is requested, worked on, then closed via simple wiki-like markup. One can also browse through the stored changes (demo) and look at a graphical difference between any two revisions of a file (demo) but also review the log of check in messages (demo) associated with that file over time.

Conclusion

With a few tools and some modest changes to current system maintenance practices, the history of the configuration of machines can be documented and the changes viewed over time. The changes in practices are designed to be very minimal and simple yet return a large payoff over time if consistently followed. The practices also enhance communication between geographically dispersed staff tasked with managing the same platforms by regularly creating snapshots of the configuration state and documenting who did what changes and why.

The text was modified to remove a link to Demonstration of Trac Issue Tickets on December 30th, 2010.

The text was modified to remove a link to http://gentoo-wiki.com/MAN_emerge_1 on January 19th, 2011.

The text was modified to remove a link to http://gentoo-wiki.com/MAN_mount_8 on January 19th, 2011.

The text was modified to remove a link to http://gentoo-wiki.com/MAN_emerge#lbAN on January 19th, 2011.

The text was modified to remove a link to http://trac.edgewall.org/changeset?new=trunk%2Fhtdocs%2Fcss%2Ftrac.css%404501&old=trunk%2Fhtdocs%2Fcss%2Ftrac.css%404390 on January 19th, 2011.

OpenLDAP with a Go Daddy “Turbo SSL Secure Certificate”

Peter Murray — Sat, 09 Sep 2006 03:16:23 +0000

Okay — this seemed like a lot harder than it should have been. At the very least, it took piecing together information from a number of places in order to make it happen. The goal is to use a Go Daddy Turbo SSL Secure Certificate (the $19.95/year one) to secure an OpenLDAP server. On the surface, this shouldn’t be so hard. The tricky part comes because the requested SSL cert is not signed by a recognized Certificate Authority root; instead, Go Daddy uses an intermediary certificate and the tricky part is making sure the whole chain of SSL certificates line up properly. There is a wealth of documentation for using intermediary certificates with web servers, but I found very little for OpenLDAP servers. I hope by posting this into the blogosphere you will find it useful someday, too.

Environment

The servers are running the Gentoo distribution of Linux. The critical bits out of portage are OpenLDAP (version 2.3.24-r1), OpenSSL (version 0.9.8c), nss_ldap (version 249), and pam_ldap (version 180). On Monday I’m going to ask OhioLINK’s resident Redhat Fedora Core expert to try the equivalent on that distribution. (I’ve put him through so much trouble already that I hope this process goes smoothly from here on out.) You’ll need to get all of those and their prerequisites installed and configured on your machine. There is a HOWTO LDAPv3 on the Gentoo Wiki and another on the Debian Wiki plus numerous other documents out there to help you get started. When you’ve had enough fun beating your head up against that wall and have got basic LDAP-based account management to work, you can come back here.

The Certificate

I picked the Go Daddy Turbo SSL Secure Certificate because, well, it’s cheap. As their own marketing literature says — why pay a couple hundred dollars for something when Go Daddy will give you the equivalent thing for $19.95? To be completely fair, Go Daddy offers two types of certificates: the Turbo SSL one that we’ll be using and the High-Assurance Secure Certificate. The difference is in the verification process. The former verifies only the domain name and control of that domain name by sending e-mail to the WHOIS administrative contact to confirm that the certificate request is legitimate. The latter is a manual verification process that looks at the domain name and control of that domain name as well as verifies identity of requesting person or company and the authority to make request. The latter is probably overkill for our uses and costs $89.99.

So go through the modestly convoluted process of generating the Certificate Signing Request (CSR), giving Go Daddy your $19.95, requesting the certificate, have the request approved by your DNS zone administrator, receive the e-mail of the signed certificate from Go Daddy, and then come back here.

OpenLDAP’s ‘slapd.conf’ Server Setup

So here is the really tricky part (where “tricky” is defined as the piece that took me the longest to figure out). As I said in the introduction, Go Daddy uses an intermediary certificate to form a chain from one of the highly-trusted root certificates. The key to making this work becomes getting the intermediary certificate into the evaluation chain at the right time so the client can see it an trust the server. It is possible to install the intermediary certificate on all of the clients who might someday make use of our server’s certificate, but we would, ideally, like the server to offer the client the certificate and let the client do all of the cryptology to determine whether the server can be trusted. This section describes what it takes to make that happen.

First, one has to go to the Go Daddy Secure Certificate Services Repository. Many of the directions I found for getting the intermediary certificate working with web servers said to download the intermediate certificate alone (or, as Go Daddy calls it, the sf_issuing.crt file). I found this didn’t work — rather, the “Root Bundle” (or ca_bundle.crt file) is what is needed.

[Updated 20070904T1104 : It looks like Go Daddy changed their certificate chain last month. What you need now is called "gd_bundle.crt" from the Go Daddy certificate repository -- you'll find it under the heading "New Go Daddy Certificate Chain" (at least that is where you'll find it today).]

Then add this to your slapd.conf file:

TLSCipherSuite HIGH:MEDIUM:+SSLv2# Your signed CSR that you got back from Go DaddyTLSCertificateFile /etc/ssl/certs/ldap.ohiolink.crt# The private key file for the certificateTLSCertificateKeyFile /etc/ssl/certs/ldap.ohiolink.key# The "Root Bundle" file from Go Daddy's Certificates RepositoryTLSCACertificateFile /etc/ssl/certs/ca_bundle.crt

Next, move onto the client side. (Your LDAP server also has the client libraries installed — you’ll likely want to start there.)

OpenLDAP’s ‘ldap.conf’ Client Setup

In case you haven’t discovered it by now, there are two — count ‘em, two — ldap.conf files on your box. One is read by tools derived from the OpenLDAP package and the other is for the pam_ldap/nss_ldap combination. And to make things even more interesting — the syntax of the files are not the same! Boy, sometimes I really dislike the profession I’m in…

So let’s start with OpenLDAP’s ldap.conf file; you’ll likely find this in the /etc/openldap directory. (At least that is where you’ll find it with Gentoo — YMMV.) In that file, you’ll want to put these pieces:
[code]
BASE dc=ohiolink,dc=edu
URI ldap://ldap.ohiolink.edu/
TLS_CACERTDIR /etc/ssl/certs
TLS_REQCERT demand
[/code]
You’ll, of course, want to replace the BASE and URI parameters with the ones most appropriate for your installation. I’ve found that third line to be somewhat unexpectedly important, however. The OpenLDAP libraries need to know where to go to find the trusted root certificates, and so you need to specify the path where they exist on your system. These got installed with OpenSSL, which you needed back in “The Certificate” stage when you generated the CSR. Again, these are in /etc/ssl/certs on a typically-configured Gentoo box; you might find them elsewhere in other distributions.

NSS/PAM’s ‘ldap.conf’ Client Setup

This is the other ldap.conf file, and on a Gentoo system you’re likely to find it in the /etc directory. Remember — the file name is the same but the directives are different. You’ll use much of the knowledge from the previous section here…you’ll just need to change the preceding labels:
[code]
suffix "dc=ohiolink,dc=edu"
uri ldap://ldap.ohiolink.edu
sslpath /etc/ssl/certs
ssl start_tls
[/code]
See the similarity? base becomes suffix, tls_cacertdir becomes sslpath, and so forth. There will likely be much more in this file — pam_login_attribute, nss_base_passwd, and more. Follow a more comprehensive set of directions to get those pieces right.

Testing

To test to see if the SSL certificate is really securing the connection, you can use the -ZZ parameter (to force an SSL/TLS interaction with the server) on ldapsearch with the debugging level set in order to see some of the protocol interaction. I find that this command is most instructive:
[code]
ldapsearch -d 9 -ZZ -h ...ldap.server.address.net...
[/code]
You can scroll back and make sure that the SSL/TLS-secured connection was, in fact being used. You can also turn up debugging on the server and look at the server log files to verify the same thing.

Conclusion

So there you go. I hope you find this useful. I also hope that if you find it in error, you’ll let me know. (Although, at the moment, this does seem to be working for us. Perhaps it only works because I have faith that it will work. If so, please be gentle when you tell me I’ve made an error… )

The text was modified to remove a link to http://gentoo-wiki.com/HOWTO_LDAPv3 on January 19th, 2011.

The text was modified to update a link from http://wiki.debian.org/OpenLDAPSetup to http://wiki.debian.org/LDAP/OpenLDAPSetup on January 19th, 2011.