Having spent the past few months working in ops I have learned a wide range of new skills in server and network infrastructure. I found that my skills as a developed augmented what my then competent ops skills. Coming back to full-time development now I was expecting to find that my infrastructure skills would improve my development. What I wasn't expecting was such an early and staggering example.
A year ago, I solved a problem that I was then experiencing - querying ActiveDirectory with python-ldap under Debian. There was an incompatibility between GnuTLS and AD that made this impossible, due to AD missing TLS 1.1 support and no fallback from TLS 1.1 to TLS 1.0. This would happen:
$ gnutls-cli -p 636 ad.example.com
Connecting to 'ad.example.com:636'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.
This worked when disabling TLS 1.1 in GnuTLS, but libldap does not expose a way to set GnuTLS options, and so nor does python-ldap.
My developer solution
My 2010 workaround was to recompile libldap against OpenSSL (which tested to work with AD). This is how it is done:
Build instructions for libldap
- check that source repos are available in /etc/apt/sources.list
- $ apt-get source openldap
- # apt-get build-dep openldap
- # apt-get install libssl-dev
- cd to the openldap-* directory
- $ CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=<where> --with-tls=openssl See http://www.openldap.org/its/index.cgi/Build?id=5464 for reasons behind the _GNU_SOURCE flag.
- $ make -j <number_of_cpus> depend
- $ cd libraries
- $ make -j <number_of_cpus>
- $ make install
- $ cd ../include
- $ make install
Build instructions for python-ldap
libldap may provide the same binary interface (ABI) whether it's compiled with GnuTLS or OpenSSL, but there is a chance that it may differ, so recompiling python-ldap against the new libldap is recommended.
- # apt-get install python-dev
- Obtain source for stable python-ldap from http://pypi.python.org/pypi/python-ldap/
- Extract archive and enter extracted directory
- Edit setup.cfg: add <where>/lib after library_dirs = add <where>/include after include_dirs = add extra_link_args = -L<where>/lib -rpath <where>/lib somewhere in the [_ldap] section.
- $ mkdir -p <where>/lib/python<version>/site-packages (where <version> is eg. 2.5, 2.6)
- $ PYTHONPATH=<where>/lib/python<version>/site-packages/ python setup.py install --prefix=<where>
To use the recompiled version of the libraries
/lib/python /site-packages/ python example.py
My DevOps Solution
Using stunnel it is possible to "unwrap" the SSL layer and provide unencrypted access to python-ldap. stunnel is compiled against OpenSSL and thus doesn't suffer from the GnuTLS bug.
$ sudo stunnel -c -d 127.0.0.1:389 -r ad.example.com:636
As a developer there's a certain hesitance to introduce another independent service into the system. It feels like weakening the chain, going from one point of failure to many points of failure - potentially bugs or misconfigurations in the adapting component itself or misconfigurations of the server that is supposed to be hosting that component.
As a DevOp, given the tools and experience to maintain infrastructure systems that involve vastly more components than this, it seems robust - no non-standard components, just an easy-to-configure off-the-shelf tool doing what it is intended for.