APC UPS and Snow Leopard Server Not Communicating

I have used APC (American Power Conversion) power equipment for a long time. I have had both good and bad experiences with their products (a cherished memory is calling their technical support and asking about the "smell of burning plastic" emanating from one of their units).

I've recently upgraded an Intel Mac Pro to Snow Leopard Server (OS X Server 10.6.2) and noticed that the controls in Energy Saver for the UPS are different. Not in a good way.

Here's the relevant screen from OS X Server 10.5.8:

And the same screen from OS X Server 10.6.2:

After reading a thread on Apple's support site about APC UPS Charge Percentage Not Updating I changed the setting on the server to that shown in the second screenshot above; namely, since the computer can't seem to read the charge percentage, it's better to let the computer monitor how long it's been on the battery.

Another annoyance is that I keep getting the dialog Your computer is now running on UPS backup battery power. The UPS is supposed to self-test every 14 days but I'm seeing the dialog more often then this.

It makes me uneasy, and I don't like being uneasy about servers.

See also: http://www.macworld.com/article/140207/2009/05/apc_leopard.html

[ Submitted by John on Mon, 2009-12-14 11:22. | | ]

Blast2GO BLAST results not opening in Mac web browser

If you use Blast2GO on Mac OS X 10.5 Leopard (and haven't been derailed completely by Apple moving Java Web Start around), you might have run into the issue of not being able to view BLAST results in a web browser. Blast2GO even helpfully opens a window for you to choose which browser you want to use, but no matter what you select, nothing happens. Except the following gets written to the Application Messages pane:

Error with choosen Browser! /Applications/Firefox.app: cannot execute

The solution is to tell Blast2GO which browser you want to use. You do that by specifying a path in the blast2go.properties file. You can find the file at /Users/yourusername/blast2go/blast2go.properties.

When you open the file in your text editor* you'll see a property entry under User Pathes (sic) called BlastBrowser.Explorer. You may be tempted to put /Applications/Firefox.app here or even, if you're clever, /Applications/Firefox.app/Contents/MacOS/firefox. But don't do that. Firefox will just complain at you about more than one instance running at a time. Rather, use /usr/bin/open and it will automatically launch the appropriate browser.


// User Pathes
MainGui.Workspace=/Volumes/Data/blast2go_datafile.dat
MainGui.Favorites=/Volumes/Data/blast2go_datafile.dat,
BlastBrowser.Explorer=/usr/bin/open

I ensured that Firefox was the default application to open .fcgi files by creating a text file called foo.fcgi and then selecting Get Info. Probably unnecessary because /usr/bin/open opens URLs in the default browser anyway.

*I used TextWrangler -- if you're still opening files in TextEdit do yourself a favor and download TextWrangler, then make it the default text editor.

[ Submitted by John on Thu, 2009-06-25 14:58. | | ]

Permissions fix for Podcast Producer

I'm setting up Podcast Producer, a proprietary podcast workflow system from Apple. After wading through the setup of OpenDirectory, Kerberos, NFS, etc., I attempted to submit my first podcast. On the client console, I got


pcast[5802]: Starting file upload for 63165854-E6A9-46F6-ADE7-BF84D67568A4
pcast[5802]: Total Upload Size: 259255
pcast[5802]: Destination directory: '/Volumes/SFS/Recordings/783AEE7D-C6EA-4F7D-8D1A-17AAFF7905AA' is not mounted on client machine. Skipping.
pcast[5802]: Trying HTTPS POST of '63165854-E6A9-46F6-ADE7-BF84D67568A4.plist' to 'https://podcastserver.example.com:8170/cgi-bin/pcastupload.cgi'
pcast[5802]: Uploaded: 355/259255 bytes (0 %)
pcast[5802]: Time elapsed: 0.064978 and remaining: Infinity (seconds)
pcast[5802]: 500 "Internal Server Error"
pcast[5802]: FTP upload not configured
pcast[5802]: Unable to upload file: /Users/john/Library/Application Support/pcastuploader/metadata/63165854-E6A9-46F6-ADE7-BF84D67568A4.plist
pcast[5802]: pcastuploader quit

On the server, I got

pcastupload.cgi[9708]: /var/pcast/server/cgi.conf does not exist

Digging in further on the server, /Library/Logs/pcastserverd/apache_error.log says

[error] [client x.x.x.x] /usr/share/podcastproducer/cgi-bin/pcastupload.cgi:36:in `read_config': CGI Configuration file does not exist (CGIException)
[error] [client x.x.x.x] \tfrom /usr/share/podcastproducer/cgi-bin/pcastupload.cgi:30:in `initialize'
[error] [client x.x.x.x] \tfrom /usr/share/podcastproducer/cgi-bin/pcastupload.cgi:275:in `new'
[error] [client x.x.x.x] \tfrom /usr/share/podcastproducer/cgi-bin/pcastupload.cgi:275
[error] [client x.x.x.x] Premature end of script headers: pcastupload.cgi

Well, all pcastupload.cgi is trying to do is read the config file at /var/pcast/server/cgi.conf. A quick check showed that /var/pcast and /var/pcast/server were not readable by anyone except the owner, root.

So to fix the problem:


sudo chmod o+rx /var/pcast/
sudo chmod o+rx /var/pcast/server/

Now the podcast is successfully uploaded to the server. Of course, it's dying there now, and I'm off to investigate.

[ Submitted by John on Tue, 2009-06-23 14:57. | | ]

Go ahead and ignore

Hmm, I think I will go ahead and click Ignore...

[ Submitted by John on Mon, 2008-04-28 08:53. | | ]

XServe RAID discontinued

Apple has discontinued their confusingly named XServe RAID storage system. That's a shame, and yet another red flag for trusting Apple in the enterprise market, in my opinion.

I currently administer two of these (one on OS X Server and one on RHEL5), and I can't say enough good things about them. They have been reliable and fast. When a disk goes out, the system sends out notification and starts a rebuild on the hot spare automatically, just like a good RAID should. And they're quieter than any other dedicated RAID solution I've looked at. RIP, XServe RAID.

[ Submitted by John on Tue, 2008-02-26 09:47. | | ]