Posts tagged with “”

Enhancing SuperDuper Backups

I’ve been using SuperDuper for a few years now. It’s saved my tuchus a few times and provided tremendous convenience many times. In the last few months, though, I’ve noticed a few things that annoy me after the backup is complete:

  1. Growth
  2. Web Server Conflicts

Growth

I archive to a sparse bundle and those only grow. After backing up a few times, that bundle can get insanely huge. Over time, they actually take up more space than they need, but they can be compacted. I have two separate, bootable backups that I store on a single 320GB external hard drive, so this growth can quickly consume a disk that size.

Web Server Conflicts

I use an Apache instance that I installed via MacPorts. To stop and start that instance, I added the location of its apachectl executable to my path so that I can stop and start the web server the same way that I’m used to doing on my Linux servers. To ensure no confusion, I disable execute permissions on OS X’s native apachectl script. The problem is that OS X expects its apachectl script to be executable and its repair permissions operation makes this script executable.

Since I ask SuperDuper to repair permissions before every backup, the built in apachectl script becomes executable and if/when I have to bounce my web server, the command sudo apachectl restart actually starts the native Apache instance which creates conflicts (they share the same port) and all sorts of preventable mayhem that used to take me a while to track down until I got used to recognizing the symptoms.

Remediation

One of the things I love about SuperDuper is that is provides hooks into its process. These hooks allow me to write a script and tell SuperDuper to execute that script when the backup is complete. So I did.

#!/usr/bin/ruby
require 'logger'
log_file = '/Users/me/Desktop/post-backup.log'
File.delete( log_file ) if File.exists? log_file
log = Logger.new( log_file )
# 
# Compact the MWF backup volume if it's not currently mounted
# 
if !File.exists? "/Volumes/mbp17.daily.mwf"
  # system "hdiutil compact '/Volumes/SuperDuper Backups/mbp17.daily.mwf.sparsebundle' > #{log_file}"
  log.info 'Finished compacting mbp17.daily.mwf.sparsebundle'
end 
# 
# Compact the TTS backup volume if it's not currently mounted
# 
if !File.exists? "/Volumes/mbp17.daily.tts"
  system "hdiutil compact '/Volumes/SuperDuper Backups/mbp17.daily.tts.sparsebundle' > #{log_file}"
  log.info 'Finished compacting mbp17.daily.tts.sparsebundle'
end 
# 
# Ensure that the native OSX Apache install remains
# disabled after permissions are repaired.
# 
log.info 'Disabling execute permissions for OS X Apache components'
system 'chmod a-x /usr/sbin/httpd'
system 'chmod a-x /usr/sbin/apachectl'
system 'chmod a-x /usr/sbin/apxs'

As I mentioned above, I have two backups that run on a schedule. One runs Monday, Wednesday and Friday evenings and the other runs on Tuesday, Thursday and Friday evenings. The backup is currently running cannot be compacted because its volume is mounted. That explains the test for whether a backup image is mounted before attempting to compact it.

Because this is a new process, I create a log on my desktop and write a few things to it just in case there’s a problem. Because it’s on my desktop, my (mild) OCD reminds me to look at it and delete it regularly (read:daily). I’ll remove the log prints once I feel comfortable that everything is doing what it’s supposed to be doing.

Finally, I re-disable the executable permission on the native apachectl script as well as a few other executables that belong to OS X’s built-in Apache instance.

MacPorts, MySQL 5 and the Launch Daemons

Update, 7/29/2009: In response to my question about this on StackOverflow, Mike Richards offered an infinitely better solution. Apparently MacPorts is effectively deprecating the mysql5 +server path in favor of a new mysql-server package. I can’t confirm this personally, but it sounds reasonable enough.

That sounds a little bit like a Harry Potter title, but the content isn’t nearly as entertaining. For the past year or two, I’ve been using a MySQL installed via MacPorts, the (pseudo-) apt repository for Mac ports (get it?) of Unix applications and utilities. MacPorts has been fantastic and I haven’t regretted the decision to move away from either OS X’s native MySQL install or from MAMP, an all-in-one solution that I had used previously. The last few times I’ve installed MySQL, though, I’ve noticed that I haven’t been able to get MySQL to start automatically when I login.

Following Chad Kieffer’s excellent tutorial for installing & configuring a MacPorts MySQL install, I would get myself to the point where I execute launchctl to load the plist file that will start MySQL automatically:

$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

Unlike Chad, I want MySQL to start automatically. Admittedly, my work-life balance sucks; I’m more than likely doing something work-related if I’m sitting behind the keyboard. Given that, the server might as well be ready to respond, right? Except that the plist I’m trying to load…isn’t there to be loaded.

The first time that I did the install, the plist was there and loaded as expected, but the last 2 or 3 times that has not been the case. I don’t know what changed with the MacPorts bundle, but that plist simply isn’t there. Fortunately, I still have my old install around, so I faked it.

If anyone else is having the same issue, here’s how you too can fake it:

  1. Create a directory for the launch scripts.
    $ mkdir -p /opt/local/etc/LaunchDaemons/org.macports.mysql5
  2. Download the files that no longer get installed, mysql5.wrapper and org.macports.mysql5.plist. I’m making mine available since I don’t know where else to get them. Save both files to the directory you just created.
  3. Set the proper ownership and permissions.
    $ sudo chown root:wheel /opt/local/etc/LaunchDaemons/org.macports.mysql5/*
    $ sudo chmod 755 /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper
    $ sudo chmod 644 /opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist
  4. Create a soft link to the newly downloaded plist file in /Library/LaunchDaemons.
    $ cd /Library/LaunchDaemons
    $ ln -s /opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist org.macports.mysql5.plist
  5. Load the plist file, as indicated in Chad’s instructions and duplicated above. For the sake of keeping it all in one place:
    $ sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
  6. Reboot.
  7. Verify that MySQL has started.
    $ sudo ps -ef | grep mysql

You should see output that looks something like this:

    0    65     1   0   0:00.00 ??         0:00.00 /opt/local/bin/daemondo --label=mysql5 --start-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper restart ; --pid=none
    0    85     1   0   0:00.01 ??         0:00.01 /bin/sh /opt/local/lib/mysql5/bin/mysqld_safe --datadir=/opt/local/var/db/mysql5 --pid-file=/opt/local/var/db/mysql5/rob17.local.pid
   74   111    85   0   0:07.48 ??         0:19.75 /opt/local/libexec/mysqld --basedir=/opt/local --datadir=/opt/local/var/db/mysql5 --user=mysql --pid-file=/opt/local/var/db/mysql5/rob17.local.pid --socket=/tmp/mysql.sock
  501  3370  3145   0   0:00.00 ttys003    0:00.00 grep mysql

If you do, then you’re golden. If you don’t, then you probably made a mistake. If the mistake is mine, please let me know in the comments and I’ll make the appropriate adjustments.

Session Interaction with Quicksilver

Although it’s true that, on the whole, I prefer the OS X environment to that of the Ubuntu Linux environment I’ve been using at work for the last few months, the degree of that preference is not as high as I would have ever thought. Nonetheless, I have to confess that I have a tremendous preference for Gnome Do over Quicksilver for OS X. I know, that borders on blasphemy, right?

I prefer Do for a number of reasons that are beyond the intent of this post, but one reason is that I’ve been spoiled by having the ability to logout, restart, shutdown and otherwise interact with my user session. My inability to do so with Quicksilver has begun to frustrate me lately and tonight I finally figured out that Quicksilver has the same capability. Unfortunately, that capability is tucked away and obscured so that it’s not immediately obvious. Session interaction, as well as a few other nice tools, is tucked away in the Extra Scripts plugin.

Another of my frustrations with Quicksilver is the complexity of the interface, but I wanted to know what was in included with this plugin, so I dug it up in Finder. Since the plugin is really just a collection of shell scripts, it’s pretty easy to see what’s in there. Here are some of the highlights:

  • Get your current IP addresses
  • Eject and close the disk tray
  • Logout of your current session
  • Lock the screen
  • Switch to root
  • Put the computer to sleep
  • Shutdown or restart the system
  • Control the system volume
  • Empty the trash

More is available, but these are the functions that I thought were the most interesting or potentially useful to me. I can’t find a way to see a list of functions available in the Quicksilver UI, but if you’re interested you can see what’s included using Finder:

  1. Open the Quicksilver preferences
  2. Go to the Plug-ins “tab”
  3. Click the gear icon at the bottom of the window
  4. Select Show Plug-ins Folder
  5. Right click on the Extra Scripts.qsplugin “file” and select Show Package Contents
  6. Open the Resources/ExtraScripts directory
  7. Explore the subdirectories

Most of the scripts are pretty descriptively named. It should be pretty apparent what functionality they provide.

When SSH Public Key Authentication Fails

I’m no Sys Admin, but I connect to enough Unix machines often enough that enabling public key authentication is a real time saver. For those that may not know, public key authentication allows a user to login to another machine via SSH without a password. I’ve written a bit more about the technique itself in my archive. The other day, in the course of setting up authentication for several machines at work, I noticed that it worked for most of the machines but failed for a few others. After spending a little over an hour checking and double checking the files in my ~/.ssh directory, I spent another hour comparing files on the machines that weren’t working with the ones that were. Everything was precisely the same.

Except that it wasn’t. Evidently I neglected to read my own earlier post, specifically step 5. I had no idea that permissions were such a hot button, but it makes sense. The permissions on my ~/.ssh/authorized_keys file were 664. The boxes wouldn’t let me login because the file was writeable by someone other than me (at least in principle). As soon as I changed the permissions to 644, I was able to connect just fine.

Of course, I realize that this is by design and a very good thing, but I wasn’t expecting it so I stumbled over it.

Mac Owners, Freak Out Someone You Love

My girlfriend works from home on Fridays. I do not. I do, however, leave my Mac powered on and active during the day so that I can SSH in and access files from the office if I need to do so. Last week, knowing that she would be sitting near said computer, I decided to mess with her just a little bit. To do so, I SSH’d into the Mac and used the say command:

$ say "Hello Tricia, this is God. Have you been touching yourself again?"

I personalized the line from Real Genius, but you get the idea. A very nice, disembodied voice that goes by the name of Alex spoke the words aloud as if there was someone in the room with her. She said she jumped about a six feet and had to crawl back into her own skin. She also said that she found Alex’s voice disturbingly sexy. Disturbing to whom?

← Earlier Posts Page 1 of 7