So a couple of interesting updates on the last.

"Verifying" the Minecraft.app dir seems to have worked on one machine. I assume it won't work if the program updates its dependencies. That's as it should be. I'm a little worried about maybe having "authorized" Java in general. That's the hard part about doing this stuff disconnected; it's hard to remember your last state. You will make mistakes. Lots of l337ers have gotten caught that way.

On another OS X foldy-slab, I have a guest account, fairly restricted. Didn't try the "verify" trick. Do get a "this application was downloaded at" warning every time. OK.

So here are sensible, safe instructions for starting Minecraft on OS X:

1. Open the app.
2. Click through the "this application was downloaded at" dialog, if you get it. But please read it and see if that was when you downloaded it. Possibly not for the last time.
3. Get out of fullscreen mode, if you are in it.
4. Go to Multiplayer.
5. Approve the Application Firewall changes. Possibly not for the last time.
6. Dig.

Now for the fun stuff. FreeBSD now has a minecraft port. Not necessarily up-to-date. They've had issues with ports due to a break-in last Nov-Dec. They are being appropriately paranoid. No idea if that is why the port can lag, but it could be. End result is that the minecraft_server.jar can have bad checksums. You can hack the minecraft-server/Makefile and minecraft-server/distinfo with new info, as I did, to upgrade from 1.4.6 to 1.5.1. No biggie, if you are using portstnap (of course you are), your hack should get blown away next update.

Anyway, once you have it installed once, upgrades are no biggie. And the main reason to use the port at all is to get the startup script and a semi-sane way of handling data and configs. Most data stuff is in /usr/local/share/minecraft-server. But configs are symlinked into /usr/local/etc/minecraft. Enable in /etc/rc.conf in the usual way. Now the minecraft service is started inside a tmux session, as the user mcserver.

Oh, sorry, I said the fun stuff. That stuff was good, but here's the fun part.

First, set up /usr/local/etc/sudoers.d/minecraft:

# Can do anything as mcserver
User_Alias MCADMIN = cooluser, root, mcserver
MCADMIN ALL=(mcserver) NOPASSWD:ALL

Isn't that fun. Now cooluser - presumably you - can run any command as mcserver. Not much danger there, it's a restricted user to begin with. Now cooluser can do this in a shell rc file (bash, zsh):

# Minecraft
alias mcadmin="sudo -u mcserver tmux attach -t minecraft"
alias mcbackup="/usr/local/share/minecraft-server/mcbackup.sh"



Now cooldude (hey, got any pizza?) can access the minecraft server console, and make timestamped backups (details of tarfiles as an excercise for the user). Oh, but what about that mcbackup script?

#!/bin/shMCDIR=/usr/local/share/minecraft-serversudo -u mcserver tmux send-keys -t minecraft:0 'say SERVER BACKUP STARTING. Server going readonly...' C-m
sudo -u mcserver tmux send-keys -t minecraft:0 'save-off' C-m
sudo -u mcserver tmux send-keys -t minecraft:0 'save-all' C-m
cd $MCDIR
sudo -u mcserver tar zcfv backups/world-`date "+%Y.%m.%d_%H.%M"`.tbz world
sudo -u mcserver tmux send-keys -t minecraft:0 'save-on' C-m

This alerts users what the admin is doing. Then it turns off auto-saving, so that the backup can proceed without internal changes resulting in an inconsistency (same misfortune as trying to back up a database from a filesystem backup). In other words, you don't want the minecraft server saving a chunk of the world in the middle of a world data file you are backing up. You have no way of knowing what that might do. If you don't know what I mean, look under world (or whatever you call it) and try to figure out what those files do, and what's inside them. Think chunks of space, changing while they are being copied. So let's not do that. Instead, we stop auto saving, then save everyting at once to be consistent, then back up the whole world, then put things back to normal. It would be polite to announce that we are done, I guess.

Oh, see that "backups" directory? You want to create that, and do this so mcserver user can write to it:

cd /usr/local/share/minecraft-server

mkdir backups

chown mcserver:mcserver backups

chmod 775 backups

That makes the directory to hold the backup packages, makes it owned (ch-ange own-er) by the mcserver user, and ch-anges modification rights to be "user can do all, group can do all, others can look".

That's a bit of UNIX to learn Minecraft. But if you've used the Minecraft console (the in-game one, not the admin one), you've already learned a few things: tab to complete a command with a guess, and up-arrow to scroll through the history of commands. Those are common to a Windows CMD console too.

Anyhoo. Be a geek. It's good for you. You can be one who lives in a world made by others, or be a maker.

Minecraft and Firewalls and OS X

Lots of people have trouble connecting LAN games on Minecraft. Recently, that's especially true of OS X. The information out there is so bad, I'm going to put down what I can find out (in a slightly flu-addled state).

Here's some suggestions I've seen - all wrong. I'm sure I'm wrong about some things, but I won't be wrong and certain.

Just click "allow incoming connections"

Problem one, you have to do this every time. Every time Minecraft starts, it requests to open a port, and it's a random high port.  From monkeying with netcat (yeah, there's a good app to permit), it looks like the changing port number isn't the issue.

The second problem is that the dialog to allow the connection disappears behind any other window nearby. If you have full-screen configured, that means Minecraft itself obscures the dialog. If you are NOT in fullscreen mode, the dialog pops up when you click "Multiplayer". So there's one method. You'd think this would also work when opening a world to the LAN. It does, for a fraction of a second, then the dialog gets lost.

So here's an observation. Modern OSen still suck at modal dialogs. On Mountain Lion and Windows 7, I still have to go searching for dialogs all the time. They blink out of site, and aren't regular windows so you cant window-switch for them. WTF.

Anyway, no obvious solution here.

Open your firewall completely

Actually, as a short-term solution, this isn't horrible, maybe the best idea of the ones floating around. Not such a good idea, as eventually you will forget to turn it off.

Add Java to the allowed applications

This makes sense because the Minecraft application itself is just a fancy loader for Java, like the exe on Windows. So something about approving the application approves the stub loader, but Java is still untrusted, as it should be.

This is the worst idea of the lot because Java.

I'm not even going to test this one.

Change your application firewall settings from the command line

I found a page showing how to manipulate the ApplicationFirewall from the command line. Doesn't work, but I bet it would if I let Java get approved. Yeah, no.

Configure IPFW

That's a nice idea. I've got plenty of nice IPFW configuration sets for FreeBSD servers. However, this would mean disabling the application firewall and using this instead. It would definitely work, but you'd have to know OS X apps pretty well to know what ports you want.

Also, it's deprecated. OS X has moved to pf for more flexibility. And that's without even getting to the wrong or misinformed rules floating around. Also, which port are we allowing here? Minecraft keeps changing its upper port, and I don't even know what it's doing to scan the LAN. 

For some reason, it's not all that easy to find out how Minecraft scans the LAN and makes connections. I tried with tcpdump. I've got the flu, I shouldn't be doing this. I tried Google. WTF, these aren't state secrets.

The Real Problems

It's amazing how many little things add up to a problem.

1. Minecraft is popping itself up and hiding the modal dialogs.
2. Modern OSen still suck at handling modal dialogs.
3. Minecraft uses high ports for incoming traffic.
4. Software documentation is getting worse. I'm picking on OS X here. Between "for dummies" documentation and developer documentation, there's not a lot of good documentation.
5. Search engines are getting worse at finding documentation. The dark side of Page Rank is its reliance on popularity.  Ignorant people commenting on popular sites get better results than actual documentation.

But really, how hard can it be to find documentation, right? Find out how Minecraft scans for LAN games. Find out how the Application Firewall works. Find out how to use pf rules to bypass the Application Firewall for particular ports.

The Minecraft Wiki contains information on how MC scans for LAN games. It was hard to find.

The Right Way

Pretty sure it's going to be manipulating PF. Using sudo or a root shell:

hostname /etc/pf.anchors} pfctl -s rules
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "com.apple/*" all fragment reassemble

Interesting. So Apple is using pf's "scrub" to clean up TCP packets, then passing everything to an internal ruleset. Let's see what's in there.

anchor "com.apple/*" allhostname /etc/pf.anchors} pfctl -a com.apple -s rules
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "100.InternetSharing/*" all fragment reassemble
scrub-anchor "300.NetworkLinkConditioner/*" all fragment reassemble
anchor "100.InternetSharing/*" all
anchor "200.AirDrop/*" all
anchor "250.ApplicationFirewall/*" all
anchor "300.NetworkLinkConditioner/*" all

Well isn't that interesting. It does look like pf is the infrastructure. So a ruleset could be created to allow specific bypasses. A nice one would be something that could be turned on and off just for Minecraft.

Some other playing around suggests that pf isn't enabled, so those com.apple anchors are probably meant to replicate whatever OS-level stuff is being done. Maybe if I enable it, I can actually see what rules are in those sub-rulesets. I've never worked with pfctl anchors so far. That's enough stream-of-flu-state for now.

UPDATE: Code signing is a problem. I've had some fun playing with pf, but the bottom line is that the socketfilterfw seems to kick in regardless of pf rules. Here's an explanation of why some apps keep triggering the firewall dialog. I kinda get it. Kinda. I checked with "codesign -v" and it doesn't think much of Minecraft's sig. Minecraft does a self-update on start, which is probably why it kills the original allow/deny dialog. Essentially, don't start in fullscreen mode. Oh well.

If I have time, I'm going back to FreeBSD. On interesting thing is that /usr/libexec/ApplicationFirewall/com.apple.alf.plist has a section called explicitauths. It includes things like python, ruby, java... and nc. Which I had used for testing. At some point netcat was triggering the socketfilterfw. I went through various cycles of disabling and re-enabling it. Now it does not trigger it, even though it is not listed in the Preferences pane, and even though an attempt to reach it from outside gets blocked and logged (while localhost skips it). That's weird, but annoying stuff like that happens when you muck about, and a reboot could reset it.

The code that powers this blog is never finished. It's an ADD thing partly, it's a life is crazy thing very much, but it's also because it's a playground I get to test out new ideas from time to time.

That being said, I will attempt to redo this code in, oh, the next 6 months. Using Django's Class-Based Generic Views, I can do it much better now. Really, a big part of how I made it the way I did was for better browsing possibilities than blogs allow. The date-based portions of URLs are all functional "archive" views. The next and previous links are relative to the year/month/day of the current page. It's made to be sparse, so that the previous and next links skip over empty spots.

So with the Class-Based views, either the date-based ones or the regular ones with date mixins, it's almost all there with little to no effort. All it really takes is a little extra context work around get_dated_items. One tricky spot could be allow_future. For me it's neither on nor off; I can see my own posts from the future, if I'm logged in, labelled as not-yet-published.

Of course, I've got to get my idea for the generics-based admin site done first.

During today's drive I tried a comparison of mapping aps. iOS still holds up well in terms of usability, whatever the data issues are. But a couple things about Google's app stood out.

The updates on your progress (10 miles to go, 5, etc) are less frequent than Siri's intrusions. At first I liked it, but then I didn't notice anything between 10 miles and half a mile to go before the next turn. I don't know if speed is taken into account, but there are many places where half a mile is not enough. I'll need to use this more and see how it performs.

What I really appreciated was the prominence of route numbers. Route 302 I know. I didn't know (or really care) that it's Roosevelt Trail along part of the way. It's nice to know both, but for purposes of navigation, the route number is better outside of urban areas. In urban areas, the reverse is true; I've never heard the West Side Highway called Route 9A (nor would I try taking that all the way to my house, though I probably could). Again, I'll need some more sampling in different locations to see how the comparison fares. I just find it annoying to hear Siri calling out local road names when I'm looking at nice prominent signs with route numbers.

Following my post on iOS Maps, it occured to me that Google's Ingress game is a fantastic way for Google to get people collecting WiFi data and matching it with good GPS data. They can even put the thumb on the scales when they want to motivate someone to re-sample for them by making them lose control of an area.