Anthony Hoppe

We still use FileMaker Pro 6, and every so often something will cause it to become as responsive as frozen molasses. For the longest time I had no clue why this was happening, but knew that a reboot always solved the problem. Some days FileMaker would be as happy as a clam, but other days it would be angry and angry often (aka multiple reboots).

I didn’t know how to troubleshoot this since, a) there were no apparent “errors”, and b) it felt extremely random. Fortunately, a co-worker of mine encountered the same problem while I was watching him work with a database. I noticed the problem occurred right after he copied the contents of a Word document to the clipboard. I did a quick Google search for clearing the clipboard, and found the following command:

pbcopy < /dev/null

Issuing the above command clears the clipboard and consistently resolves the FileMaker slowness problem! The question is, why is FileMaker Pro 6 so sensitive to the clipboard contents?

I upgraded to Lion on my personal Mac Mini at home. I’m slowly adjusting to the numerous changes the new OS brings, but there was one that I absolutely could not live with. In OS X Lion, the scroll direction is transposed! I suppose if I was using an Apple Magic Trackpad it would make sense, but on my Logitech V270 mouse, it doesn’t. Scrolling up is down, and down is up. Thankfully, a trick from Tech-Recipies fixes this.

Open a Terminal window and enter the following command:

defaults write ~/Library/Preferences/.GlobalPreferences com.apple.swipescrolldirection -bool false

Log out and log back in…and voilà! Scrolling is “normal” again.

UPDATE: After installing Lion on a laptop, I discovered that this is an option under the trackpad settings. Apple, why don’t you offer this setting for computers without a trackpad?!

When trying to run apt-get update on one of our Debian boxes, I would get the following error:

W: GPG error: http://security.debian.org stable/updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AED4B06F473041FA
W: You may want to run apt-get update to correct these problems

The following fixes this (as root):

gpg --keyserver pgpkeys.mit.edu --recv-key AED4B06F473041FA
gpg -a --export AED4B06F473041FA | apt-key add -

Note, replace “AED4B06F473041FA” with whatever is after “NO_PUBKEY” in the error message.

I love vi/vim, and love the folks at www.viemu.com for creating this awesome cheat sheet!

vi/vim Graphical Cheat Sheet

I put our tried-and-true 2010-2011 Windows XP image on one of our newer Unibody MacBooks (13-inch, Late 2009). Right away, the trackpad didn’t function! This made zero sense as this image was used on hundreds of identical MacBooks with zero problems!

I poked around the Device Manager and found that there were two “Touchpads” detected. Both were under “Human Interface Devices” with an exclamation point. The error was simply “This device is not configured correctly. (Code 1)”. I tried all kinds of different processes with no success, until I did the following:

• I changed the driver for both “Touchpad” devices to the generic driver (listed as a “compatible driver” when manually picking the device driver). At this point, the trackpad came to life minus any multi-touch features. After this was done, both devices changed became generic “USB Human Interface Device” devices.
• Next, I changed the driver for both “USB Human Interface Device” devices to the “Apple Multitouch Trackpad” driver. The driver switch was successful, except multitouch features still didn’t work.
• Lastly, I rebooted. Volla! The multitouch trackpad worked!

Once the trackpad was working properly, the two devices became “Apple Multitouch” and “Apple Multitouch Mouse” respectively.

We use the open source version of Zimbra Collaboration Suite for e-mail and calendaring services. It meets all of our needs wonderfully. The only downside is that, with the open source version, there is no support for doing live backups.

I’ve written a script that will perform three rsyncs over SSH from our production Zimbra server to a “hot spare” mail server we have. However, I’ve discovered that with the amount of traffic we have and the amount of time it takes rsync to initially index, once it starts the process of syncing files that it thinks exist are no longer, and new files are created that it’s completely unaware of (since it builds the file list, then copies). I was worried that if we needed to rely on this backup in the case of a server failure we’d run into problems.

So, I modified the script to do the following:

1. Perform the initial rsync while Zimbra is live
2. Stop Zimbra services
3. Perform a secondary rsync
4. Perform a third rsync to catch any possible odds ‘n ends (though it looks like this may not be necessary)

I set up a cron job on our backup server to execute the script at 3 AM. Everything looks great, except for one weird problem. It looks like it took 30 minutes for ‘zmcontrol start’ to complete! I’m not sure why, and I’m suspecting that maybe the SSH session simply hung.

The only requirements for my script to work are rsync and password-less login using SSH keys so that the root user on the backup server can SSH into the production server as root and as zimbra without being prompted for a password.

This article explains how to set up passwordless login. However, you will discover that you cannot use the ‘ssh-copy-id’ command for the zimbra user. Simply go into the ~/.ssh/authorized_keys file of the root account of your production server and copy the entry added by the ‘ssh-copy-id’ command and paste it into the zimbra account’s ~/.ssh/authorized_keys file.

Zimbra rsync Backup Script

We set up a good portion of our Intel Macs as dual boot systems running OS X and Windows XP. Up until 10.6, we used Bombich’s NetRestore Helper to create and deploy our images. Since it was discontinued long ago, and does not support Snow Leopard (trust me, I’ve tried to make it work!), I had to whip up a solution. There are solutions out there, but I didn’t really like any of them. Through some nifty BASH scripting I whipped something up. We have a process that is fairly efficient and works.

Anywho, it was recently pointed out that when a user holds the option key at boot to select whether or not they want to boot Windows or OS X, the OS X partition no longer shows up as “Macintosh HD”. It now shows up as “EFI Boot.” I didn’t think much of it, but soon realized that this will confuse some people. I Googled around a bit and found this solution:

In Terminal with “sudo” (or via Send UNIX Command in ARD) type the command:

bless --folder /System/Library/Coreservices --bootefi

and the partition now displays as it’s name, and not “EFI Boot”.

I’ll be adding this to my imaging script ASAP.

One of our Xserves running 10.4.11 developed a problem with Apple Remote Desktop. The service would crash and restart almost every 15 seconds. Other than being annoying, this caused CrashReporter to generate an absurdly huge log in /Library/Logs/CrashReporter/ARDAgent.crash.log, (which currently is 8 GB). I never really had the time to troubleshoot this, so I’d simply delete the log when I received alerts about the startup disk being almost full and then move on.

Well, the server developed another unrelated issue with Open Directory. As a blanket “fix”, I decided to boot the server into target disk mode (it’s headless) and run DiskWarrior on all of its partitions. As I expected, DiskWarrior found a good amount of directory errors and repaired them. It also found a few corrupt plists that it was unable to repair.

Most of the corrupt plists were related to drivers for printers we don’t nor will ever own, but one of the corrupt plists was in /Library/Application Support/Apple/Remote Desktop/Client/CacheUpload.plist. I deleted the file, rebooted the server, and ARD was happy again!

We recently discovered that when you browse to “powerschool.mpcsd.org”, browsers were redirected to “http://powerschool.mpcsd.org/public/” when they should be redirected to “https://powerschool.mpcsd.org/public/”. After talking to Pearson technical support and not finding an answer there (it’s not normal behavior), we developed a temporary solution of our own.

Adding the following JavaScript function to the default page under “/public/” and having it called on page load did the trick.

function redirect() {
	var browserURL =  window.location.href;
	var first5 = browserURL.substring(5,0);
	if (first5 == "http:") {
		var fixedURL = "https" + browserURL.substr(4);
		window.location = fixedURL;
	}
}

Translated into English:

• First, it grabs the URL in the browser window.
• Second, it strips all except the first 5 characters of the URL.
• Third, if the first 5 characters equal “http:”, it captures all but the first 4 characters of the URL and replaces them with “https” and redirects the browser to the new URL.

Pretty simple, isn’t it?

I just finished writing a simple little script that backs up our website, web related MySQL databases, Apache configs, and Pure-FTPd configs to another server (which then the files will be written to tape). A simple tarballing of the various directories and then copying them over to a CIFS share on the other server (the other server runs Windows). I have a backup user account that I use with scripts like this, but I was having a heck of a time getting it to run properly.

Normally, when mounting a CIFS/SMB share in a BASH script, I’ll use the following command:

mount -t cifs //server/share /local_mountpoint/ -o user=backup_user password=backup_password.

However, the password I gave the backup user included an exclamation point which confused the heck out of BASH on our web server (which runs Debian). The simple solution would be to change the user’s password, but it’s already in use on other OS X servers and I don’t want to have to go changing configs on a bunch of servers!

After doing some research, every possible answer I found did NOT work. I decided to look at the man page for mount.cifs one last time and noticed that you can specify the password for a user in two ways. 1) being the method above, and 2) being user=backup_user%backup_password. This worked beautifully! Why? I have no idea, but it solved my problem!