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.
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.
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
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
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
ssh-copy-id to copy my public SSH key to this
server so I could
ssh in to
After I confirmed that I could log in as my user and
sudo to root, I modified
/etc/ssh/sshd_config and changed
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
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!" email@example.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.
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 VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide