HOWTO configure ntp on a windows 2003 server

Wow, this is really sucky. I can't believe this is the blessed procedure. I have reproduced it here:

Open Registry Editor (regedit.exe) and configure the following registry entries:

    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type

This registry entry determines which peers W32Time will accept synchronization from. Change this REG_SZ value from NT5DS to NTP so the PDC Emulator synchronizes from the list of reliable time servers specified in the NtpServer registry entry described below.

    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags

This registry entry controls whether the local computer is marked as a reliable time server (which is only possible if the previous registry entry is set to NTP as described above). Change this REG_DWORD value from 10 to 5 here.

    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer

This registry entry specifies a space-delimited list of stratum 1 time servers from which the local computer can obtain reliable time stamps. The list may consist of one or more DNS names or IP addresses (if DNS names are used then you must append ,0x1 to the end of each DNS name). For example, to synchronize the PDC Emulator in your forest root domain with tock.usno.navy.mil, an open-access SNTP time server run by the United States Naval Observatory, change the value of the NtpServer registry entry from time.windows.com,0x1 to tock.usno.navy.mil,0x1 here. Alternatively, you can specify the IP address of this time server, which is 192.5.41.209 instead.

Now stop and restart the Windows Time service using the following commands:

    net stop w32time

    net start w32time

You should see some entries in the system event log stating that the box is receiving time from the server.

Nagios check_proc fooled by 15 character limit in /proc/pid/status

Interesting problem with the nagios check_proc command. It does not take into account that the status variable in /proc/pid is limited to 15 characters. Names of processes longer than this are truncated.

Using python ldap to authenticate a django app to a windows domain controller

I used a HOWTO and the auth backend from django ticket 2507 to get django working with a linux openldap. The next task was to get it working with windows. This will probably depend on your AD structure more than anything else. I used the following in settings.py:

    import ldap
    AUTHENTICATION_BACKENDS = (
    'myapp.ldapauth.LDAPBackend',
    )
    LDAP_DEBUG=True
    LDAP_SERVER_URI='ldap://mydomain.com'
    LDAP_SEARCHDN='ou=Staff,dc=mydomain,dc=com'
    LDAP_SEARCH_FILTER = 'sAMAccountName=%s'
    LDAP_PREBINDDN = 'bindacct@mydomain.com'
    LDAP_PREBINDPW = 'pass'
    LDAP_BIND_ATTRIBUTE = 'cn'
    LDAP_FIRST_NAME = 'givenName'
    LDAP_LAST_NAME = 'sn'

I used ipython to debug my ldap setup:

ipython
import ldap
ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
l = ldap.initialize('ldap://server:port')
l.simple_bind_s('domainuser@mydomain.com','pass')
l.search_s('ou=people,dc=mydomain,dc=com',ldap.SCOPE_SUBTREE,'sAMAccountName=domainuser')

The next step is to follow the Microsoft instructions for enabling SSL so the creds don't travel in cleartext.

Upgrading ubuntu

When upgrading ubuntu I usually just change my sources.list and do a dist-upgrade. There is now a utility that essentially does this for you: 'do-release-upgrade'. It replaces all occurrences of the old distro eg. 'intrepid' with the new distro 'jaunty' in your sources.list, downloads packages and tells you to reboot. Nice!

You can also upgrade with the GUI 'update manager', but I found it wasn't very good at reporting progress so I wasn't sure what was actually happening.

Backup and restore openldap 2.4

Backup

/etc/init.d/slapd stop
sudo slapcat -n 0 > backup/config.ldif
sudo slapcat -n 1 > backup/users.ldif
sudo cp /etc/ldap.secret backup/ldap.secret
/etc/init.d/slapd start

Restore

/etc/init.d/slapd stop
sudo slapadd -n 0 -l backup/config.ldif
sudo slapadd -n 0 -l backup/users.ldif
sudo cp backup/ldap.secret /etc/ldap.secret
/etc/init.d/slapd start

Openldap 2.4 and TLS

The HOWTOs I used were:

• TLS section of the admin guide
  
• The TLS FAQ entry - also includes a quick howto for creating your own CA
  

The most annoying thing about openldap is that pretty much every bit of advice and howto on the Internet is for the old version that uses slapd.conf. In the new version (2.4) everything is stored in the LDAP database in ldif itself. So where is the advice about how to add the TLS config directives? Nowhere! Not only that, but ldapadd and ldapmodify are really difficult to use, with poor error messages if you screw up your ldif syntax.

You need to write a file tls_ldap.ldif:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/ssl/demoCA/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/servercrt.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/serverkey.pem

Then run:

sudo ldapmodify -f tls_config.ldif -D cn=admin,cn=config -x -y /etc/ldap.secret

This assumes that the admin password is stored in /etc/ldap.secret - this is how the debian package installs ldap. Most advice on the internet tells you to look in slapd.conf for rootpw - retarded. Interestingly, after I disabled regular ldap in favour of ldaps below, I couldn't use ldapmodify anymore, even when I specified ldaps:// with the -H parameter. Had to re-enable regular ldap, run the command then turn it off again.

Add the following line to /etc/default/slapd (if you only want SSL then just use ldaps):

SLAPD_SERVICES="ldap:/// ldaps:///"

Restart slapd.

On the client you need to copy over the cacert, and add these lines to /etc/ldap.conf:

uri ldaps://myserver.fqdn.com/
tls_cacertfile /etc/ssl/ldapcacert.pem
tls_checkpeer no

I had to turn off tls_checkpeer, even though this shouldn't be necessary. The server wasn't giving any error logs, until I ran it manually in super debug mode:

sudo slapd -d -1 -g openldap -u openldap -h ldaps:/// -F /etc/ldap/slapd.d/

When it gave "unable to get TLS client DN". I figured out what the problem was: I was just using "myserver" in the URI, instead of the FQDN in the certificate. So make sure you put the same domain in your ldaps uri as appears in your certificate (should be fully qualified like "myserver.fqdn.com").

Python distutils installer and user_options

I found the standard doco for distutils to be pretty appalling. It is really only useful for simple cases. The API Reference is slightly more useful, but still not great. I couldn't find a good explanation of how user_options worked to pass extra stuff into the setup script.

Here a few things I found out after a lot of mucking around:

• Tuples that go into the user_options array should look like:

  ('mysql-root-passwd=', "p", 'MySQL root password for local server [default: None]')

  The '=' on the first element tells distutils this options should have a value (i.e. it is not a boolean option)
  
• Options get stored as object variables in your class so the one above turns up as self.mysql_root_passwd - note the substitution for '-'.
  
• To subclass the install command inherit from

  from distutils.command.install import install

  and set

  'cmdclass': {'install': WhitetrashInstallData}

  in your call to setup.
  
• If the doco sucks, take a look at the code:

  /usr/lib/python2.5/distutils/command/install_data.py

  helped me.