Cisco Weight Loss Addendum

After the revelatory nature of the information I shared earlier this week, I felt on top of the world, but that illusion quickly shattered when I attempted to upgrade some of our newest (but still autonomous) access points, only to have my tftp requests time out.  A quick ? showed me that I could instead use scp (which has made appearances on this blog before), but the syntax was left as a mystery to me.  I have finally found the syntax, though (hint: it’s not quite the same as the normal *nix command) and have had considerable success upgrading our remaining autonomous units with that method.

Whereas with tftp, you simply entered the server address followed by the path to the file (relative to the tftp server folder), the Cisco version of scp is a bit more complicated.  My main tripping point was discovering what the file path for the image being downloaded was relative to.  I assumed it would start at the root of the filesystem, / but instead the path is expressed relative to the home folder of the username specified.  I don’t know if using ../ will let you back out of your home folder, but it’s simple enough to copy the image to your home folder.  So, to use scp to download an image from your machine to a Cisco access point, you would use

archive download-sw /reload /overwrite scp://username@server/path/to/image.tar

where the image path is relative to the home folder of username.

That’s all.  Happy scp-ing!

Losing Weight (for Cisco Access Points)

A quick post today, but no less informative, I hope.

We just installed a brand new Cisco wireless controller, and that means converting our older, autonomous access points to lightweight mode so they can interface with the controller.  Cisco would like you to use their (Windows-based) tool, which I tried initially.  While it may be easier and faster in an ideal situation, those are so rare.  I looked around but couldn’t find a good text-based tutorial for doing the upgrade, but I did find some youtube videos, one of which brought me my solution.

Before you get started, you’ll want to collect a few things.  First, you’ll need a recovery image specific to your access point.  You can download the image you need from Cisco–you’ll want the recovery image, which will crucially contain the string “rcv” in its file name.  Download the image and move it to your tftp server root (if you’re using Ubuntu, there’s a good guide for setting up a tftp server here if you don’t already have one).  Don’t worry about extracting the tarball–the access point will handle that for you.

If you’re not upgrading your access points in place, you may also want a serial connection to the AP so you can watch its progress the whole time, but this is optional.  I use minicom for my serial terminal on Ubuntu, though you may already have a package you prefer.

Now that you’ve got everything in place, telnet (or ssh) into your access point (and enter enable mode, but not configure mode) and run the following:

archive download-sw /reload /overwrite tftp://(ip address of your tftp server)/(name of recovery image tarball)

After the access point finishes downloading the image, it should restart automatically, but if there are any unsaved changes lingering on the system, use reload to restart the switch.  The switch will reboot, and if you’re watching on your serial console, you should see the access point going through the process of loading the recovery image, contacting the controller, and then downloading a full image before finally restarting again and coming under full control.

The Problems with Backups

Backups, as far as many folks are concerned, are one of the most boring topics imaginable. Of course, that only extends to the point at which you need them; then they’re still boring, but you really really hope you have them. Most of the time, backing up your data is simple–if you’re at home, get an external drive, plug it into your machine, and make sure you back things up regularly.  If you’re at work, things often get a lot simpler than that: someone from IT provides you with a backup solution or even makes it happen without your needing to intercede. At work, backups become something of an assumed thing (provided that you’re not the person in IT who’s administrating them). Things only start to get sticky when you take that work computer home.

Imagine a situation in which your employer has issued you a laptop for work (not too hard to do, I should think). Because it’s portable, and maybe because it’s a better machine than what you own, you use it for non-work purposes, loading it with personal documents, photos, music, maybe even games. Depending on your organizational ethic, some of these personal files may be mixed in with your work documents (which are often considered to be the property of your organization, though your mileage may vary from this hypothetical situation). With your personal files mixed in with work files, your employer is now spending disk space on backing up non-essential (from their point of view) files; this is also probably known as wasting that space inside the walls of your tech office.

Yes, storage is cheap, but implementing that storage still takes time, which raises the question of how to deal with the issue of backing up only the files which your company can claim ownership over. Yes, you can issue backup drives to employees and put the onus of backups on them, but that raises its own set of problems.  User error happens, and often even the most vigilant of users will forget to make that backup at some critical juncture. Even trusting your users and stressing to them that they are responsible for their own backups, there are some users whose files are too important in one way or another to trust only to their own backups.  Too many users carry their backup drive, if it’s easily portable, in the same bag as their laptop, thus ensuring total loss of data in the event of a theft.

Cloud storage would seem to be a solution: just drop your files into a special folder, and they’re automagically available anywhere you have internet.  The problem comes back to separating personal data from work data, specifically in the event of employee termination or retirement. Not all cloud storage is created equal, and the most well-known solutions are mostly consumer/individual-oriented rather than enterprise-oriented. For Google Apps organizations, Drive is a fine solution, though it has its limits–permissions are nowhere near as fine-grained as you would find in a Windows domain or a UNIX-like filesystem, which presents a problem in more security-oriented organizations where a data breach could have serious consequences. If data is on a Drive account managed by a company’s domain, it is still recoverable if an employee leaves. This is not possible, though, with personal Google accounts, Dropbox, or other such services.

In the end, there isn’t any one easy solution–a robust data security/recovery strategy requires several levels and different considerations for different groups of users. No two organizations are likely to have exactly the same needs, but the questions should be largely the same.