More Lion teething pains

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.

Lion Sharing preference pane

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.


4 Responses to “More Lion teething pains”

  1. Brian Enigma says:

    I understand that your FTP situation is a special case, but outside of certain controlled situations (trustworthy LANs, anonymous/passwordless), it is insecure enough that it really should be phased out for more secure alternatives. You can perform the same actions via ssh/scp/sftp without plaintext passwords floating over the wires (or, gasp, over WiFi). In fact, with no passwords at all if you set up certs and keys. I’m glad that Apple finally removed FTP from the UI. I’m also glad that OS X, being Unix-based and flexible, lets you reactivate the system’s FTP if you are in one of those special cases where FTP is a good (or at least, not bad) idea. …I’m NOT glad that the removal of the FTP service came as such an underpants-staining surprise. That part rather sucks, though I’m glad you were able to recover your data.

  2. Donald says:

    Just a suggestion but maybe consider virtualenvwrapper for pythons packages. They live in your home directory then.

  3. Dr. Drang says:

    I agree with you, Brian, for the general case, but this is a small, wired, internal network with only one SSH hole to the outside world. FTP seems secure enough, but if there’s a scriptable SFTP or SCP client for Windows that’s easy to install, I’m all ears.

    Commenters in the linked Python post suggested virtualenvwrapper, Donald, and it does seem like a good idea. I just haven’t gotten around to it.

  4. Jamie says:

    This reminds me of some changes Sun made with, I think, 2.6. Any change, even for the better, causes pain to someone. Sucks if you’re that someone, as I have been. (It is far worse in the Linux world, believe me.)

    My main complaint with Apple is the wait-and-see approach to these changes - that works with workstations, surprisingly well, even if it costs users some time here and there. But when you’re doing server-ish things - automation that one counts on - having a list of behavioral changes becomes important.