David Sirr's ...stuff

My Day job's  production servers are based on Apple X-Serve and OSX as the operating system.

In a bid to get greater service stability last week we decided to roll out the latest system updates, notably upgrading to OSX 10.5.7

We rolled out first to our staging server which is effectively a mirror of production setup, it went smoothly and we tested our several critical apps and all seemed fine.

So we also ran all the additional system minor updates including Apples Java Update 4, as running this on my dev machine had resolved several issues with the java imaging libraries crashing the server while trying to process images with certain colour profiles etc.

Again all seemed good, so we rolled out to the live server. All went fine, or so we thought.

Co-incidently around this time i was experimenting on my dev machine (also 10.5.7 with java updater 4) with recently released google API components without much luck, i was constantly getting "I/O Exception: peer not authenticate" error when trying to connect to googles API. I thought it's just my machine playing up again...

A few days later clients using two seperate applications reported general application errors, after some digging around i traced both errors to CFHTTP calls in each application.

I tested the urls in the browser on the server and both were responding as expected... strange i thought...

So i noticed that both were SSL URLs and the error was "I/O Exception: peer not authenticate", which i then immediately connected back to the troubles i had connecting to googles API on my dev box. After some research on that error, it appeared that previously this error occured with connections to SSL URLs with certs issued by intermediate CAs which weren't present in the trusted CA keystore in the JVM. But google and our other API providers were using the most expensive CA's (thawte, verisign, etc) top level certs, which were definitely present by JVM 1.6 so this couldn't be the same issue.

At this point i asked a co-worker who was only on Java Update 3 to try the same code, or really a CFHTTP to any SSL URL. It worked as expected without error. Bugger.

Unfortunately apples java updates work via patching so there is no rollback or uninstall! In desperation we tried a developer preview of java update 5 on the also broken staging server, with the result that coldfusion no longer even starts up at all :(

So the only resolution was to restore our 10.5.2 pre-update backup and then re-upgrade to 10.5.7 without applying the java update 4.

This worked. We are happy for now! But i'd love to know the solution for this update 4 issues as my dev machine is still broken until i can find time to format and reinstall everything...

So, is anyone out there running OSX 10.5.7 and applied java update 4 and connect CFHTTP calls to SSL servers?

Please let me know!

Creating the new coldFusion instance

• login to the main coldfusion administrator (e.g. http://localhost/cfide/administrator)
• go to enterprise manager / instance manager
• select 'add new instance'
• enter a server name (e.g. 'newcfusion')
• leave server directory as default (/Applications/JRun4/servers)
• leave create from EAR/WAR blank
• submit form and wait for everything to finish
• the link you are provided to continue will probably be broken so ignore and click on 'instance manager' again
• open the /Applications/JRun4/ColdFusionLauncher.app and select your instance and click start if it is not running already
• click the button next to your instance name to launch the adminstrator and configure your instance (e.g.http://localhost:8301/cfide/administrator)

Hooking the new instance into a specific apache website

For and apache website to talk to a specific jrun (CF) instance you need to bind an apache virtual host to a jrun proxyport for your coldfusion instance

• make sure the admin jrun instance is started
• browse to http://localhost:8000 and login with admin and the administrator password you gave when installing coldfusion
• click the new instance from the left nav, and click services
• you then need to note down the proxyPort (e.g. 51000) and click the green play button to start the proxyService
• open up the httpd.conf or the apache vhost site config file and inside your <virtualHost> add:

<ifModule mod_jrun22.c>
# override the default bootstrap in the httpd.conf to bind to my new coldfusion instance
JRunConfig Bootstrap 127.0.0.1:51000
</ifModule>

• restart apache after the cfinstance is running and it should now be using the new instance

Autostarting your new instance at system boot

You need to use a program like smultron to edit the file ColdFusion8Multi in /Library/StartupItems/ColdFusion8Multi and add: su $RUNTIME_USER -c "$CF_DIR/bin/jrun -stop newcfusion" under the line su $RUNTIME_USER -c "$CF_DIR/bin/jrun -stop cfusion" in the if block, and also outside the if block: su $RUNTIME_USER -c "$CF_DIR/bin/jrun -start newcfusion >& $CF_DIR/logs/newcfusion-event.log &" basically the same lines already present in ColdFusion8Multi but replace cfusion with your instance name, also make sure the log file has write permission!

This being my first attempt at setting up a leopard webserver i was getting a tad frustrated with apache and the SSL setup for one of the websites. Everytime I dropped in the site's config the server wouldn't start, giving a bad passphrase error in the console. Not being able to find an option for this in my SSL config I was going around in circles and getting scared that this would be a show-stopper for our new server, especially after reading so many forum posts saying that SSL in leopard was a nightmare requiring custom builds of apache and openSSL etc... Salvation was found in the Server Admin tool... despite the fact that once you start manually editing the virtual host site files the lovely web config panel ceases to recognise any of your sites, there is a quite useful 'Certificates' button when you select the root node of your server. I had already copied all the related cert files from the 10.4 server to /private/etc/certificates, so it was then a simple matter of choosing the import certificate option and figuring out which files to put in what box. My files ended up being:

• certificate file (*.crt)
• private key file (*.key)
• certificate authority file (*.chcrt)
• private key passphrase (this was the thing that instantly fixed it for apache)

From here it worked like a dream! I hope this will save similar worry to some of you out there...

I've just added a new section in the pages area of the blog with detail of my open source projects that will be kept up to date. So far i've only put up CFGrowl project, but more to come!