Symfony’s production environments don’t create logs, but the development environments do, and for one project I had several batch jobs logging to the myproject/log directory. (Troubleshooting batch jobs without logs is just crazy).

I was going to use symfony log:rotate, but

• I would need one cron job for each log
• I had permission issues since some of the logs belong to apache and others to root
• Everything else on the machine, pretty much, is managed with the standard Linux utility logrotate. Logrotate has been around for about 174 Linux Years, and is common to most distributions.

So here’s how I did it using with logrotate.

1. WARNING: You might want to make a convenient copy of your log directory before you do this. I accidently wiped all the logs out while messing with it.
2. Create a file config/myproject.logrotate. Very simple, I just want it to use the same rotation schedule specified for the whole machine in /etc/logrotate.conf

   /path/to/myproject/log/*.log {
           weekly
           rotate 4
   }

3. Check that it will do stuff by running it with the debug flag

   logrotate -df config/badge.logrotate

4. Make a symlink to it in /etc/logrotate.d

   ln -s /path/to/myproject/config/myproject.logrotate  /etc/logrotate.d/myproject

5. Run it the first time manually to rotate your logs and make sure it does the right thing!

   sudo logrotate -fv /etc/logrotate.d/myproject

CONCEPTS

Problem 1: Brute force SSH attackers

I recently made a Linux machine accessible by port 22 from the Internet, so I could remotely administer it with SSH. Within a day or two, there were hosts from all over the Internet trying to log in using random usernames (‘root’, ‘dave’, ‘mysql’, ‘neo’) and random passwords.

Problem 2: Weak system passwords

System passwords are becoming easier to guess by brute force every time a new processor comes out. It doesn’t matter how complicated your alphabet soup is, it’s just not long enough, or won’t be long enough eventually. The bad guys also have botnets full of machines and all the time in the world.

Working around problems 1 and 2: Key authentication

An SSH key is complex (random) and much, much longer than your password (see Wikipedia for more details about how public-key cryptography works). You store the private part of your key securely on your client machine, and tell the server to trust only the public key that goes with it. BUT, you should really use a nice, long, complex passphrase to lock up your private key so that someone who gains access to it can’t get free access to all your servers, which leads to

Problem 3: I’m too lazy to unlock my inconvenient SSH key all the time

I log in to different machines all the time, from a bunch of different workstations. But, I have a long passphrase on my SSH key. Too long to type every time, especially if I’m just looking at something or transferring a file or two.

Solution to problem 3: A key agent

An SSH key agent lets you unlock your key and load it into memory once, and then automatically uses it to get you in to all your servers. SUPER convenient.

Problem 4: It’s confusing

I tried to explain it to a friend recently and found nowhere on the internets that explained it all in one place.

Coming up: detailed instructions for getting started with SSH keys and using a key agent on Mac OS X (command line), Windows (PuTTY and Cygwin commandline ssh), and Linux/Unix (command line).

HOW TO START USING SSH KEYS

References:

• PuTTY manual chapter 8 and chapter 9
• section 2.4 of the O’Reilly SSH book by Barrett/Silverman
• man ssh_config
• man ssh-agent

Generate your key with a command-line (Open)SSH client (Cygwin, Mac OS X, Linux)

I’m going to start with this client, because the command-line OpenSSH is the common denominator on all the OSes I use.

1. Write down a nice long, complex, memorable passphrase that you’re capable of typing reliably, and store it in a safe place. You probably won’t need it every day (unless you reboot a lot), so make sure you can remember and type it. Security expert Bruce Schneier suggests a scrap of paper in your wallet is a pretty good place.

2. Generate a private key with ssh-keygen from your client machine’s command line:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/myusername/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):     # use yours from step 1
Enter same passphrase again:
Your identification has been saved in /home/myusername/.ssh/id_rsa.
Your public key has been saved in /home/myusername/.ssh/id_rsa.pub.
The key fingerprint is:
9a:89:9c:6b:87:a7:e8:93:9a:f5:f7:35:bf:23:87:c6 myusername@myhostname

1. The file permissions of your new .ssh directory and the files in it (except maybe your public key) should be very restrictive, allowing only you to read them. But just in case, reset them restrictively:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
chmod 644 ~/.ssh/id_rsa.pub

1. You need to append your public key to ~/.ssh/authorized_keys on each of your servers:
   • if you don’t have an authorized_keys file in your ~/.ssh directory, just copy your public key to it on each server:

scp -r ~/.ssh/id_rsa.pub  myserver:.ssh/authorized_keys

• if you already have one, you’ll need to append your key to it. Use a text editor and paste, copy and paste, or, courtesy of CodeSnippets,

cat .ssh/id_dsa.pub | ssh user@domain.tld 'cat >> .ssh/authorized_keys'

1. Test and make sure it works! When you ssh to the server, it should prompt you for your passphrase to unlock your private key, and then you should successfully connect. Using the -d flag to ssh gives you verbose debugging information which is usually useful.

$ ssh -v myserver
... # copious debug information about which keys or 
... # authentication methods ssh is trying ]
Enter passphrase for key '~/.ssh/id_rsa':
... # here's where you type your passphrase correctly
... # more debugging
debug1: Entering interactive session.
Last login: Thu May 21 14:30:31 2009 from 10.0.0.2

1. I like to turn on agent forwarding by adding this line to ~/.ssh/config file on each server. This allows you to ssh from server A to another server B that trusts your key, using the agent on your client machine to pass your key through. ForwardAgent yes

2. If all the users on the server will be using keys from now on, it’s a good idea to turn off password authentication for the whole server, in sshd_config, which is usually located in /etc/: PasswordAuthentication no Unfortunately, I can’t figure out how to lock one account on the server from using password authentication. You can put that line in your ~/.ssh/config file, but it only affects your use of ssh from that account, not to it.

Or, generate your key with PuTTY on Windows:

PuTTY is rock-solid terminal and SSH software for Windows. I usually generate my key with the command-line OpenSSH tools and then import it to PuTTY, but here’s how you do it the other way around:

1. Install the latest version of the whole PuTTY package. At the time of this writing, the PuTTY author’s site has been inaccessible for a while, but there are mirrors available for downloading the software.

2. Generate an RSA key with puttygen.exe, using a good passphrase (see instructions in the PuTTY manual chapter 8)

   

   Generating a key with puttygen.exe

3. Save the private key somewhere using the ‘Save private key’ button, like maybe in C:\Documents and Settings\yourusername\.ssh\puttyprivkey to be compatible with command-line SSH tools. Save the public key somewhere too (though you will paste it, below).

4. Make the file permissions of that directory and the files in it very restrictive (only you should have access).

5. On one server, edit .ssh/authorized_keys in your home directory (creating it if it doesn’t exist yet), and paste your public key from puttygen in there

6. Test that it works! Tell PuTTY to try key authentication instead of password authentication by setting your private key under Connection->SSH->Auth in the connection settings:

   

   Tell PuTTY to use your key

7. Copy the authorized_keys file and/or the whole .ssh directory to each other server. Eg on the first server, scp -r .ssh myotherserver:

8. Turn on agent forwarding (and “try to use Pageant”… see screenshot above) for each ssh session config in PuTTY in the Connection->SSH->Auth pane (this lets you ssh from server A to another server using the agent on your client machine)

9. Put your username in the “Auto-login username” field under Connection->Data for each saved PuTTY session:

   

   Don't forget to fill in the Auto-login username field for each saved PuTTY session.

Using your PuTTY key with command-line ssh client (Cygwin, Mac OS X, Linux):

If you want to use the key you just generated with puttygen.exe with another ssh client (eg cygwin commandline ssh), export your private key from puttygen and store it in your .ssh dir (ssh looks by default for .ssh/id_rsa but these instructions let you specify another name), and put these lines in your .ssh/config file:

ForwardAgent yes
IdentityFile ~/.ssh/id_rsa_putty_priv.openssh

( i.e., the filename of your exported private key )

To change your ssh key password

Load it in puttygen and change the password, save and export it for your other ssh client(s) if necessary

Using a different key from home or another machine or whatever

You can copy your private key to several machines, or you can generate a new key on each and append the public key to the .ssh/authorized_keys file on the server. Think about how much you want to expose/replace if something gets compromised.

In my case, I use one private key on all my client computers at work, one on my home computers, and one on my Palm handheld. That way if one of my client computers is lost, stolen or compromised, I can disallow that key but keep the others.

USE A KEY AGENT TO KEEP YOUR KEYS HANDY

So far, we’ve made SSH more secure, but my key passphrase is at least as much of a pain as using my password — in fact, more so because it’s about twice as long.

Using an SSH Key Agent offers a killer mix of security and convenience. When you open the agent and load your keys, you can unlock them and they’re held unlocked in memory. This lets you open connections all day without having to type your password or passphrase. NOTE WELL, lock your machine when it is unattended if you have an agent running; otherwise anyone who walks up to it can conceivably log in to any of the servers you’ve configured to trust your key.

To use PuTTY’s agent “Pageant” on Windows:

1. Launch pageant.exe, PuTTY’s ssh agent, right-click it in the system tray, and add your private key.

Now you can log into all your servers conveniently and get from server to server using agent forwarding.

You may want to convince pageant.exe to run at login. See Chapter 9 of the PuTTY manual.

I just made a shortcut to pageant and edited the Target to load the key and launch PuTTY at startup thusly: "C:\Program Files\putty\pageant.exe" "C:\Documents and Settings\myusername.ssh\puttyprivkey.ppk" -c "C:\Program Files\PuTTY\putty.exe"

To run an agent with the command-line OpenSSH client:

This applies to Linux, Mac OS X, and Cygwin.

Basically, add this line to your .profile file in your home directory, to start the agent whenever you open a shell:

eval `ssh-agent -s`

Then, before you ssh to anything in that terminal, use the ssh-add command (if your private key in openssh format is named .ssh/id_rsa) or ssh-add ~/.ssh/puttyprivkey.openssh if you’ve got a weirdly named one you made with puttygen.exe, above.

$ ssh-add
Enter passphrase for /cygdrive/c/Documents and Settings/myusername/.ssh/id_rsa:
Identity added: /cygdrive/c/Documents and Settings/myusername/.ssh/id_rsa (/cygdrive/c/Documents and Settings/myusername/.ssh/id_rsa)

ssh-add -l (ell) shows which keys the agent is currently holding.

$ ssh-add -l
9a:89:9c:6b:87:a7:e8:93:9a:f5:f7:35:bf:23:87:c6 /cygdrive/c/Documents and Settings/myusername/.ssh/id_rsa (RSA)

Making it nicer in with keychain

The keychain utility you can get with Cygwin (and some Linuxes) is also nice. I put this line in my .bashrc so that every Cygwin shell either starts the ssh agent or connects to the already running one.

eval `keychain --eval -q -Q --noask`

Then I can use ssh-add (see above) when I want to load my keyring, and all my open Cygwin shells get it, until I log out or restart Windows.

Running an agent on Mac OS X

In Leopard (Mac OS X 10.5, released in October 2007), the SSH Agent is integrated into the OS, so if you’ve generated your keys with ssh-keygen as above and they live in ~/.ssh/id_rsa and id_rsa.pub, you will get prompted to unlock your key the first time you try to ssh or scp anywhere:

This dialog box prompts you to unlock your key and/or start the agent.

The “Remember password in my keychain” checkbox makes it keep an ssh agent running. It works great.

For older versions of Mac OS, you want SSHKeychain. It also works with the Apple Keychain, to remember your key’s passphrase.

Both solutions work seamlessly for all the OpenSSH tools (ssh, sftp, scp, etc) in all your terminals.

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!

It’s annoying how much harder this is than the MySQL driver…

1. Download these RPMs from Oracle’s Instant Client for Linux page:Instant Client Package – Basic: All files required to run OCI, OCCI, and JDBC-OCI applications Instant Client Package – SDK: Additional header files and an example makefile for developing Oracle applications with Instant Client [just for future fun] Instant Client Package – ODBC: Additional libraries for enabling ODBC applications
2. Installify them,

   $ sudo rpm -ivh oracle-instantclient-*.rpm

3. Get DBD::Oracle

   sudo cpan

   cpan> look DBD::Oracle

4. Look at README.linux.txt
5. Set up the environment

   export ORACLE_HOME=/usr/lib/oracle/11.1.0.1/client/lib
   export LD_LIBRARY_PATH=$ORACLE_HOME
   export LIBPATH=$ORACLE_HOME
   
   export ORACLE_DSN="DBI:Oracle:host=myhost;sid=MYINSTANCE"  # remember to quote the ;
   export ORACLE_USERID=myusername/mypassword

6. I had to patch the Makefile.PL (sent changes to the maintainer) to find the header files with a longer “client_version_full”:

   # diff -u Makefile.PL Makefile.PL.dist
   --- Makefile.PL 2008-07-31 10:53:00.253634000 -0800
   +++ Makefile.PL.dist    2008-07-31 10:51:49.327631000 -0800
   @@ -1538,7 +1538,7 @@
        if (!$client_version_full) {
           print "I'm having trouble finding your Oracle version number... trying harder\n"
               unless $force_version;
   -       if ( $OH =~ m![^\d\.]((?:8|9|1\d)\.\d+\.\d+<strong>(\.\d+)?</strong>)! ) { #decode it from $OH if possible
   +       if ( $OH =~ m![^\d\.]((?:8|9|1\d)\.\d+\.\d+)! ) { #decode it from $OH if possible
               $client_version_full = $1;
           }
           elsif ( "$OH/" =~ m!\D(8|9|10)(\d)(\d?)\D!) { # scary but handy

7. Install normally:

   perl Makefile.PL
   make
   make test # a few minor failures
   make install