More Lion teething pains
October 29, 2011 at 8:51 PM by Dr. Drang
So I walked into my office earlier this week and was greeted with a problem: over a hundred records in our time and expenses billing database had bad data in one of the fields. The corruption had just occurred when one of my partners was creating an invoice.
I had a pretty good idea how to de-corrupt the records—it’s a FileMaker database that I created over 15 years ago and have been using and maintaining ever since—but since the error occurred at the beginning of the day, I figured the easiest thing would be to grab the previous day’s backup and revert to it. The backup is done every afternoon by FTPing files from the accounting computer to my office computer (which is itself backed up through Time Machine and every night via SuperDuper!). It’s a rolling backup: Monday afternoon the files are sent to a monday subdirectory, on Tuesday they’re sent to a tuesday subdirectory, and so on.
I went to my computer and dug into the appropriate subdirectory only to find that the backup files in it had modification dates of two weeks ago. I looked in the other day-named backup subdirectories and found basically the same thing. Their modification dates were different, but they were all at least two weeks old.
Shit. Shitshitshitshitshit. Now I had two problems to fix, neither of which were on my schedule for the day.
As it turned out, correcting the screwed up records in the database wasn’t especially hard. I went about it very slowly and deliberately, taking notes and thinking through every step twice because I was, in effect, working without a net. In twenty minutes or so the database was back in shape.
Which left me with the second problem: the backup failure. The accounting machine is running Windows, and it uses a batch script—yes, written by me several years ago—to FTP the files across our intranet to my computer. Why the hell would the backup script have stopped working two weeks ago?
I was about to open up the script when it hit me. Two weeks ago was when I installed Lion on my office computer. I’ll bet the upgrade turned off the FTP server.
So I opened the Sharing preference pane to turn the FTP server back on, but the option for FTP has been taken away.
It didn’t take long to find a command-line way to launch the FTP server. I got this command from Daniel Smith’s blog:
sudo launchctl load -w /System/Library/LaunchDaemons/ftp.plist
This turned on the FTP server for the current session and set it up to relaunch every time the computer starts up. I’m not a real expert on launchctl, but I believe the -w option is what makes the loading persistent across reboots.
Update 10/30/11
I just learned via Twitter that PuTTY has a command-line SCP client. (Thanks, @mackenab!) I used PuTTY a bit many years ago but never knew about this capability. If I can get it working on the Windows machine, I’ll be able to turn off my Mac’s FTP server and just go with SSH.
Later that same day I ran into another Lion-related problem. I printed out some labels using one of my label scripts, and the printing didn’t match up with the positions of the labels on the sheet. This time I knew exactly what the problem was. My scripts use groff, and by default, groff outputs PostScript formatted for A4 paper. I had, a couple of years ago, made a site-specific change to format the output for letter-sized paper. The Lion upgrade had overwritten my change.
So I made the change again, which consisted of saving a file to /usr/share/groff/site-font/devps/DESC with these contents:
res 72000
hor 1
vert 1
sizescale 1000
unitwidth 1000
sizes 1000-10000000 0
styles R I B BI
family T
fonts 9 0 0 0 0 0 SS S ZD ZDR
tcommand
postpro grops
broken 0
papersize letter
print lpr
It’s exactly the same as /usr/share/groff/1.19.3/font/devps/DESC except for the papersize line. When this file is present, groff uses it for configuring PostScript output, not the one in the 1.19.3 tree.
Frankly, I’m a little pissed at Apple for making me do these things. It’s like when I found out that Lion had erased all the Python libraries I’d installed in /Library/Python/2.6/site-packages under Snow Leopard.
I realize that, in general, everything in the /usr directory tree that isn’t in /usr/local is fair game for getting overwritten during an upgrade. But my changes were in a site-specific directory—that’s what the site-font and site-tmac subdirectories in /usr/share/groff are for. Apple should have left them alone.
I guess you could argue that Unix site-specific configuration files are too diverse and in too many places for Apple to have a special rule protecting each and every one. But that doesn’t explain the turning off of my FTP server. That’s controlled by launchd, which Apple invented specifically for OS X. Regardless of Apple’s decision to remove control of the FTP server from the Sharing pane, there’s absolutely no reason for it to turn off a service that I had specifically turned on using its own system.
I’m hoping I don’t run into more upgrade-induced problems, but I wouldn’t bet on it.
