North Star Labs

Working with Apache today, I ran into an issue where the process would appear to start OK, returning a zero exit status, yet strace was showing a SIGCHLD being caught.

Needless to say, the server wasn’t actually running for any length of time, but I found the following strace command immensely helpful in figuring out the problem.

  strace -o /tmp/httpd.strace -ff /usr/sbin/httpd

Because apache spawns a number of children, strace with -ff attaches to each child and recorded the system calls in /tmp/httpd.strace.$PID

As it turns out, I was receiving the following error in the child processes:

    bind(5, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("0.0.0.0")}, 16) \
    = -1 EADDRINUSE (Address already in use)

Over the past few months, I’ve been getting fed up with stability issues plaguing my OpenWRT based Linksys WRT54GS v2.0 router. Wireless under OpenWRT was very unreliable, often cutting out in the recent version of White Russian I was running.

Based on the advice of a friend, I’ve re-flashed my firmware to DD-WRT v23 SP2, and I must say, I’m quite impressed. The Web interface is very slick and clean, UPnP is working out of the box, QoS is present and configurable, though I haven’t tested it very much yet, the web interface allows SSH public keys to be configured easily, and stores them in NVRAM variables, and my dynamic DNS host name is also easily configured through the web interface.

All in all, I’m finding DD-WRT to be much more developed and polished than OpenWRT. I’ll comment on this post after a week or so in the event I have stability issues.

I had $15 in expiring gift cards from when I bought my new TV, so I decided to pick up an inexpensive 2gig Flash drive online.

To increase my peace of mind, I decided to store everything important to me in an encrypted disk image on the device. I used the same method I use to create a FileVault image, and then just moved the image file over to the flash disk.

I’ve been really happy with the performance, and it’s great know that WHEN I lose this tiny thing, none of my private and very sensitive information will be accessible to whoever picks it up.

In addition, there’s really no additional barriers to using this encrypted disk image. I store the password to the disk image in my Keychain, and it’s also encrypted with the FileVault Master certificate as an added layer of protection against forgetting my password.

Finally, even though the following command creates a sparse bundle capable of storing 300 Gigs of data, the Finder will realize the image file lives on a 2 Gig flash drive, and will only display the free space available on the “parent” filesystem.

The command to create the Leopard-only disk image is:

umask 077
export NAME="secure"
hdiutil create -size 300g \
    -encryption -agentpass \
    -mode 0700 \
    -fs "HFS+J" \
    -type SPARSEBUNDLE \
    -layout SPUD \
    -volname "$NAME" \
    "$NAME".sparsebundle;

Joel just posted a great article titled SSL and LDAP in Leopard about the pitfalls of using SSL secured LDAP servers in Leopard. As Joel mentions, Leopard now refuses to trust any and all SSL protected LDAP servers out of the box.

A few people have complained that Directory.app, and the the LDAPv3 plugin for DirectoryService don’t honor the same purchased certificates that work just fine in their web browsers. Nor do they honor certificates signed by authorities listed in the x509Anchors keychain.

I’m not sure exactly where I personally stand on these very reasonable gripes, but I do know that it’s relatively trivial to configure all of your clients to honor “legitimate” certificates signed by authorities such as VeriSign, GeoTrust, etc…

It’s as simple as:

echo "TLS_CACERT /usr/share/curl/curl-ca-bundle.crt" >> \
  /etc/openldap/ldap.conf

You may need to give DirectoryService a kick, with killall DirectoryService.

This works because Apple already distributes a long PEM encoded list of certificate authorities for use with the curl command line utility. We’re able to leverage it’s trusted certificate store.

Also be warned your Leopard workstations are now slightly more vulnerable than if you were to configure only the certification authorities you need to get your LDAP server trusted.