30 November 2014

The difficulties of operating an Olive Garden on the moon

(This is satire, fan mail, and a get-well card for Maureen Johnson. Here is some context for this nonsense.)

Maureen Johnson,

It is my displeasure to report that--at least temporarily--I've been forced to close my Olive Garden franchise on the moon. As you've always been such a strong supporter, I felt I owed you an explanation.

As the owner of many fine dining establishments in a variety of locales, I've found that running a restaurant has many challenges under the very best of circumstances. Running a restaurant on the moon has a few extra difficulties, and it goes far beyond the gravity problem (although breadsticks are notorious for floating right off the table).

There's only one health inspector on the moon (which caused plenty of scheduling problems), and he is MONSTROUSLY corrupt. When I refused to pay his "protection" fee, I found myself featured prominently in the "health inspection failures" report of the local newspaper. When I asked a fellow lunar restaurant owner how she dealt with the inspector, she (the restauranteur) said that she would just pay him. She regarded it simply as a business expense. I won't reveal which restaurant, but let's just say that I often imagined the inspector leaving that establishment, gleefully counting his money on his way out the door, saying "I'm loving it."

(This particular problem--the health inspection racket--seems quite specific to the moon. For example, even when the health inspector [DIFFERENT inspector] found at my Red Lobster restaurant in Atlantis that the kitchen, bathrooms, maitre D' station, bar, and dining area were LITERALLY CRAWLING with shrimp that weren't on the menu, he was entirely professional about the whole thing.)

(I had to close the Atlantean Red Lobster as well, but that's a different story. In retrospect, a seafood restaurant in Atlantis may have been a poor choice. Those folks prefer barbecue.)

Rampant smash-and-grab theft caused a problem with parking at the lunar Olive Garden. I've seen this problem at my Chili's restaurant on comet 67P/Churyumov-Gerasimenko, but it's far worse on the moon, where that nice little Philae lander would likely have been relieved of its harpoons before the driver even got his or her drink order. (There's a nearby pawn shop whose owner doesn't ask a lot of questions.)

Getting a liquor license on the moon is tough. All applications have to be approved by a council whose members are primarily other restaurant owners who don't want any new competition. Also, in a place where one day is nearly thirty times longer than on Earth, "Happy Hour" can result in some awfully thin margins. I thought serving cold beer at an Applebee's on Antarctica's Ross Ice Shelf would be difficult, but that's a cake walk (turns out that penguins are quite fond of Guinness).

And just try getting anything other than blue cheese on the moon. I mean I love blue cheese, but some of my customers prefer Parmesan on their salads. For someone who managed to find inexpensive chopsticks for a P.F. Chang's in freaking Asgard, you'd think cheese wouldn't be that big a deal, but it's a supply problem I still haven't solved.

So I'm hoping that this is a temporary setback. I've got a lead on a fromager somewhere in Mare Frigoris, I'm investing in some security cameras for the parking lot, and I'm sure the other problems will sort themselves out one way or another. I hope to reopen soon and that you'll honor us with your patronage. Thanks for all your support.

Management, Olive Garden on the moon

25 October 2014

CentOS 7, openssh/openssl

Yesterday I finally gave CentOS 7 a try as a Virtualbox VM. (In the following, when I talk about a guest or a host, it's in the virtualization vernacular.)

I did what I usually do with VB guests: I gave it two network interfaces. The first is configured as NAT, so that the guest can reach the internet without the host needing a second IP for a bridged interface (bridging would be fine at home, but might cause me some trouble at work). The second is configured as host-only with a static IP, so that the host (and other guests) can initiate to the guest. (There’s probably a much easier way of doing this, but it’s worked so far.)

My CentOS experience is primarily with CentOS 5, and several things were really different in C7. (CentOS and Red Hat documentation is typically pretty good and will no doubt help me through some of the following. These are just some of the things I’m stumbling on at the moment.)

There’s no /etc/cron.daily/rpm, which creates a list of packages in /var/log/rpmpkgs. I use that a lot, so I copied that over from a C5 box.

I had a pretty hard time with networking. Neither interface seemed to come up on its own at first. I had to set ONBOOT=yes in the corresponding /etc/sysconfig/network-scripts files, and then the second interface mangled the first interface’s NAT connection. I ended up setting ONBOOT to yes for the first interface (the NAT connection) and to no for the second (host-only) interface. I put an ifconfig statement in rc.local to bring up the second interface, and that (eventually) worked.

ifconfig, netstat, and probably a bunch of other useful stuff is in the net-tools package, which isn’t included in a minimal install. And although there’s an rc.local, it’s not executable, and won’t run at boot until you “chmod +x” the thing.

And the interface names are now really weird. Instead of something memorable, traditional, predictable, and sensible like eth0 and eth1, now they are called enp0s3 and enp0s8. (I just had to look those up, because I couldn’t remember them.)

The new C7 guest has a very long list of iptables rules, but /etc/sysconfig/iptables doesn’t exist, so I don’t know where those rules are coming from. Thankfully port 22 is open by default, but I don’t like to run openssh on the default port, so at some point I’ll need to figure out how to fiddle with iptables rules.

I use GNU screen all the time. (I know the cool kids like tmux, but, frankly, screw them.) I typically have a screen session in which I’m logged in to several different hosts, and each window is named for the remote host. C7 rewrites the window name in screen, so “Ctrl-A ‘, hostname” no longer works. I don’t know if I need to (somehow) tell screen (on my Ubuntu host) not to allow the window process to rewrite the window title, or if I need to (somehow) tell bash in the C7 guest to be less assertive.

I’m also having some trouble building openssh from source in C7. The version of openssh that comes with C5 lacks some desirable features in the newer versions, so we tend to build it from source. In just the last version or two of openssh, something has changed such that it won’t build against the version of openssl that comes with C5. So the other day (before messing with C7) I built the newest version of openssl on a C5 box and built openssh against that. That worked, but I see now that by default openssl doesn’t create shared libraries, so the openssh I built linked to openssl statically (which made sshd nearly three times bigger than a dynamically-linked sshd).

So far I’ve been unable to build openssh against a source-built openssl on C7. I get one error if I try to link statically, and another error if I try to link dynamically. The version of openssl that comes with C7 is pretty current, so I could just build against that and probably have no problem. Likewise I could just use C7’s version of openssh. But although I’ve enjoyed the stability of C5, everything about it is pretty old at this point. I think that in the future I’d like to build many or all network services from source. Since openssh, apache, stunnel, and several others need openssl, I’d like to keep that current, too.

So I have some work ahead of me. I think C5 hits end-of-life some time in 2017, so I’ve got some time, but the C5 EOL will probably sneak up on me if I let it.

02 May 2014

PHPUnit via phar with suhosin

The PHPUnit developer has announced the end of life for the PEAR installation method for PHPUnit. So I tried the phar method, but phpunit (and phar) would fail silently. After a little searching, I found a useful post* suggesting that suhosin might be the problem (I only have PHPUnit on my development platform, but I also have suhosin there, so that it more-or-less matches production). That post's suggestion of adding suhosin.executor.include.whitelist=phar to php.ini did the trick.


*That post is for an entirely different package, but it was the same problem I was having.