Skip navigation

Monthly Archives: February 2013

Last week, I attended a webinar (I don’t like that word) presented by Meraki on the subject of BYOD solutions in a K-12 environment.  The presentation was interesting, certainly, but perhaps the best part was that, as a technology professional and as someone who makes purchasing recommendations for an organization with a budget for technology, I qualified for getting a free access point from Meraki.  Specifically, they sent me an MR12 access point and gave me a free several-year license for their cloud controller to go with it.

In case you don’t know Meraki’s deal, they make a full range of network hardware–APs, switches, and security appliances–which can be managed through the cloud from anywhere.  They also claim that, once you have your cloud controller set up, you can configure a new AP in as little as 15 minutes.  These are things that I like.  I also like getting free things to try out, so I was happy to get an opportunity to evaluate their hardware.

Simple packaging makes me happy.

Nothing superfluous here.

First of all, simple packaging makes me happy.  The box was just big enough for the AP, some mounting hardware, and a bit of padding to keep the thing safe.  No excess packaging.  There was barely any paper literature included in the box, either–just a single piece of paper listing the contents of the box and explaining, in short, that in this digital age, it’s stupid to print out documents that most people are going to throw away or lose anyway.  The access point itself seems to stick to this philosophy as well with a very spare aesthetic that I imagine would be next to invisible when deployed.

(Note, you don’t hear me talking in this unboxing video because I hate hearing my recorded voice and because narrating unboxing videos just seems awkward to me.)

So what happens after you get the thing out of the box?  Well, in my case, a lot of frustration to begin with.  My initial attempts to configure the AP as if it were any other of our APs, putting it on our control network with a static IP, putting it in bridge mode so that clients connected through it are on the LAN, and setting it up to authenticate against our RADIUS server, then making sure that the switch port it’s getting plugged into is associated with the right VLANs.

Then I plug it in and nothing works.  Sure, the power came on and I could see the AP on the cloud controller page, but the controller was reporting that the AP had never connected to the cloud controller, and the lights were flashing in a way that told me that it was getting a bad gateway.  That ain’t no good.

Well, I read through a lot of documentation, tried some things, and basically frustrated myself more working on it while during the afternoon when I kept on running off to attend to more urgent matters.

Wawa travel mug for scale (and because it was there first, and I'm not kicking it out of its home for some upstart AP).

Wawa travel mug for scale (and because it was there first, and I’m not kicking it out of its home for some upstart AP).

Today, after some more fiddling with the firewall and quiet swearing, I decided, what the hell, I’ll just plug it in to a regular network port, not trying to put the thing in Bridge mode, and just hoping that it would work as simply as I’d been promised.  Wouldn’t you know?  It worked.  It came on no problem.  The lights all went green (well, the power light started flashing orange after a bit, but that’s because it was updating the firmware for the first time, but after a reboot, it came back on no problem).  So now it’s sitting on my desk, plugged into the only network cable I had on hand, which is going through the switch in the back of my desk phone.  Maybe it’s not ideal, but I can finally start messing around with the cloud controller some more and really get an idea of what I’m working with and if I’m going to make the recommendation that we invest in Meraki hardware as we expand and upgrade our wireless.

Expect to see more about this hardware and probably some competing wireless solutions on here in the coming weeks.


As part of my efforts to expand and strengthen our wireless infrastructure on campus, I swapped out one of our aging Cisco Aironet 1200s for an Aironet 1250 last week.  In theory, this was fine and a great thing to do.  In practice, I got a call just as I was walking to work saying that classrooms in that area were reporting problems with their WiFi.

I checked the usual suspects, made sure that DHCP was running fine, made sure that the RADIUS server was up and running, and tried several times, in vain, to correct the presenting problem from the web-end.  At a loss, I went back and switched out the new AP for the old one just as a hold-over until I could figure out what was up.

Then, while doing the initial configuration for a new Meraki access point that I’m going to be testing out as soon as it shows up in the office, I realized what the missing piece of the puzzle was: the shared secret.

If you’re using a RADIUS server for wireless authentication, each client (access point) needs to have a shared secret that both it and the server know in order for any authentication to happen.  If the Aironet 1250 I had put in had been totally new to us, then I wouldn’t have run into this problem because I would have entered the shared secret during the course of my initial configuration, but this AP was formerly located elsewhere on campus, so all I had done was to change the IP address for its ethernet interface to prevent conflicts.

Now the AP had the correct Shared secret, and everything is as it should be again, but let this be a lesson to all of you: share your secrets.

Well, I said that I was going to build a server to do a larger-scale test for AirPrinting from iOS devices here on campus, and by gum I did.  Right now, under my desk, there’s an Ubuntu 12.04.1 Precise server named Goodmountain (see what I did there?) whose only job is to serve up AirPrint printers for campus iDevices.

Nothing more glamorous than an old ThinkCentre shoved under a desk, amiright?

Here it is (center).  Nothing more glamorous than an old ThinkCentre shoved under a desk, amiright?

So how’s it working so far?  Well, I’ve printed a couple pieces of short fiction from my iPad to two of the printers that I’ve made available for this pilot program, and everything’s gone just fine.  There aren’t any students around this week, and I don’t know how much demand there’s been for iPad printing.  For this pilot, I’ve only made four printers available in the locations where the iPads get used most often, and I’ll be waiting to see if there’s more demand and/or how much the service gets used before I do anything else.  Top on my list of priorities is moving this to an actual server that isn’t hanging out under my desk, but that only happens if this is something that there’s heavy demand for.

Now, what have I learned?  Well, top on my list is that the Ubuntu server installer doesn’t recognize full-sized Apple SATA drives (or at least drives that have been pulled out of the bin and have an Apple logo on them–I don’t actually know if it’s the drives or something about the partitions, and I don’t care to test that right now).  More important than that, though, is that if you’re going to be serving multiple printers, you need to have a separate .service XML file under /etc/avahi/services/ for each printer or none of them are going to show up.  If you’ve already built a nice big file for all your printers and you need to cut it up into a bunch of individual files, just consider it more Vim practice.  Yank is your friend.

Expect to see another report here once I have some usage statistics.

Presented as an exercise in figuring out what I was trying to accomplish:

sed -e 's/\([ ]*[0-9]\{4,4\}\)\([ ]*\)\([^ ]*\)\([ ]\)\(.*\)/\1,\5,\3/g'

Anyone (other than Dave) with an idea of what I’m doing here, leave your answers in the comments.

Like many other private schools, there have been rumblings at my workplace about going one-to-one (that is computers to students). At the moment, those rumblings point towards a pilot program rolling out iPads in the Middle School. We have a lot of smart teachers doing interesting things with iPads in their classrooms already, and I think that an iPad program could have a number of benefits in the classroom (though it will require a thoughtful digital citizenship curriculum), but that’s not what I’m most concerned with at the moment. I’m concerned with how the kids and teachers will print to all our legacy printers from their shiny new tablets.

A week or two ago, I was asked to research a product that is supposed to simply and seamlessly solve the problem of using legacy printers for AirPrint. The idea, which is a decent idea, is that you plug this box into your network and it discovers all your printers and makes them available for AirPrint. The problem, which I’ve heard from other sysadmins at schools in the area, is that this particular product doesn’t scale well–one of the boxes costs about $100, and each of them is “good” for about 7 printers, but even then, they apparently have a tendency to lock up and require frequent hard resets. There are software solutions available, but they cost money and run on Macs, and I don’t want to make us get a dedicated Mac to act as an AirPrint server if there’s a way to get the system running for free on open-source software.

Well, it turns out there is a way. At this point, I’ve only done a small-scale proof-of-concept, but as of this writing, I have printed a document from my iPad to my office’s HP 3505n, which is certainly a step in the right direction, and in the future, I’ll probably do a scaled-up test and then hopefully put the system into full deployment. In my test case, there was no noticeable lag between my submitting the print job from my iPad and the printer firing up compared to printing directly from my computer.

To get this running, I used my Linux workstation, which is running Ubuntu 12.04.1. Ubuntu comes with Avahi pre-installed, which is great, because you need that, too. (You may remember my mentioning Avahi before.) After installing your printer or printers, you need to make sure that they’re shared, then edit your CUPS configuration and create a configuration file for Avahi. Full instructions are on gyttja’s blog, though the original article referenced seems to be down, so you’ll want to go here to get it on the wayback machine.

You’ll want to restart CUPS and Avahi after you’ve put through all the changes, otherwise, you probably won’t get any results, and some swearing might ensue. To do that, just run

sudo service cups restart
sudo service avahi-daemon restart

Look for another post on this subject here once I get a solution working on our campus.


Today’s unintentionally artsy-fartsy out-of-focus picture of server room blinkenlights brought to you by ny investigation into a stubbornly malfunctioning security camera.

Sorry, couldn’t help it.

More to the point, what the hell does 755 mean when referring to file permissions? You may remember, way back in my first post, that I talked about the output of ls -l showing you the permissions for files. Well, that chain of permissions, rwxrwxrwx can be represented quite simply octal notation. Why octal? Because each permission can be represented as a single bit, each group of permissions is three-bits, an octal number is three bits, and, as far as I can tell, our UNIX fore-bearers liked to make things confusing and intimidating for non-users. So there.

Therefore, if we go back to 755, we can convert each digit to binary, giving us 111 101 101 which tells us that the permissions for a file with the mode of 755 is rwx for its owner, r-x for its group, and r-x again for all others.

Today’s awful-looking (though fairly tame) regular expression comes to you from my work at making my life, and the life of anyone who comes after me and still has to use our RADIUS server that much easier.

We make, edit, and delete entries from our RADIUS server’s database using the wlesscmd command which includes a list option that takes a string and gives back a list of entries that match that string. We use this in conjunction with the -n (note) option to give us an idea of who a particular MAC address belongs to when we’re looking at logs and whatnot. It’s also useful for doing housekeeping–we make a note of a student’s graduating year whenever we put one of their devices into the system so we can clear out batches of graduating students. The output of the list option looks something like this:

STUDENT 2010 Mike Jones lappy 1a2b3c4d5e6f STUDENT
STUDENT 2010 Janet Jones phone 0f9e8d7c6b5a STUDENT
STUDENT 2010 Frederick Wong lappy 5b8a9d4cfeef STUDENT

Which isn’t quite as nice as the comma-separated sheets that get used to add lots of devices all at once.

Enter the regexp.

sed -e 's/\([^ ]*[ ]*\)*\([0-9a-f]\{12,12\}\)\([ ]*[^ ]*\)/\2/g'

First, it looks for the note, which is any number of characters separated by any number of spaces any number of times: \([^ ]*[ ]*\)* . Then it looks for something that looks like a MAC address, which is exactly twelve hexidecimal numbers (0-f): \([0-9a-f]\{12,12\}\) . Finally, it looks for an SSID: \([ ]*[^ ]*\) . Then, sed takes just the MAC address, represented by \2 (the second regexp) and (in a code segment that isn’t included here) appends it to a temporary file of MACs prepped for removal.

This has been your scary-looking regular expression for the moment.