Error loading /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: ... no matching architecture in universal wrapper

This is due to osascript running in 64 bit mode and being unable to load a 32 bit addition. A quick fix is to force osascript to use i386 architecture, like so:

arch -i386 osascript path/to/applescript


In addition, you can now eliminate the error referenced above by downloading the latest 64 bit Adobe Unit Types.osax from the Adobe site.

Here’s hoping the 64 bit transition goes smoothly for all involved. I’m thinking the performance payoffs will make these little workflow snags worth the effort.

This is the first fruit of my experimentation. I often need to make a tape log of a sequence in Final Cut Pro, and a quick way to get the sequence details into a text file could be useful. The most approachable way to address the problem seems to be with markers. You can store all of the values I need for a tape log in a marker – item number, name, description, length and the starting timecode. So, that’s how we’ll approach it.

1. First, we’ll need to add a marker at the time in the sequence we’d like to add an item. A quick way to add a marker is to hit the m key twice, or go to the menu item Mark:Markers:Add . When we do that we’ll get something that looks like

2. We’ll want to rinse and repeat for each item we want in the log.

3. Export an FCP-XML file of just the single sequence of interest. A possible upgrade for this action would be to do a version where we pick the sequence, but for now the Action is just set to work with a single sequence. Any version of the Final Cut XML spec should work just fine

4. Launch the workflow, markerToLogWorkflow.workflow which should look like this.

5. Run the workflow by pressing the run button. You can set options by selecting or deselecting the checkbox for items. When I run the workflow I get a text file looking something like…

That’s about it. Next up will probably be digging into Indesign Automator Actions so that we could flow our log into a nicely formatted document. Another interesting Action might be to do this in reverse adding Markers from a producers Excel, Word Doc, or XML File, but I’m happy with this as a start.

So, what do I think about Automator? It definitely takes a little getting used to, but if Apple continues to improve features, I’ve heard rumors of cool Leopard upgrades, then I think it will be a good application to add to the mix.

Zip Archive of Action and Workflow

You’ll need to move the markerToLog.action file to your Library/Automator folder for the Workflow to work.

I’ve been here before, with an investment in a technology that seems to be going away. I tend to take a pragmatic approach as much as possible. Things usually don’t fall apart right away, but as each new software update is added to the puzzle you start to lose functionality. So you have to start your migration strategy early. I first do an inventory of the current technology landscape and what options are available. If there is a clear migration path (hint to backup vendors: If you can read a Retrospect catalog , reverse-engineer the tape format and make it seemless I’ll be the first in line) I’ll take that path. If not, it usually involves some sort of dual platform support until the first technology platform fades into the background. This path is less ideal because that first platform becomes so archaic, Jazz Disks anyone?, that you end up having ancient workstations dedicated to that format taking up valuable studio space. If the data is important, I’ve found that it makes sense to bite the bullet and migrate to the new format.

Either way, none of this is fun. I don’t have any definitive answers of what is the right direction to take, but I’ll be posting some of the information I find out as I do the research and see what’s out there. Feel free to leave comments about any information you have about good options for small and medium sizes businesses with the heavy back-up requirements that digital studios face.

/usr/bin/mdimport -d2 /path/to/pdf/file.pdf >& pdf.txt

It’s the raw text that Spotlight is using to index the file, so you’ll need to do some clean up, but your mouse hand will thank you.

(via Borkware Quickies)

An equally common question is, “What media should I use?”. There are a ton of manufacturers, OEM’s, and generic media on spindles. Luckily, Patrick McFarland has done most of the research for you in his article How To Choose CD/DVD Archival Media. He gives a history of different flavors of optical media and recommendations on which flavor to use as well as specific manufacturers he recommends. Very useful stuff. Hopefully, he’ll take the time to breakdown his recommendations on Blu-ray and HD-DVD once the dust settles there.

Around the middle of last year a security exploit was found in the implementation of the XML-RPC protocol in PHP. PHP is obviously a very popular web scripting language and dozens of content management systems, including the blogging software I use for this blog, utilize the language. Now an open security hole in such a popular language is just an invitation for the underground to attempt to exploit the situation, and try to exploit they did.

It started out as just a trickle, but before long it became obvious that the underground was attempting to exploit the security hole. How’d we know? By analyzing our logs.

An access log is generated by your web server, in our case Apache, and contains a lot of information. For example, here is a random line from this blog.

208.52.128.170 - - [28/Apr/2006:11:07:53 -0700] "GET /wp-content/themes/rdc/style.css HTTP/1.1" 200 7581 "http://www.creative-workflow-hacks.com/" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/418 (KHTML, like Gecko) Safari/417.9.2"

The first column is where the ip request comes from. The second is the date. The third is the url and the GET means it uses a GET style HTTP request. The fourth is the user agent, in this case Safari. So that’s all well and good, but what’s that have to do with the security exploit?

Well, by looking at your raw access logs, you start to notice patterns. Something like this is what we started to see in our access logs.

209.213.106.25 - - [26/Apr/2006:05:46:19 -0400] "GET /xmlrpc.php HTTP/1.0" 404 1453

and

209.213.106.25 - - [26/Apr/2006:05:46:20 -0400] "GET /drupal/xmlrpc.php HTTP/1.0" 404 1453

Drupal? We're not using Drupal. What was happening were attempts to exploit the security hole. And there were quite a few attempts and they kept coming.

So was this some lone hacker typing into her browser? Not likely. What was happening was bots.

You've probably heard about spyware. In addition to sending you all kinds of weird popups and putting casino shortcuts on your desktop, malware like this can take over your computer and do things like send spam email, or in this case attempt to send security exploits to take over yet more computers and send spam email and then attempt...well, you get the picture.

So by analyzing our logs we start to get a picture of what to watch out for and figure out what software *really* needs to be up to date. Better get over to wordpress and check for patches

What I want to show today is one little tool that I used to analyze our logs while this exploit was going on full tilt, although we still see a lot of requests for xmlrpc as the last laggards still haven't updated their software and the law of diminishing returns kicks in for the bots

We're going to use the command line today (it's really not that scary, you might even end up with 10 different shells open on your deskop one day like a real unix grey beard...don't laugh, it could happen).It goes without saying that the following will only work if your webserver is running apache and you have unix shell acess to the server your log files are kept. The first order of business is to find out where your log files are kept. A common location is /var/log/httpd or if your on a shared host, a logs directory in your home directory. Once you've figured out where your log file is located, let's cd to that directory.

Unix tools are designed to do one thing very well and work in conjunction with other small tools that do one thing well to accomplish the task at hand. Unix tools have a concept called standard input and standard ouput which allow each tool to do their bit of business and then pass the result on to the next tool. The command we are going to use today is:

cat access.log | grep xmlrpc |  awk '{print $1}' | sort | uniq | wc -l

Scary huh? But don't freak out. We'll go through each part and you'll start to understand that it really is easy and you might be able to do some useful work with this command line stuff any how.

So let's start off with the first part. Commands start from the left like you're reading a sentence. cat access_log catalogs or writes out the acess_log to standard output which in this case is the terminal in which you typed the command. Your version of your access_log might be named something else like access.log or somesuch, but you should be able to figure it out. You could also use tail command if you had an access_log that is several days long and you only want to check out just the last bit of access.

Use tail -n 100 to grab the last 100 entries. Which brings us to Unix command switches, the -n 100 is a command switch. Most unix commands let you alter the base behavior of the command with a switch. How do you know which switches to use? You use the man command. Type man tail and see what you get.

A lot of the stuff in a man can seem hopelessly geeky at first, but with a little perserverance we can find what we need. So we've written out our access_log file. This is the raw data that comes from the web server. Take a look around, it's pretty interesting even before you've run analytics on it, but for most folks it's just too overwhelming to find anything useful. Let's take a look at the next part of our command.

cat access_log | grep xmlrpc

the | is the pipe indicator. We talked earlier about standard input and standard output. The | lets us pipe the output of cat into the input of grep. If we wanted to write out our acess_log to a file we would use the > character.

tail -n 100 access_log > ourfile.txt

would write a file called ourfile.txt with the last 100 lines of our access_log.

Back to our command. We pipe the output of our access_log to something called grep. What is grep? Grep stands for "generalized regular expression processor". Grep allows us to search for patterns in our output called regular expressions. Think of a regular expression as a find and replace on steroids. Regular expressions can get really complicated, but in our command we're just looking for xmlrpc. It won't match on variations with upper case or with dashes, etc., but it's surprisingly effective here.

Let's move on to

cat access_log | grep xmlrpc | awk '{print $1}'

We now pipe any matches on xmlrpc to awk. awk is a general purpose language that is designed to process text data. I don't use awk a lot, but it is really handy to grab a specific column from text output. That's what we do here. awk'{print $1}' takes only the first column and prints that to standard output. So from the first three parts of our command, we've printed the ip address of every access on our web server that used the word xmlrpc. Pretty neat. Let's move on.

cat access_log | grep xmlrpc | awk '{print $1}' | sort

All of those ip addresses are all over the place. Let's sort them into something useful. We first sort them numerically with sort.We use the uniq command to grab only the unique ip's. These bots might hit us once or a bunch of times, but we are only interested in grabbing the unique ones.

cat access_log | grep xmlrpc | awk '{print $1}' | sort | uniq

If we stop here we get a sorted, unique ip list of requests for xmlrpc. If we had a blackhole list we could add these ip's and not accept requests from these ip's in the future when the next exploit becomes available. We do need to be careful with that though because your most important customers might have a virus or spyware and not be able to access your site or your grep search string might find ip's that are accessing your site legitimately, use your judgement.

And finally

cat access_log | grep xmlrpc | awk '{print $1}' | uniq | sort | wc -l

let's use the word count command wc command with the -l switch to count the number of lines. 137. Wow. During the worst of our xmlrpc weirdness we were getting 137 unique ip's trying to exploit our web server.Definitely time to check for patches.

So that's it. This was definitely a long-winded post, but I hope you find it useful especially if your new to the command line. Like most things computer oriented, try to break down your big goal into smaller pieces until you work out the combinations that get you were you need to go.

THE SCENARIO

My boss approached me about a weird slowdown he was having where his machine was slowing to a crawl. Trying to move the cursor was taking a lifetime to move a couple of inches. There wasn’t a beachball cursor indicating an application was sucking up resources and I was able to launch programs, just very S L O W L Y.

So, what did we do?

I’ve done this stuff for a while and you start to get a sense of what seems like the usual suspects when you’re debugging an OSX problem. I’m going to run through the process I use and tell you about what we found out.

THE PROCESS

Step One.

We back up a lot of data at Primal Screen. We do both SD and HD video and have about 10 Terabytes of online storage and 5 Terabytes for near-line archive storage, combine that with individual client machine backups, and we, unfortunately, end up backing up during business hours. So when I hear about a mid-day slowdown, the first thing my “spidey-sense” goes off about is back-up. We use Retrospect from a central server so I did a quick check to see if it was running the client backup on Doug’s machine. Nope.

On to step two.

I also knew that Doug had recently installed Tiger(OSX 10.4) on his laptop. We are relatively late adopters on software for production machines and we’ve had enough problems with Tiger that it still isn’t universally adopted. One of the “features” we struggle with is Spotlight. Spotlight is a great idea. It indexes your data and allows for quick context sensitive searches, but it’s definitely a version 1.0 technology. The interface is a bit wonky and you can sometimes run into the next problem I suspected, Spotlight indexing. Spotlight needs to “index” your computer to gather all of the information that it uses. Indexing means that spotlight goes through the folders on drives that are searched by Spotlight and gathers the metadata from your files so that you can search it. While this is happening your machine can slow down and become unresponsive. So that’s the next place we look.

If you open Applications/Utilities/Activity Monitor (or for the geeky who like the command line, via Applications/Utilities/terminal top -o cpu), the process mds is active when Spotlight is either indexing or searching. The mdimport process is also active during indexing. If we were having Spotlight problems, those processes would be active and using excess CPU cycles. Nope, in this case.

If this turns out to be your problem, a great resource is available at thexlab.com on various ways of stopping and altering Spotlight indexing.

This is also the step where we would look for other programs taking too many CPU cycles. Sometimes you’ll have a spinning beachball cursor and not be sure of the source. Here’s where you’d check that.

On to step three.

THE SOLUTION

We now take a stop at Applications/Utilities/Console. The console is where applications send data about their current state. You’ll find errors, status and crash information here. The GUI hides a lot of interesting information from you. Some of it is a bit geeky and extraneous but you can pick up a lot of info and understanding about your computer by checking out the console.

So, we open it and I notice these entries….

SoundGrinderCMPlugInFactory-I-Debug
AllocCMPlugInType-I-Debug
SoundGrinderCMPlugInQueryInterface-I-Debug
SoundGrinderCMPlugInAddRef-I-Debug
SoundGrinderCMPlugInRelease-I-Debug
SoundGrinderCMPlugInExamineContext-I-Debug
SoundGrinderCMPlugInPostMenuCleanup-I-Debug

This looks promising…

hmmm, a CMPlugin is throwing debug info. A CM Plugin is a Contextual Menu plugin. Contextual Menus appear when you Control-click or Right-click (yeah, even macs work with two button mice these days) in a “context” that allows their use. Ok, but what is Sound Grinder?

Ahh, yes. Sound Grinder is an audio conversion utility we were checking out to convert some audio clips. Doug had removed the program when he decided to use a different app. But why was I still getting debug info? Sure enough, in /Library/Contextual Menu Items/ a SoundGrinderCMPlugIn.plugin file.

So, we’re definitely suspicious of this file. Let’s remove it. Another quick search for “uninstalling Sound Grinder” revealed:

To uninstall Sound Grinder you can simply drag the Sound Grinder folder to
the trash, and trash the plugin located at: /Library/Contextual Menu Items/SoundGrinderCMPlugIn.plugin. If you
wish to delete the preferences, look in the preference folder for a file
called "com.monkeytools.soundgrinder.plist", and drag to the trash.

We removed the plugin and that cleared up the problem. BTW, Sound Grinder seems like a very nice program and I’m not sure exactly why I was having the slowdown problems that we found related to the CMPlugin, although it probably didn’t help that we had yanked most of the rest of the program from the expected location.

I do think a nice universal OSX uninstall utility for programs that install things outside of the application bundle would be a good thing. I’ve got bits and pieces of no longer used detritus all over the place.

REFERENCE

So, in this case we caught our problem in the triage stage. Sometimes, you don’t find your problem here though. Where to next? I’ve had great success with Jaguar, Panther and Tiger Cache Cleaner from Northern Softworks. It runs a bunch of standard maintenance and utility scripts that tend to ferret out corrupt caches and permissions problems. For disk problems, I recommend DiskWarrior and avoid Norton (mainly for it’s insistence in leaving bits and pieces of itself everywhere, go figure). I’ve also been greatly assisted by John Gruber and his Daring Fireball site. His rundown of the Software Update process is a great piece of info and his font cache problem exposé is at least vaguely the inspiration for this post.

Hope you’ve find this helpful, and here’s hoping your avoiding these gotcha problems in your workflow.