The Need
We host free seminars on backup & recovery and virtualization each year. We decided to lessen our paper dependency this year and provide the presentations via a pdf file instead of a printed booklet, as we had been doing for the past couple of years.
We wanted a solution that would easily serve files to people at our seminars. Our options were to put the files on 1) thumbdrives, 2) an internet available server, 3) one of our laptops/phones/iPads running a webserver, ftp or some other means of filesharing, or 4) a dedicated device. Also, we are limited on the amount of gear we can take on a trip, as we only have 2 suitcases for gear. I’ll review the options, why I settled on the one I did, and how I configured it.
Option 1: files on a thumbdrive. We could have put copies on thumbdrives and handed that out to everyone, but I wasn’t too keen on that due to price and hassle of keeping updated copies of presentations on large numbers of devices. We do bring a handful of thumbdrives in case anyone has trouble downloading the file.
Option 2: internet available server. Easiest thing would be to have a page on our website and point people to it, updating the pdf for each city. However, internet access at hotels (where we do the events) is flaky at best, often non-functional. I do carry around a MiFi device to provide internet access in the event the hotel’s access is too horrible. However, our average attendance is 50 people and the average pdf size is about 50 MB, so that would be 2.5 GB of data downloaded in one city, at the painfully exorbitant prices that MiFi providers charge. And it is not unusual to be in a hotel where I can’t get any sort of MiFi signal, so I didn’t want us to be dependent on that.
Option 3: running something on laptop/iPad/Phone. This has the distinct advantage of not bringing another piece of equipment into play, as it would just run on one of our devices that we are already bringing. I didn’t really want to run a solution on multiple devices or have to worry about battery life/connectivity for iPads or phones, though I could have gotten around those. I really didn’t spend much time on this.
Option 4: dedicated device. This is what we settled on, though we struck out with our first device. I wanted something small and lightweight due to my luggage constraints. Our first attempt was with an iUSBport by HyperDrive. I created a webpage that had a link to the file and to pdf readers and put that and the pdf file on a usb drive and had a URL for people to access the file. We even wrote a script to simulate dozens of simultaneous downloads and thought we were good to go. As with many things, production use managed to bring out the worst and did not follow our testing experience. The iUSBport is strictly wireless, and though it was on a local network created by our cradlepoint router and users did not go out over the internet to access, it still ended up feeling like it was behind a dialup connection halfway around the world. That ended the use of the iUSBport.
Enter the Raspberry Pi
The Raspberry Pi is a credit card sized motherboard. Load the debian-based OS on an SD card, put it in a small case and you have a $60 webserver. It weighs 2.6 oz and is 3.5″x2.5″x1″ in the case. It comes with 512 MB of RAM and a 700 Mhz ARM processor.
An SD card serves as the disk drive and we opted for the mini-SD card and converter, so that it would fit in the slot and not stick out of the case.
Configuring the Raspberry Pi as a webserver
I basically followed a modified version of this WikiHow, http://www.wikihow.com/Make-a-Raspberry-Pi-Web-Server.
There are guides and instructions on the download site in step 1 below; you will need to select which method works for you. My steps, run on my Mac, were:
NOTE: Don’t blindly follow the steps below and blame me if something goes wrong, you do need to understand what you are doing. For instance, using dd incorrectly can really mess things up, as it will rewrite all data on whatever target you specify. Follow the guide for beginners in the download link for detailed explanations.
- Download Raspbian “wheezy” http://www.raspberrypi.org/downloads
- unzip and dd image to SD card
- Used df -h to figure out correct disk name of SD card, removed s1 at end and replaced disk with rdisk
- unmounted SD card, sudo diskutil unmount /dev/disk2s1
- sudo dd if=2012-12-16-wheezy-raspbian.img of=/dev/rdisk2
- Either add sudo in front of each of these commands or run sudo su, then run each of these.
- mv /boot/boot_enable_ssh.rc /boot/boot.rc (enables ssh)
dpkg-reconfigure tzdata
apt-get -y update
apt-get -y upgrade
apt-get -y install ca-certificates
apt-get -y install git-corewget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
rpi-update
shutdown -r now - Next set need to be run with sudo as well
- apt-get -y install apache2 php5 libapache2-mod-php5
groupadd www-data
usermod -g www-data www-data
groupadd www-data
usermod -g www-data www-data
service apache2 restart - I then copied over the files I wanted to share to the webserver root and was ready to go
I also set a static IP, so that our documentation wouldn’t need to change, we simply point people to the 192.168 address that gets assigned by the cradlepoint router we use. For each city, I merely scp over the lastest pdf file.
For a backup, I pulled the SD card out of the Raspberry Pi, used dd to copy it over to my laptop, gzipped it up to take up less space and now have an image-based copy that I can dd onto a new SD card, complete with webserver and desired IP.
Summary
The Raspberry Pi has been a great solution for us. It has a small price tag, weighs next to nothing, requires only a short ethernet cable for access and a short usb cable for power. What more could I ask for? (Don’t worry, I’ll think of something).
thereedrobins 