So, after a discovering a cloaking hack that was gradually populating the search indices for my site with bogus links, I decided to do some much needed cleaning up around my web server. As a result there may be a few dead links around here. If you discover one, or if there’s something you need that you can no longer find, feel free to ask. I have it all backed up somewhere.
Spring Cleaning Notice May 17, 2013
Using Quinnipiac's BobcatNet With 'netctl' Apr 16, 2013
I use a Linux machine with Quinnipiac’s wireless network, BobcatNet. I have until recently used ‘netcfg’ as my wireless network manager, as it’s both highly configurable and the default network manager for Arch, my Linux distro. I had shared my netcfg settings for other folks who might wish to connect to BobcatNet using a Linux machine and ‘netcfg’. Recently, however, Arch changed things up and ‘netctl’ is now the default network manager for the distro. I’ve made the switch and figured I’d share my new netctl wireless settings for BobcatNet. The following goes in a netctl profile file in ‘/etc/netctl/’:
I’ve called the above profile file ‘qu’. To start the wireless connection, the command is ‘netctl start qu’ and to disconnect I use ‘netctl stop-all’.
Using Quinnipiac's BobcatNet With Linux Feb 5, 2013
Update 4/16/2013: My Linux distro, Arch, has changed its default network manager from netcfg to netctl. The details in this post should still work for users of netcfg, but I’ve also posted my new netctl settings here.
Quinnipiac University’s IT department doesn’t support Linux, but it is, of course, possible to use a Linux machine here. I do, and in the event that anyone else is interested in doing so, I’ll occasionally put up posts on how best to get your Linux computer working with QU’s resources. Here’s how I got my wireless working with QU’s secure BobcatNet WiFi network.
First off, I use netcfg as my network manager. If you use wicd or another network manager, you may have to extrapolate a bit. With netcfg, the settings for each of your regular wireless networks is stored as a separate config file in the directory ‘/etc/network.d/’. If you’re using netcfg, just create a new blank configuration file in the aforementioned folder—I called mine ‘qu’—and place the following in it:
identity="your MyQ username"
You will, of course, need to fill in your own network username and password. To find the name of your wireless interface (usually, but not always, wlan0), run the ‘iwconfig’ command from the command line and use whatever combination of letters and numbers it identifies as being associated with your wireless card.
Once finished, you can connect to the network at any time with the command ‘netcfg qu’ (where ‘qu’ is whatever you’ve called your config file). To disconnect, it’s ‘netcfg down qu’. You can, of course, automate connecting and disconnecting with systemd (or initscripts, for that matter). Check out the Arch wiki for more information on configuring and/or automating netcfg.
Lastly, no small thanks to Jon Gjengset of Bond University, who posted a WPA2 Enterprise netcfg config file for his own school that, along with netcfg’s own example files, served as an excellent guide for getting this working.
Setting Up VirtualBox Shared Folders Dec 31, 2012
In my previous post on installing Arch Linux in VirtualBox, I’d mentioned that I’d eventually add information on sharing folders and files between Arch and the host operating system. I wasn’t going to get around to writing this up for a while, but a question came up about it in a discussion on the Arch forums, so I ended up doing it sooner than later.
Here’s how I’ve configured shared folders on my own VirtualBox install of Arch Linux. These instructions should work for other Linux distros used with VirtualBox as well, but the usual disclaimers apply—this worked for me, but your mileage may vary and there’s no warranty here express or implied.
Everyone hates outdated instructions, so I’m going to include the version numbers I’m working with. The instructions in this guide were executed on a 13-inch MacBook Pro (early 2011 model) running Mac OS X 10.7.5 (Lion) and VirtualBox 4.2.6. The Arch guest OS is running Guest Additions packages from the Arch community repository, the version numbers for which are virtualbox-guest-utils 4.2.6-1 and virtualbox-guest-modules 4.2.6-3.
Setting Up Shared Folders
Note that before you can begin, you need to have installed and configured the VirtualBox Guest Additions in Arch. These instructions assume that you’ve done so already.
- Create a folder on your host OS to be shared with your Arch Linux guest. Note that this folder has to be in a location that’s not “owned” by a particular user of your host OS. There’s some weirdness to this, as it appears to be about more than just the permissions assigned to a particular folder. I’ve found that on OS X, creating a folder either in the ~/Public folder (<–this is where I put my shared folder) or on the Desktop works, while creating a folder in the ~/Documents directory does not, despite the fact that the permissions for some of these different directories are similar. Also, at this stage, place a text file or some other file in the folder—later on, if you can see and view the contents of this file from within Arch you’ll know the folder’s been shared successfully
- Identify the shared folder in your VM’s VirtualBox settings. In the VirtualBox Manager window, prior to booting your VM, select your Arch Linux guest and go to “Settings > Shared Folders”. Click the folder icon with a plus on it to add a shared folder. For “Folder Path” open the dropdown menu and select “Other…” to launch your host OS’ file browser. Select the folder you created on your host OS in step one. For “Folder Name”, if it’s not autofilled, enter a name for the folder to identify it to the Arch Linux guest—to avoid dealing with escape characters and so forth later on, I generally make this something simple, like “Shared”, and avoid spaces or special characters. For simplicity’s sake, I also usually make this name the same as the name of the folder I created in step one. “Read Only” should be left unchecked, assuming you want to be able to add files to the shared folder from within Arch. Also, leave “Auto-mount” unchecked—there’s an alternative configuration in which you leave this checked, but for present purposes it shouldn’t be. Finally, check “Make Permanent” to have the folder available every time the Arch guest is booted. When you’ve filled out the form and clicked ‘OK’ your new folder-to-be-shared should appear in the “Settings > Shared Folders” window under the list of “Machine Folders”.
- Boot your Arch Linux VM. Log in with your normal user account (i.e., not as root).
- Create a mount point in Arch for the shared folder. By this, I mean create a folder in Arch where you want the contents of the shared folder on the host OS to appear. I usually create this folder in my home (~) directory and, for consistency, name it the same thing I named the folder on the host OS, which is also the same “Folder Name” name I gave when identifying it in the VM settings.
- Test the availability of the shared folder by manually mounting it. Momentarily, we’ll automate this process, but before we do it’s a good idea to make sure everything’s working correctly. This is an example of the command to run, which I’ll explain subsequently:
# sudo mount -t vboxsf -o gid=1000,uid=1000 Shared /home/josh/Shared
In the above command,
- sudo is obviously to invoke administrative privileges, which are needed to mount the folder;
- mount is the mount command;
- -t is a flag specifying the type of thing to be mounted, which is a Virtual Box shared folder (‘vboxsf’);
- -o is the options flag, which is there so we can invoke the option to make the folder writable for the users in the group with the number 1000 (gid=1000) and the particular user with id number 1000 (uid=1000). Assuming this is a personal install and you created only one non-root user account for yourself, user 1000 in group 1000 will beyou, however if you’ve got multiple user accounts or have set up weird group privileges, you may need to look up the group and user id that apply to you;
- ‘Shared’ is the name you gave as “Folder Name” in step two;
- ‘/home/josh/Shared’ is the absolute path to the folder you created in step four (my username is ‘josh’). Note that you have to give this filepath without any shortcuts or symlinks (i.e., ‘~/Shared’ will not work).
Note that if you want to temporarily share a folder between your guest and host in the future, you can use this same ‘mount’ command in conjunction with VirtualBox’s “Devices > Shared Folders” menu while the VM is running. The only difference is that the folder you share using “Devices > Shared Folders” will be added to a list of “Transient Folders” rather than the “Machine Folders” list, meaning that it will only be available for the current VM session.
- Test the shared folder. Once you’ve run this command, you should be able to see and view the contents of any files you’ve placed in the shared folder on the host OS by navigating to the mount-point folder you created from within Arch. You should also try copying a file from your Arch system into the shared folder to see if it shows up on the host OS. If not, you may not have write privileges for the folder, and you should check (1) the folder permissions on the host, as well as (2) the uid/gid you used in your command to make sure they correctly apply to your user account.
- Add instructions for mounting the folder to /etc/fstab. If everything’s worked up ’til now, you can go ahead and add instructions for mounting to the folder to your /etc/fstab file. This will automatically mount the shared folder in the future when Arch boots. At the end of my /etc/fstab file, I placed the following:
# VirtualBox Shared Folder Shared /home/josh/Shared vboxsf uid=1000,gid=1000 0 0
While the order is slightly different, you’ll see that all of the options set here are identical to the ones used in the ‘mount’ command above, so you should set them to whatever the personal equivalents are that you used previously. The only exceptions are the last two zeroes, which you should just leave as is. These turn off Linux’s file system backup (‘dump’) and file system check (‘fsck’) for the shared folder, neither of which is needed here.
- Reboot Arch. At this point, you should be able to reboot Arch and, if everything’s worked correctly, the shared folder should be automatically mounted for you.
Alternative Configurations and an Important Note on the ‘Auto-mount’ Feature
Lastly, I should mention how the method I’ve described here is different from alternatives that some other people use, so there’s no confusion if or when you encounter a forum thread at some point in which people have done it differently. Some other folks will use much the same process I’ve outlined, but instead of having ‘fstab’ mount their shared folder will instead create a systemd configuration file or initscript to do the same thing.
Still other folks will check “Auto-mount” in step two above, and omit my steps 4–7. Instead, they create user privileges for Guest Additions within Arch that allow the Guest Additions software to mount volumes by itself. Guest Additions will then automatically mount the shared folder as an external drive that shows up under the ‘/media’ directory. I’ve never tried this method personally, but if you wanted to, you could find instructions on doing so with a bit of Googling.
Note that if you use my configuration, you should leave ‘Auto-mount’ unchecked—if you leave it checked, things will work just fine when you boot and while you’re working, but will cause problems when you try to shut down the VM. At that point, VirtualBox’s ongoing attempt at connecting to the VM as a removable device, hitherto harmless, causes Arch to wig out as it’s unmounting and closing down all the virtual hardware. This usually induces a slew of error messages ending in a kernel panic (on the VM), and the need for a hard shutdown of the virtual machine.
That’s it! Hopefully this works for you, and feel free to leave your own critiques, comments, or alternative configurations in the comments.
A Guide to Installing Arch in VirtualBox Dec 22, 2012
Author’s Note (12/26/2012): This post has been updated to take advantage of some of the excellent corrections and constructive criticism provided by the Arch Linux community on Reddit. Many thanks to them for their advice and suggestions.
Author’s Note (3/21/2013): I’m thankful for all the nice things users have said about this guide and all the advice they’ve given in the comments—you folks are great. There’ve been a number of calls to update this post to reflect recent changes in Arch. I’ve added a few updates throughout the text and will probably continue to do so once or twice a year until it becomes unwieldy. With that said, however, given that Arch is a rolling release that changes all the time, keeping this entire post up to date for the indefinite future would be a constant, and quite possibly losing, battle. That’s why we have the Arch Wiki, edited by the masses and not one guy. It’s also why I put dates and version numbers high up in this post—so people could easily see how dated the instructions were. Your best experience with this guide will be to use it alongside the Arch Wiki and other resources, so you can take what’s helpful and leave what’s not. And if you’re coming to this post for the first time, you should also most definitely check the comment thread, where users have added helpful comments and advice about changes that have occurred with Arch since the post was written. Also, note that while I try to be helpful, I can’t necessarily provide tech support here for everyone following these instructions. Check out the Arch wiki, forums, IRC channel, and Google+ community, as these are your best resources for questions.
As the title suggests, this is a guide to installing Arch Linux in VirtualBox. However, since there are a lot of these out there at this point, I’ve tried to make it a bit more than a utilitarian installation template, but to put together a more substantive resource for relative beginners, reflecting on why I run Arch and providing a bit more context as to what’s actually going on during the installation process. If you are indeed a beginner, please also check out Arch Linux’s Beginner’s Guide [H/T nCrazed], a great resource which I wish I’d been aware of when I first started out. If you know what you’re doing, on the other hand, feel free to skip directly to the instructions and take only what you need, or to find another post or YouTube video that describes the process more concisely.
As of this writing, I’ve been a Linux user for around five years. As with many Linux noobs who began the adventure around the time I did, I started out with Ubuntu. As a gateway drug, Ubuntu served me well. It’s easy to use, it installs itself with little user intervention, it familiarized me with *nix in a way that even OS X didn’t, and as with almost any Linux distro you can’t argue with the price. But it wasn’t long before I wanted to know more about Linux than I did, or at least—given the vast number of Linux distros in the wild and the remarkable customizability of the operating system—to explore a few other options.
Why Arch Linux?
I started out very tame, installing other Ubuntu variants and then Debian (on which Ubuntu is based), before a friendly Linux user suggested that, if I ever wanted to figure out what the hell I was doing, I should try tinkering with a Linux distro that wasn’t based on Debian, just to broaden my perspective a bit. After a little poking about I decided to try Arch, and that’s when I fell in love.
The philosophy behind the Arch distro is dubbed “The Arch Way” and it revolves around a definition of the word “simple” that diverges sharply from what Ubuntu users think of as “simple.” For the folks behind Ubuntu, simple means a polished user experience—the idea that your whole system will install instantly, easily and out of the box with all your essential needs met. At its best, this means that a new Ubuntu user can install the operating system in a few minutes, find the applications she needs already there, and immediately begin loading up her music and pictures, browsing the web, checking her email and working with office documents.
But the Ubuntu philosophy of “simple” can also mean that your new system is bulky, built with every contingency in mind and preinstalled with applications you may never have asked for. While it’s true that Ubuntu installations can be customized, opening a new default installation can feel a bit like booting up an old Compaq Windows PC for the first time and finding it loaded with “crapware“—software you don’t need and would never have chosen to install yourself. The introduction of Ubuntu’s custom “Unity” desktop—a new system interface reviled by many users—doesn’t help matters, either.
The Arch definition of “simple” meanwhile is “without unnecessary additions, modifications, or complications.” In other words, it’s less about user friendliness and more about leanness and customizability. You can still add a noob-friendly desktop environment to an Arch installation, of course, and as much software as you want. But out of the box an Arch Linux distro comes without bells and whistles installed.
As with Ubuntu, it comes with a package manager that makes it easy to add new software and update your system from there (Arch is also a “bleeding edge” distribution, which sends out software updates as soon as they become available, with all the benefits—and perils—that such a release cycle involves [H/T Silentl620]), but with Arch you are able from the get-go to choose everything that you want (and don’t want) installed on your computer. Getting my first Arch installation up and running was a revelation in that, for possibly the first time, I had an OS that was exactly as I wanted it. At its best an Arch installation fits you like a tailored garment, its capabilities and selection of software shaped to your every specification.
This is, of course, possible with other Linux distros as well. Even Ubuntu makes a “minimal install” package available that will allow you to start small and customize. And more broadly my treatise here is meant not as a judgment on Ubuntu or a testament to the unique superiority of Arch, but rather as a description of my personal experience switching between the two and the new horizons it opened for me. Part of my affinity for Arch is no doubt sentimentality surrounding this experience—it’s not just about Arch itself, but about exploring an alternative approach to the OS and having my eyes opened to a greater diversity of philosophies behind Linux and open source computing.
Why an Installation Guide?
Recently, in setting up a new Arch installation, I got to know the distribution even more intimately. The folks behind the distro have decided to discontinue the auto-installer they had previously offered. The installation process for Arch is now largely done from the command line, which may be a bit frightening for folks whose idea of “simplicity” is more in line with Ubuntu’s. But for those willing and interested in learning a bit more about how their OS works—in short, the user base Arch hopes to attract—it’s an interesting and educational process. And there’s a lot of help out there to step you through it, both in the form of play-by-play YouTube tutorials, and the documentation on the Arch website itself.
Nonetheless, if you’re not an old hand at Linux/Unix, installing Arch for the first time requires a fair amount of digging and reading to learn exactly what you’re doing—especially if, like me, you were unaware of Arch’s Beginner’s Guide when you began. Whenever I get myself into something like this, I try and take careful notes so that (a) I can easily go back and find the sources I used, and (b) I can repeat the process more easily myself in the future.
And since I’m not a Linux developer, I try to share some of this documentation as a way of giving back to the open source community and paying forward all the help I’ve gotten over the years. My guides aren’t perfect—keep in mind that they’re inevitably written at the point when I’m still just on the cusp of knowing what the hell it is that I’m doing. But, without any warranty, express or implied, my hope is that they can help the next person get at least as far as I did. And often visitors to this site will do everyone a huge favor by correcting my mistakes, updating outdated instructions, and pointing out ways of doing things that are better than those I’ve contributed. So please check the comment threads for helpful addendums. And without further ado, here is my guide to installing Arch Linux. Once again, this worked for me, but there’s no warranty here, express or implied.
Library Proxy Chrome Extension Updated Nov 26, 2012
For users of my Library Proxy extension for Google Chrome, please note that I’ve updated the plugin to conform to Google Chrome’s new developer specifications. You can download the latest version of the extension by visiting the original download page/blog post.
For end users, the extension will function the same as always, however the new version will now be safely compatible with future versions of Chrome. Also, since Chrome no longer auto-installs extensions offered outside the Google Chrome store, please refer to this guide when installing new versions of the plugin. I think you’ll find the installation process is still quite simple, even if it’s no longer automated.
Paper in Communication, Culture & Critique Oct 22, 2012
Good news! My article, “Going Over the Top: Online Television Distribution as Socio-Technical System” was recently accepted to the ICA journal, Communication, Culture & Critique. The piece uses some analytical tools from science and technology studies to examine an early controversy surrounding streaming television distribution, specifically a tussle between Hulu and Boxee that presaged many of the dust-ups and heated arguments surrounding TV Everywhere and television distribution to interntet-connected set-top boxes like Google TV.
It also examines the agency of users in the online distribution chain—how user modifications to Boxee’s software impacted the flow of content and the discourse surrounding the technologies and relationships behind online television distribution. I’m particularly fond of this article in a paternal sort of way, as it’s one of the first in which I really begin to lay out my research perspective in earnest, which I hope will be well received.
No word on a publication date yet, but I’m happy to share a draft of the article with those who are interested.
Of Privacy and Parsimony Oct 2, 2012
Every academic publication makes small asides and fleeting or tangential points on the way to its big argument. Most of the time it’s that larger case that’s remembered, the smaller points easily forgotten.
But every so often as a reader you come across a summary, description, or insight an author has made in passing that sticks with you for years. For me one of those is from Anton Alterman’s 2003 article, “‘A piece of yourself’: Ethical issues in biometric identification [PDF],” which in making a larger argument about—as you may have guessed—ethical issues in biometric identification, attempts to boil down the privacy concerns surrounding other prior information technologies into three brief sentences.
No doubt this is the author trying to be parsimonious in his lit review, with an eye toward the journal’s length requirements. Nonetheless, the distillation of such a broad field of study into a small paragraph is the sort of high wire act that makes reviewer-worn academics bite their nails as they begin reading. That’s, perhaps, one reason the passage has stuck with me so long.
The other is that those few sentences turn out to be incredibly incisive and useful. They likely leave some things out, of course. But each year, when discussions of online privacy issues come up in my new media courses—as they will this week—my thoughts inevitably return to Alterman’s brief set of categories, which seem to so beautifully capture so much:
One [privacy concern] is that someone, say a stalker, or the U.S. Federal Bureau of Investigation (FBI) for that matter, will legitimately gain access to information about you and utilize it to locate and harass or harm you in some manner.
A second is that information you provide for a particular purpose will be retrieved or purchased, say by direct marketers or credit bureaus, perhaps to be be correlated with other data, and used for purposes that you would neither have predicted nor agreed to.
A third kind of concern is that the data will be stolen or illegitimately released, exposing you to risk, embarrassment, or other harm. (p. 140)
Alterman, A. (2003). “A piece of yourself”: Ethical issues in biometric identification. Ethics and information technology, 5(3), 139–150.
[Image Credit: "Privacy" cc-by 2.0 Alan Cleaver]