Raspberry Strudel: My Raspberry Pi in Austria

I remember my first colocated server rather fondly. It was a 1U Supermicro that had been decommissioned from my employer after a few years' service. Although it was too old and slow for my company, the 800MHz CPU, 1GB RAM and 36GB SCSI storage was perfect for my needs back in 2005. A friend was kind enough to allow me to colocate the server at his facility for free. So, after a lot of planning, I installed and configured Debian, generated SSH keys and set IPs so I could manage this machine remotely. Once it was colocated, it became my primary server for Web, DNS, SMTP and my perpetual Irssi-in-a-screen session. The machine served me for more than five years until I ultimately replaced it with newer hardware.

Fast-forward to today, and although my primary server has significantly more resources, I just finished colocating a new server, again for free, and again with similar resources as my old Supermicro: 900MHz CPU, 256MB RAM and 40GB Flash storage. This time though, the server is a Raspberry Pi, and the facility is located in Austria. In this article, I explain how I was able to colocate a Raspberry Pi and the steps I went through to prepare it for remote management.

The Deal

When I first saw the deal advertised, I couldn't believe my eyes. An Austrian colocation facility, EDIS GmbH, was offering free Raspberry Pi colocation. Although I was a bit skeptical, I carefully read through the fine print, but it was pretty clear. If you set up an account, the EDIS GmbH folks would send you network information for your Raspberry Pi. Once you configured the network settings, you would send the Raspberry Pi along with the SD card, USB cable and optionally a small USB thumbdrive and they would rack it and provide 100Gb/month of traffic on a 100Mb connection. They even offered free remote power cycling of the server as long as you were fine with waiting 24–48 hours. I figured the worst that could happen is that I'm out a $35 Raspberry Pi and some Flash storage, so I signed up and set aside a Raspberry Pi, 8GB SD card and 32GB thumbdrive while I waited for my IP information.

The Setup

I'm no stranger to colocating servers without remote management. Although I certainly prefer servers that provide remote lights-out management, beggars can't be choosers, so many of my personal servers have had to make do with SSH and the ability to have someone cycle the power. Although I wasn't sure how I would use the server, I did know I wanted to keep the OS relatively lightweight. I also didn't want to take too many chances with a machine I would have little access to, so I went with the standard Raspbian "wheezy" Debian distribution linked to on the Raspberry Pi download page. There already is plenty of documentation on how to set up Raspbian, so I don't go into that here. Instead, I focus on the changes I made to the distribution before I shipped it off.

Because Raspbian assumes you will run a desktop, it splits the available RAM with the GPU. Of course, on a server, you need the RAM for your services, so the next thing I did was run sudo raspi-config to launch an ncurses interface that let me tweak some of the hardware defaults. I ended up allocating only a little bit of RAM to the GPU, and while I was in the interface, I figured it wouldn't hurt to expand the root filesystem to fill my SD card, overclock the Raspberry Pi to 900MHz, change my locale and time zone, and change the boot behavior so the desktop didn't start at boot.

The default Raspbian image ships with a standard user and known password. I didn't want anyone to log in to my server except for me, so the next thing I did was add my own user account:


$ sudo adduser greenfly

Then, I edited the /etc/group file as root, and anywhere I saw the pi user, I added my greenfly user to the list. In particular, you would want to add your new user to the sudo group, because the default sudoers file on the distribution gives any members of that group full sudo privileges. At this point, I also used ssh-copy-id to copy my public SSH key to this server so I could ssh in to it.

After I confirmed that I could log in as my user and sudo to root, I modified /etc/ssh/sshd_config and changed PasswordAuthentication to no, so I wouldn't have to worry about SSH brute-force attacks. Then, once I confirmed I could still ssh in, I deleted the pi user and removed its home directory:


$ sudo deluser --remove-home --group pi

Now that my user was set up, the next step was to remove all the desktop packages I would no longer need so I would have extra space for any services I wanted to install. There wasn't really a science to this; I just tried to pick base desktop packages I thought would have a lot of other desktop dependencies to remove:


$ sudo apt-get remove x11-common openbox-lxde omxplayer 
 ↪openbox libgtk2.0-common lxde-common xarchiver

Configure Bulk Storage

The base OS for the Raspberry Pi was on an 8GB SD card. I wanted the option to have more storage, and the folks at colo facility stated they would allow external USB drives as long as they were less than 4cm long. I had a 32GB USB stick that fit that profile and that showed up as /dev/sda when plugged in, so I then proceeded to partition it and format it:


$ sudo fdisk /dev/sda
$ sudo mkfs -t ext4 /dev/sda1

One thing I didn't do was add the disk to my /etc/fstab. I didn't want to risk the server stalling in the boot process either because the USB drive was unplugged or had failed, so I decided to add the mount statement to the end of /etc/rc.local.

While I'm are talking about /etc/fstab, I also decided I should set up some swap storage for the device. I don't plan on needing swap, but I didn't want an out-of-memory issue crashing the server. Unlike with a traditional server, on Raspbian, the recommendation is to use dphys-swapfile to create a swap file that it takes care of mounting for you:


$ sudo dphys-swapfile setup

By default, it picks a swap file size it feels is optimal for your system, but you always can edit /etc/dphys-swapfile and change the size.

The IP Change

While I could set up a local network to test the colocated network settings truly, I didn't want to go to the trouble, so the very last change I made to the system was the network settings. Before that point, I rebooted and updated the Raspberry Pi a few times and made sure I was still able to log in. Once I was ready, I edited /etc/network/interfaces and changed my eth0 network configuration from dhcp to static (IPs changed to protect, well, me):


auto eth0
iface eth0 inet static
        address 151.236.x.x
        netmask 255.255.255.0 
        gateway 151.236.x.1

What I Wish I Would Have Done

It turned out it cost me only around $5 to ship the Raspberry Pi from California to Austria with the US postal service. Of course, the moment I dropped it off, I started thinking about all the things I should have done. In particular, there are two things I wish I would have done.

First, I wish I would have set up a system so that the Raspberry Pi automatically e-mails me whenever it boots. That would have gone a long way toward helping my impatience while I waited for the server to be racked. Instead, all I could do was ping the IP and hope I set the network up right. To set it up to e-mail me, all I would have had to do is install the postfix package and during install time, configure it to be a standalone Internet mail server. Then I could install the mailutils package and add a mail command near the end of my /etc/rc.local file:


echo "I'm alive!" | mail -s "I'm alive!" me@mydomain.com

Then before I changed the network settings at home, I could have rebooted the system a few times and confirmed that the mail was sent.

The second thing I wish I would have done is pay extra for a tracking number! I was actually pretty angry with myself for forgetting to do this. Not only could I have known where the Raspberry Pi was while it was shipped, I would know when it arrived at the colo. Furthermore, without any tracking, any dishonest person along the way could have pocketed the Raspberry Pi and said it was lost in shipping.

You may be wondering what I'm going to use this Raspberry Pi for after all. Since there isn't much redundancy, I'm not going to host anything critical on it; however, I'm considering what kind of redundancy I could get if I partnered up and shared resources with a fellow Raspberry Pi colo customer. At the moment, I'm just using it to provide a network sanity check so I can perform network troubleshooting from outside the US. Beyond that, I have set up postfix and nginx on it and plan to run some sort of rudimentary Web service and possibly backup DNS. Keep an eye on this column for updates as I start to add services to it.

Resources

The EDIS GmbH Raspberry Pi Colo Product Page: https://manage.edis.at/whmcs/cart.php?gid=6

Raspberry Pi OS Download Page: http://www.raspberrypi.org/downloads

______________________

Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

mai

Anonymous's picture

i just want to show you this site , i found it very pleasant.

actually the mail command is probably incorrect...

David Gouveia's picture

If you are using bash and really want to use the exclamation mark, then you should escape it :P

I'm also thinking about shipping an rPi to Austria, but just like someone already said, there aren't free lunches so I'm still trying to figure out what's the catch! :)

Any update? :)

GreatNews's picture

It's been a while since you sent it, any update? What happened?

Thanks!!!

Helpful ideas

QL's picture

Thanks for the helpful ideas, especially the one about adding an email command to rc.local, and the mounting of a USB stick away from fstab. I chose to mount the stick at /home, but realised just before sending the Pi, that if I relied on keyed SSH access, if /home doesn't mount, I'm in trouble. So I created a "spare" user with a home directory on the main SD card to ensure I can get in even if the USB stick fails.
What a generous service, though. I hope I am able to pass on such generosity in some way to make someone else's life better and keep the goodness flowing.

IP address

Patito's picture

Sorry if my question is too stupid for words, but when I signed-up at EDIS they asked for an IP address. I am planning on using a free dyn dns service, and assumed that my IP would be changing constantly. Can someone help me get my head round this?

Thanks
Pato

... and now part of the official config-emails we send ... ;-)

Gerhard Kleewein's picture

Thanks a lot for all your efforts!
Gerhard

set up a old system

on ap's picture

I think I could manage this machine remotely. Once it was colocated, it became my primary server for Web, DNS, SMTP and my perpetual Irssi-in-a-screen session@ http://onaplioa.com.vn

Die iPhone Reparatur München erwartet sie und ihr Gerät

iphone reparatur münchen's picture

Austria ip is better but other ip address was not bad for your communications. If you follow it than you can imagine it very clearly. iphone reparatur münchen

I just want to show you this

agence de voyage maroc's picture

I just want to show you this site, I found it very pleasant.

No such thing as free. What's the rub

Anonymous's picture

No such thing as free. What's the rub

Wow nice :-)

dewc's picture

Neat! Free hosting and something cool you can do with your Pi!

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix