Monitoring tools are to the sysadmin what testing tools are to the developer.

Recently I realized that there need to be more ways to bring both toolsets together. Here’s one, tying the Nagios monitoring toolset to anything that emits the popular Test Anything Protocol.

The sysadmin community loves monitoring tools. Partly because of Tom Limoncelli’s time management book, I’ve been using Nagios for several years now to monitor all sorts of IT hardware and software. It includes features for scheduling check scripts and contact rules (page me during weekdays, page someone else at night), and dashboard views for the visually oriented (curiously unnecessary once you have alerting configured well). I’ve found it takes investment of time and attention to configure all the checks you want, but it’s worth it. Because of its open-source, extensible nature, Nagios is especially good for monitoring weird things that other enterprise monitoring systems aren’t even aware of. There are a lot of books about Nagios available, and I’d recommend them for anyone new to Nagios. I found James Trumbull’s book published by APress particularly useful, though it looks like it might be due for a new edition by now.

The developer community has become increasingly interested in software quality control and test driven development (TDD). I first became interested because of the Perl community’s emphasis on Kwalitee testing ever so long ago. There are even more good books and online resources about testing than there are about monitoring. I have been noticing everywhere though, that Perl’s simple and ancient Test Anything Protocol has become somewhat of a standard, with testing tools in many languages (including JavaScript, PHP, Python, Ruby, Java, C, C++, C#/VB/.NET and database-specific languages) producing it. Everything from low-level unit tests in C to frontend cross-browser functional testing tools like Selenium. And TAP is so simple, it’s easy to wrap a TAP harness around other test frameworks.

One strategy–from the security world–on which sysadmins and developers both agree is enumerating goodness (take note, “antivirus” is Doing It Wrong). Basically, it’s too hard to guess all the myriad ways your technology might fail and then write monitoring or test scripts for them. Instead, focus your monitoring and testing on covering the important functionality of your product.

But at what level of detail should we monitor? When the monitoring system wakes you up at 2 am, which do you want it to say?

1. CRITICAL. No users can log in to http://myapp/login.
2. CRITICAL. The app can’t contact the database.
3. CRITICAL. The database server is down/unpingable.

My preference is “4. All of the above”, because the user-facing effect is sometimes hard to guess from the sysadmin-facing event (and vice versa). Nagios is good at #3 and maybe #2. #1 is more in the realm of functional testing, and your app may already have functional test scripts that could provide this sort of information.

check_tap.pl

A Nagios plugin for consuming Test Anything Protocol. Basically it combines Test::Harness with Nagios::Plugin.

Read, download, or fork check_tap.pl from the Github Gist.

Plugin Documentation (more or less straight from check_tap.pl --help)

check_tap.pl [ -v|--verbose ] [-t <timeout>]
[ -c|--critical=<critical threshold> ]
[ -w|--warning=<warning threshold> ]
[ -s|--script = '</full/path/to/test.t>' ] (Required. multiple OK)
[ -e|--exec = '/full/path/to/runnable ARGS'
[ -l|--lib = '/path/to/perl/libs' ] (Multiple OK)

    check_tap.pl -s /full/path/to/testfoo.pl

    check_tap.pl -s /full/path/to/testfoo.pl -c 2

    check_tap.pl -e '/usr/bin/ruby -w'  -s /full/path/to/testfoo.r

    check_tap.pl -e '/usr/bin/curl -sk' -s 'http://url/to/mytest.php'

    check_tap.pl -e '/usr/bin/cat' -s '/path/to/testoutput.tap'

Installation and Nagios configuration

Save check_tap.pl anywhere that makes sense and the nagios user can access. The default plugin location depends on your distribution. For RHEL and ilk, plugins are in /usr/lib/nagios/plugins/.

In misccommands.cfg:

# runs Perl test script given in $ARG1$
define command {
        command_name    check_tap
        command_line    /usr/lib/nagios/plugins/check_tap.pl -v \
               -s $ARG1$ -w $ARG2$ -c $ARG3$
}
 
# gets TAP output from the full URL in $ARG1$
define command {
        command_name    check_tap_remote_url
        command_line    /usr/lib/nagios/plugins/check_tap.pl -v \
               -e '/usr/bin/curl -sk' -s $ARG1$ \
               -w $ARG2$ -c $ARG3$
}
 
# gets TAP output from the relative URL in $ARG1$ at host $HOSTADDRESS$
define command {
        command_name    check_tap_remote_host
        command_line    /usr/lib/nagios/plugins/check_tap.pl -v \
              -e '/usr/bin/curl -sk' \
              -s http://$HOSTADDRESS$$ARG1$ \
              -w $ARG2$ -c $ARG3$
}

You can also use NRPE for *nix or NSCLient++/nscp or NC_Net for Windows (you’ll also need Perl, like Strawberry Perl) to run check_tap.pl on a machine other than the Nagios server. I’ll leave that as an exercise for the reader, or maybe a future blog post.

In services.cfg:

define service {
  use                  generic-service
  check_command        check_tap!/path/to/my/test.t!0!0
  service_description  Local test script on Nagios server
}
 
define service {
  use                  generic-service
  check_command        check_tap_remote_url!http://webhost99/nagios/mytest.php!0!0
  service_description  Remote test script accessible by URL
}
 
define service {
  use                  generic-service
  host_name            webhost1, webhost2
  check_command        check_tap_remote_host!/nagios/mytest.php!0!0
  service_description  Remote test script
}

Host-based security for URL-accessible test scripts

It would be good to limit access to the URL-accessible test scripts to your Nagios server and development/admin network. So for Apache, .htaccess or httpd.conf:

Order deny,allow
Deny from all
Allow from nagioshost.example.com
Allow from developers.example.com

For IIS you can click on stuff for the same result or use the deny element in your web.config file. For other web servers, RTFM.

Doughnuts for Developers

Wow! Now I can use Nagios’s monitoring, alerting, performance logging, acknowledging, scheduling, dashboarding, and thresholding features for my unit and functional tests! I can run them with different rules in build and production! I can detect random and senseless acts of system administration! I can detect new bugs as soon as I write them! I can hook Nagios up to the sprinkler system to put a damper on that hotheaded programmer in the next cube! I can write frontend functional tests with Selenium or AutoIt or AppleScript and have Nagios alert (the sysadmins of course) when any of my app’s core functionality breaks!!!

There are plenty of other test harnesses out there, but Nagios has some big advantages, especially for monitoring production systems.

Shortcuts for Sysadmins

Two last things which are more good news for sysadmins:

Custom test scripts for things Nagios won’t easily check

Writing your own Nagios plugins is a little bit hard, even with the example plugin I worked on ever so long ago. Writing TAP test scripts, on the other hand, is easy! So, after you’ve set up Nagios monitoring for all the low-hanging fruit like hardware utilization and network availability, write a test script for some of the harder to monitor signs of enumerable goodness. Here’s an example:

#!/usr/bin/perl
use warnings; use strict;
 
# This allows the script to run as a CGI or on the command line.
# We have to output the header in a BEGIN block or Test::Simple will
#   output the plan too soon.
BEGIN {
    if ($ENV{REQUEST_METHOD}) {
        use CGI qw(header);
        print header("text/plain");
    }
}
 
use Test::Simple tests=>4;
use Test::File;
 
# These use Test::File to test file permissions and size.
# See http://search.cpan.org/perldoc?Test::File
file_writeable_ok "path/to/cache";  
file_not_writeable_ok "path/to/index.html"; 
my $backup_file = "/usr/local/backups/myapp-backup.tar.bz2";
file_min_size_ok $backup_file, 911377;
 
# -M is a file test operator returning the file's last modifed age in days.
# See http://perldoc.perl.org/functions/-X.html
ok -M $backup_file < 1, "Backup file is newer than 1 day old";

Just run that script as a CGI or with NRPE etc. and you’ve got instant monitoring of things like backup success, which is otherwise kind of hard to hook in to Nagios. You could get even fancier with checksums or whatever you want.

See Test::Tutorial for more. Or look for TAP tools for your favorite language; they’re probably out there.

Tolerating ambiguity

In some cases, a certain amount of failure is acceptable. I’ve been monitoring connectivity between crucial hosts with a test script. I don’t want to be bothered by this check if one of our Citrix VMs isn’t available to the gateway server for a while, but it’s a problem if they’re ALL inaccessible because of a firewall issue or something. The configurable warning/critical thresholds on check_tap.pl allow me to define how much aggregate failure is worth getting excited about–something that’s hard to do with vanilla Nagios configuration.

Here’s the gist of my test script. ping_ok() and service_ok() come from a module I wrote 50 years ago to check basic connectivity/responsiveness with Net::Ping.

diag "Checking Citrix farm connectivity from DMZ\n";
my @stas = qw(
   citrixdc01.mydomain.com
   citrixdc02.mydomain.com
);
foreach (@stas) {
    ping_ok($_, 'http');	
    service_ok($_, 'http', "XML service on $_ is responding in some way" );
}
 
 
 
my @citrix_farm = qw(
   citrixps01.mydomain.com
   citrixps02.mydomain.com
   ...
   citrixps29.mydomain.com
   citrixps30.mydomain.com
);
foreach (@stas, @citrix_farm) {
    service_ok($_, '1494', "ICA service on $_ is responding in some way" );
}

I can just use the “warning” and “critical” arguments to check_tap.pl to set my thresholds for how many inaccessible servers I want to tolerate.

So there you go. Sysadmins and developers rejoice!

Salient errors:

String.cpp: In member function ‘off_t String::toOffset()’:
String.cpp:167: warning: format ‘%d’ expects type ‘int*’, but argument 3 has type ‘off_t*’
In file included from HTTPHeader.hpp:38,
                 from DownloadManager.hpp:30,
                 from OptionContainer.hpp:27,
                 from ConnectionHandler.hpp:27,
                 from ConnectionHandler.cpp:25:
RegExp.hpp:31:23: error: pcreposix.h: No such file or directory
In file included from HTTPHeader.hpp:38,
                 from DownloadManager.hpp:30,
                 from OptionContainer.hpp:27,
                 from ConnectionHandler.hpp:27,
                 from ConnectionHandler.cpp:25:
RegExp.hpp:82: error: ‘regex_t’ does not name a type
make[2]: *** [dansguardian-ConnectionHandler.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f .deps/dansguardian-String.Tpo .deps/dansguardian-String.Po
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

And a wild goose chase: don’t alter your PCRE_LIBS environment variable or you’ll have trouble like this:

ld: in /Developer/SDKs/MacOSX10.5.sdk/usr/include/php/ext/pcre/pcrelib, can't map file, errno=22

What worked:

 
# this is the main thing-- help it find pcreposix.h !
export CPPFLAGS=-I/Developer/SDKs/MacOSX10.5.sdk/usr/include/php/ext/pcre/pcrelib
 
# only the last two are my preferences, 
# the others are from the INSTALL doc
 
./configure --localstatedir=/var  \
         --mandir=/usr/share/man/  \
         --bindir=/usr/local/sbin/ \
         --with-logdir=/usr/local/dansguardian/logs/ \
         --enable-email=yes
 
make -j 2
sudo make install

starting at boot with daemonic

I got squid using Fink, which uses daemonic for startup/init scripts. So hopefully I can use it to start dansguardian at boot too.

I copied the squid XML file and made this one at /sw/etc/daemons/dansguardian.xml:

<service>
<description>Dan's Guardian</description>
<message>Dan's Guardian content filter</message>
 
<daemon name="dansguardian">
<executable checkexit="true">/usr/local/sbin/dansguardian</executable>
<configfile>/usr/local/etc/dansguardian/dansguardian.conf</configfile>
<pidfile>/var/run/dansguardian.pid</pidfile>
</daemon>
 
</service>

Now all I have to do is:

$ sudo daemonic enable dansguardian

Looks like it built some nice OS-X-y startup scripts for me in /Library/StartupItems/daemonic-dansguardian. Here goes rebooting…

We need a quick-and-dirty LDAP server with basically a list of usernames and passwords to point Cisco ACS gear at, in order to provide people with limited-time authentication tokens to a wireless network. I need to populate that with an HL7 interface in Perl and make a web app UI frontend (preferably using symfony). The latter two interfaces are well established around here with MySQL, so I am trying to use OpenLDAP’s SQL backend to make that happen naturally.

Simplifications

Unlike other similar implementations out there, I have smaller goals:

• The database will be updated/written by the HL7 interface and web interface. The LDAP tools don’t need to write to it.
• All my user data should fit nicely into two tables (users and groups… and another table to relate many-to-many), and two Objectclasses in LDAPland.

Resources

These were unexpectedly hard to Google up, which is partly why I’m documenting them here for Posterity.

• Zytrax has an open source book about LDAP entitled LDAP for Rocket Scientists, which has an excellent chapter about LDAP concepts, which is nice since I don’t really understand LDAP like I do the other technologies involved.
• Section “10.10.2. back-sql Configuration” of the OpenLDAP manual
• The slapd-sql man page is indispensible. See especially the “METAINFORMATION USED” section.
• The README that comes with the back-sql samples
• The samples themselves (either unpack servers/slapd/back-sql/rdbms_depend/mysql from the source tarball or browse them, but you’ll probably want them unpacked so you can feed the schema to the mysql client. MOST OF WHAT YOU NEED TO LEARN is demonstrated in the samples.
• This 4-year-old blog article at/by “Flat Mountain” is sketchy but an improvement over the documents above!
• Albert Lash at DocuNext has a 2-year-old post similar to this one with another list of fine references!
• This HOWTO for OpenLDAP and Postgresql by Gilles Darold is far superior than the other articles, but needs adaptation of course for MySQL
• Likewise, here’s a good article for doing the same thing with Oracle/MSSQL
• And here are some extended notes from someone who did it with Oracle, including another explanation of the data mapping part.

I. Install Stuff

I’m using RHEL5 on a virtual machine. Your package system may vary. You may in fact have to compile from source to get SQL support in LDAP.

$ sudo yum install openldap openldap-clients openldap-servers openldap-devel openldap-servers-sql

II. Get and unpack the source code for the MySQL samples

1. Download the source tarball to your machine
2. Unpack it

   tar zxf openldap-stable-20080813.tgz

III. Create the database and tables

Make sure the mysql server is running of course. We’re assuming it’s on the same host as the LDAP server.

Create the database (my_db_name) and a password-having user (my_mysql_user) with all privileges to that database (I recommend the MySQL Administrator GUI for this, strangely enough since I usually dislike clicking on stuff). You should be able to connect to your database like this now:

$ mysql -umy_mysql_user -pxxxxxxxxxxxxx  my_db_name

Build the tables that configure how OpenLDAP talks to the database.

1. cd into servers/slapd/back-sql/rdbms_depend/mysql from the unpacked openldap source
2. Feed backsql_create.sql to the ‘mysql’ client

   $ mysql -umy_mysql_user -pxxxxxxxxxxxxx  my_db_name < backsql_create.sql

IV. Hack the basic config files

a. slapd.conf

Basically I’m starting from the slapd.conf in the rdbms_depend/mysql sample (see above), but folding in some RedHatese file locations from the distributed slapd.conf.

I define an adminstrative user with the rootdn and rootpw directives. Use slappasswd to generate the hashed password:

$ slappasswd -h {crypt}

and type in the password. It will spit out the string you need, which is prefixed by the algorithm in curly braces.

# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
 
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args
# Timeout in seconds, 0 = never
idletimeout     30
threads         32
# Debuging level, 0 = none
loglevel        32
 
# THIS IS IMPORTANT-- without it you will get "<database> failed init (sql)!"
# Load dynamic backend modules:
modulepath    /usr/lib/openldap
# modules available in openldap-servers-sql RPM package:
moduleload back_sql.la
 
 
#######################################################################
# SQL Database Definitions
#######################################################################
 
database        sql
suffix          "ou=Junk,ou=AK,DC=mycompany,DC=com"
rootdn          "cn=root,ou=Users,ou=Junk,ou=AK,DC=,mycompany,DC=com"
rootpw          {CRYPT}xxxxxxxxxxxx
 
#  The name of the ODBC datasource (from odbc.ini,
#     not necessarily the database instance) to use.
dbname          my_database
dbuser          my_database_user
dbpasswd        xxxxxxxxxxxxxxxx
 
# this is important because my simple view for the ldap_entries table
# has no 'organization' object.  See `man slapd-sql`.
baseObject
 
subtree_cond    "ldap_entries.dn LIKE CONCAT('%',?)"
insentry_stmt   "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)"
has_ldapinfo_dn_ru      no
 
 
#######################################################################
# Access Control
#    see http://www.openldap.org/doc/admin24/access-control.html
#    and `man slapd.access`
#######################################################################
 
# Here we define who can see which parts of the directory
 
# Hide the password attribute (except for the root user of course) but
#   allow authentication against it
access to attrs=userPassword
        by anonymous auth
        by * none
 
# don't allow anonymous access
# allow authenticated users to see their own entry
access to *
        by self read
        by * none

I started without the Access Control section and added it after I had things basically working.

b. ODBC config files

In my case they are in /etc/odbc.ini and /etc/odbcinst.ini already existed and just needed a MySQL section added to odbcinst.ini and a section for this particular database in odbc.ini, but I had to get the paths right for Red Hat. See the MySQL section of step 2 of the samples README document

/etc/odbcinst.ini:

# Driver from the MyODBC package
# Setup from the unixODBC package
[MySQL]
Description     = ODBC for MySQL
Driver          = /usr/lib/libmyodbc3.so  # note, filename includes a 3, differs from docs
Setup           = /usr/lib/libodbcmyS.so
FileUsage       = 1

/etc/odbc.ini

[my_database]
Description         = my database
Driver              = MySQL
Trace               = No
Database            = my_db_name
Servername          = localhost
UserName            = my_database_user
Password            = xxxxxxxxxxxxxxxxx
ReadOnly            = No
RowVersioning       = No
ShowSystemTables    = No
ShowOidColumn       = No
FakeOidIndex        = No
ConnSettings        =
SOCKET              = /var/lib/mysql/mysql.sock

(OK, here’s where I dinked with the example database and read lots of examples and stuff, but hopefully you can skip that because of this excellent documentation )

V. Create and populate your user and group tables

These are my basic tables of users and groups:

CREATE TABLE my_user (
  id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  username VARCHAR(45) NOT NULL,
  password VARCHAR(45) NOT NULL,
  first_name VARCHAR(45) DEFAULT NULL,
  last_name VARCHAR(45) DEFAULT NULL,
  PRIMARY KEY  (id,username)
);
 
CREATE TABLE my_group (
  id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(45) NOT NULL,
  PRIMARY KEY  (id)
);
 
CREATE TABLE my_group_member (
  -- unique id isn't necessary but easier for symfony
  id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  my_user_id INT(10) UNSIGNED NOT NULL,
  my_group_id VARCHAR(45) NOT NULL,
  PRIMARY KEY  (id),
  UNIQUE KEY uniquepair (my_user_id,my_group_id)
);

You’ll need to populate the tables with a user or two and at least one group, of course.

VI. Insert the special configuration rows

I entered these data sets using the MySQL Administrator GUI. The most helpful explanation was in the “METAINFORMATION USED” section of the slapd-sql man page.

Basically, the ldap_* tables show the SQL backend how to map the database tables onto LDAP objects. This is a nice reference to the common LDAP object schemas. That’s important because you can only map your database fields to fields in the schema for the objectClass you’re using (unless you want to start making your own schema, which is beyond my scope here). In my case I’m using inetOrgPerson, which inherits from organizationalPerson, which inherits from Person, and for groups, groupOfUniqueNames.

The ldap_entry_objclasses table needs one row for each objectClass we’re using:

The ldap_oc_mappings table also has a row for each objectClass, and it shows the sql backend how to find objects corresponding to those object classes.

The ldap_attr_mappings table is the most complex part. Basically you’re showing the sql backend how to build queries that map the database columns onto LDAP attributes.

Create a view for the DNs in ldap_entries

I’m going to use the username field in my DN instead of the common name (CN) in most examples, because it’s more guaranteed to be unique, and it is apparently OK to do so.

DROP TABLE ldap_entries;
 
CREATE VIEW ldap_entries AS
  SELECT 
    -- differentiate id spaces here 
    (100000 + my_user.id) AS id,
 
    -- calculate a DN for each user
    ucase(concat(
     'uid=', my_user.username, 
     ',ou=Users,ou=Junk,ou=AK,DC=mycompany,DC=com'
    )) AS dn, 
 
    -- the id of the inetOrgUser objectClass in ldap_entry_objclasses
    1 AS oc_map_id,    
 
    -- zero for every row 
    -- (see baseObject in the `slapd-sql` man page)
    0 AS parent,
 
    -- the real id in the user table
    my_user.id AS keyval 
 
  FROM
    my_user 
 
UNION 
 
  SELECT 
    -- a different id space
    (200000 + my_group.id) AS id,
 
    -- calculate a DN for each object in our group table 
    ucase(concat(
    'cn=',my_group.name,
     ',ou=Users,ou=Junk,ou=AK,DC=mycompany,DC=com'
    )) AS dn
 
    -- the id of groupOfUniqueNames in ldap_entry_objclasses
    2 AS  oc_map_id,
 
    -- like above
    0 AS parent,
    my_group.id AS id 
 
  FROM 
    my_group

VII. Test and stuff

Launch the Slap daemon

It’s nice to launch slapd in debug mode in one terminal. This is pretty verbose and will hopefully tell you if you’ve got something wrong in your mapping tables or anything:

sudo /usr/sbin/slapd -d 5

Test connectivity and data with an LDAP client

Hint: it would help to LEARN HOW TO USE ldapsearch correctly.

Connect anonymously and spit out all the LDAP data (if ACL allows it– by slapd.conf above allows anonymous connections but won’t show any of the data):

ldapsearch -x -s sub -b "ou=Junk,ou=AK,DC=mycompany,DC=com" "(objectClass=*)"

Connect as root (the special account defined in slapd.conf) and show all the data in the directory:

ldapsearch -x -D uid=root,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM -w xxxxxxxxx -s sub -b "ou=Junk,ou=AK,DC=mycompany,DC=com" "(objectClass=*)"

Here’s an example of what it shows me:

# extended LDIF
#
# LDAPv3
# base <ou=Junk,ou=AK,DC=mycompany,DC=com> with scope subtree
# filter: (objectClass=*)
# requesting: ALL
#
 
# Junk, AK, mycompany.com
dn: ou=Junk,ou=AK,dc=mycompany,dc=com
objectClass: extensibleObject
description: builtin baseObject for back-sql
description: all entries mapped in the "ldap_entries" table
description: must have "0" in the "parent" column
ou: Junk
 
# TESTUSER, USERS, JUNK, AK, MYCOMPANY.COM
dn: uid=TESTUSER,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM
objectClass: inetOrgPerson
cn: test user
ou: guest
sn: user
uid: testuser
givenName: test
userPassword:: dGVzdHBhc3M=
 
# 1234567890, USERS, JUNK, AK, MYCOMPANY.COM
dn: uid=1234567890,ou=USERS,ou=JUNK,ou=AK,DC=MYCOMPANY,DC=COM
objectClass: inetOrgPerson
cn: test2 user2
ou: guest
sn: user2
uid: 1234567890
givenName: test2
userPassword:: MTIzNDU2Nzg5MA==
 
...
 
# VALIDUSERS, GROUPS, JUNK, AK, MYCOMPANY.COM
dn: cn=VALIDUSERS,ou=GROUPS,ou=JUNK,ou=AK,DC=MYCOMPANY,DC=COM
objectClass: groupOfUniqueNames
cn: validUsers
uniqueMember: uid=1234567890,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM
...
uniqueMember: uid=TESTUSER,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM
 
# search result
search: 2
result: 0 Success
 
# numResponses: 8
# numEntries: 7

Connect as a valid user and ask for everything, but according to my ACLs the user can only see itself:

ldapsearch -x -D uid=TESTUSER,ou=USERS,OU=JUNK,OU=AK,DC=MYCOMPANY,DC=COM -w testpass -s sub -b "ou=Junk,ou=AK,DC=mycompany,DC=com" "(objectClass=*)"

Additional Considerations

chkconfig is the Red Hat tool for managing init scripts– here’s how to make sure the slapd starts at boot time.

$ sudo chkconfig --add ldap
$ sudo chkconfig ldap on

Ah, Mr. Flat Mountain reminds,

9) Ports for the Firewall LDAP runs on port 389/tcp by default and LDAP over SSL is 636/tcp.

Securing communication between the LDAP client and OpenLDAP server with SSL/TLS is beyond my scope here, but it seems to be much better documented.

Good luck!