I ran into this problem with several perl scripts using CGI::Application::Plugin::Session. I had just upgraded a database server from PostgreSQL 8.3 to 9.1. The scripts could connect to the but would report errors like the following:

	Error executing class callback in prerun stage: No session object!
	This module depends on CGI::Application::Plugin::Session!
	(or you need to use the -dont_use_session config parameter) at ...

It turns out that the culprit was the new hex output format used by PostgreSQL 9.x. CGI::Session was unable to decode the resulting data and would fail to load existing sessions.

The fix is easy. Simply use the following command to set the bytea output format for a given database:

	ALTER DATABASE database SET bytea_output = 'escape';

Additional details can be found in the Client Connection Defaults section of the PostgreSQL documentation.

Launching the Console application would result in a continuous stream of Error: failed to register for new message notifications messages.

To fix this I just wrote up a quick perl script that scanned for apple-generateduid attributes in LDAP that were not up-cased and the issues vanished.

From: https://www.dns-oarc.net/oarc/services/porttest

$ dig @4.2.2.3 +short porttest.dns-oarc.net TXT

Replacing 4.2.2.3 with the IP address of your DNS server(s).

To get around this problem one can install SSL certificates that employ the subjectAltName extension.

To be deployed properly you will need to either be running your own certificate authority (beyond the scope of this document) or using commercially signed certificates. If you are purchasing certificates you should check with your CA first to see if they are willing to sign certificate requests that employ the subjectAltName extension.

Generating the Certificate Signing Request (CSR)

First edit the openss.cnf file (location may vary depending on OS) and add the v3_req extension. Locate the [ req ] section and add

req_extensions = v3_req

Next find the [ v3_req ] section and add a subjectAltName line containing the appropriate DNS names (in this case I will be using server1.example.com, ldap-1.example.com and directory.example.com):

subjectAltName = “DNS:server1.example.com, DNS:ldap-1.example.com, DNS: directory.example.com”

Generate a Private Key

To generate a CSR we need a private key, generated with the following command. This file should never be world readable and needs to be carefully protected.

# ( umask 077; openssl genrsa 2048 > server1-ldap-key.pem )

Generate the CSR

# openssl req -nodes -new -key server1-ldap-key.pem -out server1-ldap-req.pem

Answer the question prompts. When prompted for your Common Name enter the primary host-name of the system.

Signing the CSR

In order to include the extensions in the signed certificate the CA must be configured to copy extensions from the CSR. This is potentially dangerous if you do not fully trust the source of the CSR! You may want to enable it on a per-signing basis.

Locate the openssl.cnf file on your CA. Find the appropriate CA section (usually [ CA_default ]) and add or un-comment the following line:

copy_extensions = copy

Copy the server1-ldap-req.pem file to your CA and sign it with the following command:

# openssl ca -keyfile [path to CA private key] -in server1-ldap-req.pem -out server1-ldap-cert.pem

The presence of the subjectAltName extension can be verified using this command:

# openssl x509 -in server1-ldap-cert.pem -noout -text

Look for the X509v3 Subject Alternative Name: section.

Now just install the certificate and private key as you would with any other certificate/key pair.

A Few File Locations

• openssl.cnf:
  • Debian Linux: /etc/ssl/openssl.cnf
  • Mac OS X: /System/Library/OpenSSL/openssl.cnf
  • Solaris 10: /etc/sfw/openssl/openssl.cnf