The Snow Leopard VPN is not very configurable from the GUI, but behind the scenes it is using a racoon configuration.

To grab the configuration it is generating, configure the VPN in the System Preferences GUI, then rename /usr/sbin/racoon and try connecting. The config file will be written in /var/run/racoon/. Grap a copy of that file and customize it to your needs. Once you have the config file, rename racoon back to its original name.

Then to make the GUI use your custom config file instead of the one it generates, edit /etc/racoon/racoon.conf to include your custom config file and comment out the line:
include "/var/run/racoon/*.conf" ;


By making a few changes I was able to get a successful connection to our Cisco VPN Concentrators.

I’m hoping there is a less hacky way to accomplish this. If you know of one, let me know. Otherwise file a bug with Apple.

Web apps including rails won’t parse parameters POSTed in an http request unless a specific header is present.
A curl command automatically adds this header for you, but other tools including httperf might not.

To ensure the header gets sent with httperf, add the following command line option:
--add-header 'Content-Type: application/x-www-form-urlencoded\n'

Note, I discovered the answer because curl worked, though httperf did not. So I ran the curl command against a simple netcat (nc) server and noticed the extra http header being received. Netcat was really handy for this. To run a netcat server simply enter nc -l 1234, where 1234 is the port you want to listen on. Then run your client app pointing to your netcat server ip and port. The netcat server will output the raw TCP it receives.

Rails turns on protection from CSRF Cross-Site Request Forgery by default. It can make load testing more challenging since you need to get an authenticity_token for posting form data.

More information here: http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html

Using current record when AppleScripting FileMaker has a couple of problems. The current record can change out from under you, so by the next step in your script, you may be dealing with the wrong record. Simply storing the record result in a variable doesn’t work either because getting the result converts it to a native AppleScript list of the data from the record. Using a reference to current record suffers the same problem.

One solution is to use record IDs. I believe that record IDs are guaranteed to be static/unchanging, at least while the app is running.

To get the record ID for the current record:
set recID to ID of current record

To use the record ID later in your script:
get cell "my_field" of record ID recID

To get all record IDs for a given query:
set recordIDs to ID of every record whose cell "my_field" is "my_value"

Then access each found record by ID:
repeat with recID in recordIDs
   get cell "my_other_field" of record ID recID
end repeat

Note: The following method will also work for certain use cases since it appears to use the record ID internally as well:
set x to current record as reference

Ruby’s built-in telnet capability has been extremely useful for scripting automated RAID changes like LUN masking, etc.

It is super simple. Connect, login, issue commands, read and parse results.

The example code I used is here.

This is telnet, so don’t do this if eavesdropping is a concern.

If your firewire hard drive is failing intermittently or after transferring some data, it could be a heat issue. Symptoms might include i/o errors and spontaneous disconnects.

Simply removing the case (housing) from my Western Digital MyBook drive allowed it to work reliably enough to get all of the data off. I might continue to use it that way since it hasn’t failed since removing the housing.

I’ve seen this issue with LaCie cases as well. They get extremely hot and are prone to failure, especially if the case does not have a fan and the drive is used continuously for long periods of time, such for backups.

If you need to use a firewire drive for backup, I would invest in a good case with a fan if possible.

The title says it all. If you find that it does work, please let me know. I’ve tried it and it does not work even though there is a reference to a computer type record in the man page.

Apple’s document on Extending and Troubleshooting Directory Services has a lot of good info.

One correction though is that the debug level must be an integer.
sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" -integer 2

I’ve notified Apple, so this may be fixed by the time you read this.

I often need to schedule scripts to run at an interval, but I don’t know how long that script will take to complete and I don’t want the script to run again at its normal interval unless the script isn’t running.

I’ve done this with pid files and grepping through ps lists to exit the script if another instance is running, but I was wondering if there is something built into launchd to handle this.

It turns out that launchd does this by default. Just set up your job as normal using StartInterval and if your job hasn’t finished running by the next time it is scheduled to run, launchd will wait until the job finishes. If more than one schedule has passed, the missed jobs will be coalesced into one instance and run just once until the next scheduled run, much like it behaves if the machine goes to sleep.

Another win for launchd.

I was getting random AD plugin connection issues after joining to Active Directory. dsconfigad showed no errors, but sometimes I would not get a connection and I would have to rejoin. The problem turned out to be related to replication.

The AD plugin initially has no knowledge of which AD site and domain controllers are considered local to your subnet, so it discovers any domain controllers and contacts one to lookup the site information. During this process, and in general, the AD Plugin keeps an LDAP connection open to the domain controller. The AD plugin likes to reuse these LDAP connections, presumably for performance reasons. When it is time to actually add the computer to the domain, the AD Plugin reuses this existing connection. The problem is that this domain controller is not necessarily one within your AD site.

At this point, if the Mac is restarted or DirectoryService is killed, any new connections will be made to a DC in the subnet’s AD site, but if your computer was added to a non-local DC, the local DCs may have no knowledge of your computer because the computer account has not yet replicated to them.

This problem can appear to be quite random because sometimes you’ll get lucky and get a local DC for the join, or you might catch the replication at the right time. You might also see bad password errors in the DirectoryService debug logs. I have filed a bug report on this, and I don’t have a good workaround for now other than — don’t reboot or restart DirectoryService after a join. Of course if you know your replication schedules, you could just wait until you are sure replication is completed.

This same issue can present itself with unjoins and rejoins.

You can see what domain controllers you are connecting to during the join using the following shell command assuming your are joining using dsconfigad:

while [ 1 ]; do if netstat -a | grep ldap| grep ESTAB; then ps auxww | grep dsconfigad | grep -v grep; date;fi; done


If you have joined, unjoined, and rejoined and think you may be seeing replication issues, compare the whenCreated attribute of the computer account on different domain controllers using ldapsearch.

ldapsearch -LLL -v -W -x -h domaincontrollerfromsite1.subdomain.forest.com -D username@subdomain.forest.com -b "OU=Computers,DC=subdomain,DC=forest,DC=com" CN=machine-join-name | grep whenCreated:


If an older out of sync computer account exists, its whenCreated date will be different from the domain controller the computer was just added to until the last join has replicated to all the servers.