Archive for June, 2012

Configuring Existing OpenLDAP 2.4+ Directory to Accept TLS Connections

Friday, June 29th, 2012

This tip assumes that OpenLDAP is currently running properly on port 389 without SSL/TLS configured and that the database is being used to store the config file via cn=config.

1. Generate an SSL key pair

a. private key

openssl genrsa -out slapd.key 2048

b. self-signed certificate


openssl req -new -x509 -key slapd.key -out slapd.crt -days 1095

2. copy the certificate file and key to /etc/openldap/tls or appropriate location — be sure to modify the following LDIF if not maintaining the standard thus far in this tip

3. Create a file called tls.ldif and copy the following contents into it:

# re:  ldapmodify -x -D "cn=admin,cn=config" -w $password -f tls.ldif
dn: cn=config
changetype:  modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/tls/slapd.crt
add: olcTLSCACertificatePath
olcTLSCACertificatePath: /etc/openldap/tls
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/tls/slapd.crt
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/tls/slapd.key
add: olcTLSCipherSuite
olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2

4. Execute the following command to modify the database, based on the contents in the LDIF, enter the password for the DN cn=admin,cn-config when prompted:

ldapmodify -x -D "cn=admin,cn=config" -W -f tls.ldif

Once that step is complete, TLS connections should succeed. To validate this assumption, execute an ldapsearch with the -ZZ flags to force a successful TLS connection.

ldapsearch -xZZ -D "cn=manager,dc=example,dc=com" -W

5. Once TLS connections have been configured and validated, configure all clients to connect via TLS.

6. The next step is to *require* TLS connections from all clients, using the following LDIF — require-tls.ldif:

dn: cn=config
changetype:  modify
add: olcSecurity
olcSecurity: minssf=256

Do not do this until clients are configured or you will risk being locked out!

7. Run ldapmodify to modify cn=config:

ldapmodify -x -D "cn=admin,cn=config" -W -f require-tls.ldif

MySQL Backup over SSH to Another Host

Tuesday, June 26th, 2012

A problem that I’ve had a few times is to backup a MySQL database before decommissioning a server. Oftentimes the server is not large enough to accommodate a backup on the local disk store so a remote backup is required. This is not too hard, athough with hundreds of gigabytes or serveral terrabytes, it can take quite some time and be costly in bandwidth costs.

Here is how to do it:

mysqldump -u${msyqluser}  -p${mysql_password} ${mysql_database} \
   | gzip -c | ssh -l $user $host 'cat > /path/to/backup/location/file.sql.gz'

It’s not pretty, but it’s effective.

At this point, the astute reader is asking, why doesnt the regularly schedule backup get copied to the final destination? Or possibly, why aren’t backups being taken locally?

Great questions all, but that’s not always possible, depending on the customer and particular strategy in play.

Whenever I setup a new server, I try to satisfy some basic requirements that make my life easier for on-going maintenance:
1. backups in place
2. break/fix and performance monitoring in place
3. high availability (mysql slave, load balanced web server, etc..)
4. configuration management, backed by source control

If these 4 steps are followed and documented, life is much easier!

AWS Elastic Load Balancing in a Private Subnet

Wednesday, June 6th, 2012

I recently learned a valuable lesson when setting up load balancing using an Elastic Load Balancer within a Virtual Private Cloud using public and private subnets and a NAT host.

When creating the ELB, be sure to create it within the public subnets and not the private subnets where the instances that will be attached to the subnet exist!

Creating the ELB within the public subnet(s) will allow them to route through the internet gateway and route traffic properly.

Note that any instance within the private subnet requires a route to the NAT host in the public subnet which has an EIP for internet access through the internet gateway. Any instance in the public network requires an EIP to allow routing through the internet gateway.

This guy said it first.