Wandering Thoughts archives

My perspective on the 'Bring Your Own Device' controversy

My understand, garnered mostly from Twitter, is that there is an increasing controversy about what is being called BYOD; people bringing in their own computers and other devices instead of using IT-issued stuff. As it happens I have a skewed perspective on this issue, because our academic environment here is heavily BYOD at multiple levels. For us, supporting BYOD to some level is routine and in fact actively required because of how computing is provided (and not provided) to people here.

(I say we have multi-level BYOD because a professor buying their own equipment for a research group is somewhat different than a graduate student or staff member showing up with their own computer or device. How computing is 'provided' here is a sufficiently complex issue that it needs its own entry; this one is already long enough.)

In my view, what makes BYOD work in our environment is that we don't really attempt to directly provide support for BYOD devices and BYOD users (especially really good support of the 'we will make it work' type). In a way this goes along with our sysadmin environment, as one way to summarize our reaction to BYOD devices is that we provide services and it's up to the owner of a BYOD device to get that device working with them. Sometimes the answer is that you just can't; for example, if you turn up with an unsupported printer and want it to be part of our printing system the answer is going to be 'no, we told you to get a supported printer'.

(We have relatively broad standards for supported and maybe-supported printers, but network connectivity and PostScript support are basic minimums.)

This answer is a copout in three ways. First, I'm only speaking of the central core sysadmin group. Points of Contact work on whatever their groups and professors tell them to; if the group wants their Point of Contact to spend their time making people's random BYOD devices work in our environment, that's up to the group. However, there's an obvious limit in that Points of Contact only have so much time (and this is explicit). The group gets to prioritize the time but they don't get to demand that extra time magically appear, so if a Point of Contact is providing hands-on support for BYOD devices they're not doing other things.

Second, this lack of support fundamentally assumes that you can opt to not support people. This ties into a broader issue of what makes an academic environment very different from a corporate environment, but the short and unkind version is that graduate students are really on their own. Unlike conventional employees, if they can't work that's ultimately their problem not the department's.

(For support staff, the answer is that they're provided a baseline IT environment. If they want to supplement it or replace it with a BYOD device but can't get the device working, the answer is 'use your IT provided system'. For professors the answer gets complex, as you might guess.)

Third, once a particular BYOD device starts to become common we start supporting it simply as a practical matter. There may be no official document that says that we'll support Windows 7 on laptops on our wired and wireless networks, but in practice doing so is a clear requirement. If something in our core environment doesn't work with a common device, we have to fix it (even if our core environment is technically operating to spec). In practice this is both common sense and not particularly burdensome so far.

(Not all common functions of devices are necessarily supported, only what we consider sufficiently important ones. For example it would be nice to support Apple's Airprint for Macs, but we don't so far. But printing from Macs to our printing environment is supported in general; you just have to configure things by hand on the Mac.)

As a side note, BYOD is inescapable in an academic environment because of grant funding issues. Professors with money will not buy only what IT tells them to, no matter what; in fact, often they may have very little practical choice about what they buy and who they buy from.

My story of running scripts from the web

One of the famous terrifying ideas for system administrators is people being told 'oh, to install this just pipe this URL into a (root) shell' (see, for example, this tweet). On Twitter I mentioned that I used to do this sometimes, so today I'm going to explain myself. Trust me, it's less insane than it looked.

Once upon a time I was responsible for a bunch of more or less identical Linux machines. We had two forms of automated installs. One was a bare machine install, where you stuck a USB key on the machine, booted from it, and specified various information about the machine in the process. The other was a reinstall of an existing machine, which could be done entirely over the network and automatically took all of the necessary bits from the machine's existing configuration. The reinstall had to be set up by some management scripts.

(The full complex background for this is in How CQUEST installs generic machines, which is something I wrote long ago before I started WanderingThoughts. I think it dates from 2003 or 2004. Note that CQUEST is a lot different today.)

Every so often an automated install would go wrong, either because of a bug in our scripts or because of some system problem. Usually the result of this was that the machine had the base OS installed but had not applied our post-install customizations and had none of our normal environment available; no NFS mounts, no management scripts, and so on. In particular, it lacked the management infrastructure that would set up a reinstall.

We could have fixed these machines with a bare machine (re)install, but that was annoying for various reasons. So instead I had a script that would bring up enough of the management infrastructure and set up a hands-off reinstall. That left me with the problem of getting the script on to a broken machine and running it, and you can probably guess what my answer was: I put the script on the web server, and we ran it with:

lynx -dump MAGIC-URL | sh

(This was so long ago that lynx was the obvious choice.)

At the time this struck me as clever. Today I would probably change it to something like 'scp ... /tmp/rerun.sh; sh /tmp/rerun.sh', but that's partly me being conditioned by how we do things around here.

(I don't think that there's a big difference in security between the two options, but it may be easier for an attacker to pervert your web server configuration or alter a script that is hanging out on the web server separate from the rest of your install environment.)