Raspberry Pi Home Server v2: Creating a Home Page

Note: This post is part of a series. Each post builds on the previous ones. If you are just trying to add one thing to an existing system that was not built following this series, then I cannot promise that these instructions will work for you, although they probably will. If you’ve started from something other than a non-NOOBS Raspbian image, then you’ll probably need to adjust for that.

Please refer to the series Introduction for a list of all the different posts in the series.

Self-Promotion: I have recorded this series as a screencast for Pluralsight:
(http://www.pluralsight.com/courses/raspberry-pi-home-server)
If you have a Pluralsight subscription, please consider watching it. Reading the instructions is one thing, but watching it done demystifies the whole process.

Thank you!


Over the course of this series, we’ve installed a number of packages that expose web interfaces on various ports, and it’s starting to get a little hard to keep track of. So far, we have

  1. Webmin: port 10000
  2. Transmission: port 9091
  3. Resilio Sync: port 8888
  4. Syncthing: port 8384

It’s getting hard to keep track of what port does what already. What we need is some kind of index with links to these various services. In this post, we’ll create a simple home page for the Raspberry Pi Home Server with links to the UIs for the various packages.

If you already have a web server running (e.g. Apache, Lighttpd, Nginx), then you can just use those. If you’re running WordPress, then you can just create a post with the links in it and make it sticky.

I’m not actually running WordPress on my Pi, so I’ll need to start from scratch. I’m going to show how to build the home page using Nginx (Engine-X). It’s significantly smaller and faster than Apache, and is very light on its resource usage, which makes it a great choice for the Raspberry Pi. Since it’s going to be serving up a very small and simple static web page, we don’t really need a full-blown Apache instance here.

As with most things, install Nginx using apt-get

sudo apt-get install nginx

That’s it. You now have a web server, and it’s already running. Open a browser, and go to the address of your raspberry pi with no port specified. You should see a “Welcome to nginx” page like this.

01-nginx

All we need to do now is customize that page to say what we want. The file we need to edit lives at /var/www/html/index.nginx-debian.html. This location has changed in the past, so the filename may not be exactly the same, but it should definitely be found in that location. Open it for editing.

sudo nano /var/www/html/index.nginx-debian.html

I’m going to make some simple changes, changing the title to match the name of the computer it lives on, and replacing the body with a simple list of available services. You can get as fancy as you want. Use jQuery and Bootstrap. Go nuts. Build the page of your dreams. For this demo, however, I will go with the simplest thing that works.

<!DOCTYPE html>
<html>
<head>
<title>RPHS</title>
<style>
  body {
    width: 35em;
    margin: 0 auto;
    font-family: Tahoma, Verdana, Arial, sans-serif;
  }
</style>
</head>
<body>
<h1>RPHS</h1>
<p>The following services are available:</p>
<ul>
  <li><a href="https://192.168.1.11:10000">Webmin</a></li>
  <li><a href="http://192.168.1.11:9091">Transmission</a></li>
  <li><a href="http://192.168.1.11:8888">Resilio Sync</a></li>
  <li><a href="http://192.168.1.11:8384">Syncthing</a></li>
</ul>
</body>
</html>

You can just copy and paste this over the existing content if you want. Rather than saving it over the original file though, lets save it as simply “Index.html”. Press Ctrl-O to save the file, and simplify the name when prompted. Nginx will use the new “Index” file instead of the old “index.nginx-debian.html” one. You can delete “index.nginx-debian.html” if you want, or keep it around.

There are a few things to note here. The links are all fully qualified from the static address down to the port. It is not possible through plain old html to create a link that goes to a different protocol (https) or port (10000) under the same root. You can do it through javascript, but since this server has a static IP address, I can safely assume that it’s not going to change on me, and this does the job for now.

I’ll leave it up to you to make your index fancier/prettier, but this accomplishes the job of keeping everything straight, even if it’s not very attractive.

Posted in Computers and Internet, Home Server, Raspberry Pi | Tagged , , , | Leave a comment

Raspberry Pi Home Server v2: Syncthing

Note: This post is part of a series. Each post builds on the previous ones. If you are just trying to add one thing to an existing system that was not built following this series, then I cannot promise that these instructions will work for you, although they probably will. If you’ve started from something other than a non-NOOBS Raspbian image, then you’ll probably need to adjust for that.

Please refer to the series Introduction for a list of all the different posts in the series.

Self-Promotion: I have recorded this series as a screencast for Pluralsight:
(http://www.pluralsight.com/courses/raspberry-pi-home-server)
If you have a Pluralsight subscription, please consider watching it. Reading the instructions is one thing, but watching it done demystifies the whole process.

Thank you!


Sync What?

SyncThing. It’s another cloud synchronization program, very much like Resilio Sync, which I covered earlier in the series. It’s a free and open-source project though, and offers most of the same functionality as Resilio Sync, although not as much a Resilio Sync with a Pro license.

I’m just putting it out there as an option, because it’s easily installed on the Raspberry Pi, and has clients available for just about any platform you’d care to run it on. I’m using it to mirror my public share to my CrashPi.

Note: Make sure you check out the Resilio Sync post in this series as well. Look at both options and decide which you like better. It seems that running both Resilio Sync and Syncthing at the same time works just fine, but you probably won’t need both.

Installing Syncthing

Syncthing has its own repository and signing key, similar to a few of the packages we’ve installed previously. Download and install the signing key like this.

wget -O - https://syncthing.net/release-key.txt | sudo apt-key add -

Here, we’re downloading the key file from Syncthing’s own site, and installing it by piping it directly into apt-get with the “add” keyword. This key is required in order for apt-get to install any packages that it was used to sign.

Next, add the Syncthing repository to APT’s list of known sources by creating a new source list. As with previous examples, I’ll create a separate file rather than just tacking onto the main sources.list file.

sudo nano /etc/apt/sources.list.d/syncthing.list

Paste in the following

deb http://apt.syncthing.net/ syncthing release

Exit nano, saving your changes (Ctrl-X, Y).

Tell apt-get to update its list of repositories, and then install Syncthing

sudo apt-get update
sudo apt-get install syncthing

Now we’re ready to start configuring Syncthing. Start Syncthing from the command line.

syncthing

Configuring from a Local Browser

If your Pi is hooked up to a monitor, and you’re running the desktop, then a browser window should open automatically, and in a few moments, the Syncthing web UI will appear.

01-web-ui

This web UI is very full-featured, and you’ll use it to set up folders that you want to sync between devices. I’ll show an example of that a little later on. The only problem is that the UI is only available from a local browser running on the same machine as Syncthing. If you don’t mind remoting in to make changes, then you can just skip ahead, but if you’re like me, you’d like to connect directly from the browser on your regular computer.

This is easy enough through the web UI. Click the “Actions” drop-down in the upper-right of the page, and then “Settings”.

02-settings

In the right-hand column, change the “GUI Listen Addresses” from “127.0.0.1:8384” to “0.0.0.0:8384”. This will allow Syncthing to be administered from other computers on your home network. We don’t want to leave it wide open to just anyone though, so fill in values for the “GUI Authentication User” and “GUI Authentication Password” as well. You can decide to make up an entirely different user name, or just use “pi” and its password. It’s up to you.

Configuring from a Remote Browser

If your Pi doesn’t boot to the desktop, or you’re doing this installation through a remote SSH session, then obviously the local browser is not going to be an option, but we can still make the required changes.

Now that Syncthing has been run once, it has created a config file where we can make the same adjustments. Press Ctrl-C in the terminal window to shut down Syncthing.

Open Syncthing’s config file using nano.

sudo nano ~/.config/syncthing/config.xml

Find the “gui” section. It should look something like this:

<gui enabled="true" tls="false" debugging="false">
    <address>127.0.0.1:8384</address>
    <apikey></apikey>
    <theme>default</theme>
</gui>

Change the “127.0.0.1:8384”, which refers to the local machine, in this case the Pi itself, to “0.0.0.0:8384”, which means any machine on the local network. Technically, you could forward a port through your firewall and make Syncthing accessible from outside your house as well, but there’s no reason to do that. If you set up a VPN as covered in my OpenVPN post, you can always connect securely to the Pi and make any changes you need from there.

Close nano, saving your changes (Ctrl-X, Y), and restart Syncthing from the command line.

syncthing

Give Syncthing a moment to get started up, and then open a browser from your regular computer. Connect to the Pi, port 8384. The web UI will open up, and after a few moments you can expect to see a warning that the web UI is now configured to allow remote access, but isn’t going to require a password.

nopassword

Click the “Settings” button, and fill in values for the “GUI Authentication User” and “GUI Authentication Password”. The same way as we did in the previous section. Click the Save button, and you’ll soon be prompter to re-authenticate with the name and password you just set up.

Sync some things

For a demonstration, I’ll be syncing a folder between two of my servers, my main Raspberry Pi Home Server, and my CrashPi (although sadly, CrashPlan isn’t working right now). By default, Syncthing already created a folder called “Sync” in the pi user’s home folder. Following the same directions above, I’ve installed Syncthing on my second server already, and it now has a similar default folder already created. All I need to do is introduce these two Syncthings to each other.

Click the Actions drop-down in the upper-right corner of the page again, and then “Show Id”. You’ll get a page with a QR code on it, as well as a text representation of this Syncthing’s “Device Id”. The QR code can be used by the mobile versions of Syncthing so that you can sync things to your phone. For now, copy the text above the QR code. Make sure you get the whole thing.

Switch to the Syncthing web UI running on the second device, and click the “Add Remote Device” button in the lower-left corner of the page. You may have to scroll a bit to see it. Paste the first Syncthing instance’s Device Id in the first field. Fill in a name so that you can keep track of which device is which, and then check the “Default Folder” checkbox at the bottom. Fincally, click “Save” to dismiss the dialog. There are a lot of other options here, but I’ll leave it up to you to explore Syncthing’s documentation on your own. Just click the “Help” button in the upper-right and you’re off.

Return to the web UI of the first Syncthing instance, and you should see a prompt asking you to confirm the addition of the second instance. This ensures that even if someone were to get ahold of your Device Id, they couldn’t just help themselves to your stuff. You need to give the okay first. Click “Add Device”, and you’ll see the same dialog that you were looking at a moment ago, but most of the fields will be filled in for you already. Check off the “Default Folder” checkbox again, and then click the Save button.

Finally, switch back to the other instance, and you’ll see another prompt asking you to confirm sharing the default folder.

Time to Test

Open a second Terminal window, SSH session, or simply use the file browser on the desktop to create a new file in the “Sync” folder that Syncthing created for you. Perhaps name it after the device on which it was created so we can keep track. Do the same on the other computer, and then observe what happens. If you’re lucky, the files will magically sync from one computer to the other. At the time I’m writing this, there’s some kind of bug when adding new folders, and you’ll need to go to the Actions drop-down and click “Restart” on both instances to get things flowing. After that though, the folders on each computer should stay in sync.

As with and file synchronization technology, it’s possible to have conflicts. If you edit the same file on both systems, or try to sync a file that receives regular changes from both places, things are going to get ugly. Rather than just clobbering what the other computer did, Syncthing will create “conflict” files, and leave it up to you to sort things out. This is good in that you won’t have one version simply overwriting another, but it does mean that you’ll have to be involved in fixing it when things go wrong.

Try to use Syncthing only for items that you want available everywhere, but will typically only make changes from one place at a time. Refer to Syncthing’s documentation for help with synchronization strategies.

Stopping Syncthing

Since we started Syncthing from the command line, that command line has been held up waiting for Syncthing to finish. You can press Ctrl-C in the terminal window to shut it down, or go to the Actions drop-down and click “Shutdown”. In either case, your command line will wake back up so you can issue more commands.

If you want to start Syncthing without locking up your command line, you can always append an ampersand (&) to the command to run it in the background.

syncthing &

Since you can’t hit Ctrl-C to stop it anymore, you’ll have to use the menu to shut down this instance if you want. Syncthing will also keep interjecting things into your terminal session, which can be annoying. This approach also means manually starting Syncthing every time you reboot, though.

Starting Syncthing automatically

Logging in and starting Syncthing manually isn’t going to work long-tern. Fortunately, Syncthing’s authors have done most of the hard work for you here. There’s already a service description set up and waiting for you. All you need to do is enable it and reboot.

sudo systemctl enable syncthing@pi.service
reboot

That’s it. When the pi reboots, Syncthing should be up and running as the “pi” user automatically.

At this point, I refer you to Syncthing’s documentation for more information on its configuration, care and feeding. It’s a very capable program, and I’ll be interested to watch its progress.

Posted in Computers and Internet, Home Server, Raspberry Pi | Tagged , , , | 1 Comment

Raspberry Pi Home Server v2: Web Administration

Note: This post is part of a series. Each post builds on the previous ones. If you are just trying to add one thing to an existing system that was not built following this series, then I cannot promise that these instructions will work for you, although they probably will. If you’ve started from something other than a non-NOOBS Raspbian image, then you’ll probably need to adjust for that.

Please refer to the series Introduction for a list of all the different posts in the series.

Self-Promotion: I have recorded this series as a screencast for Pluralsight:
(http://www.pluralsight.com/courses/raspberry-pi-home-server)
If you have a Pluralsight subscription, please consider watching it. Reading the instructions is one thing, but watching it done demystifies the whole process.

Thank you!


SSH is a simple way to remotely log in to your machine’s command-line interface, but that’s not always the most convenient way to work. There is a wonderful web administration system called Webmin that can handle a lot of the “magic” of system configuration. Webmin can take care of a lot of the tasks you’d normally do from the command line, but in a much friendlier way. In addition, you can add Webmin modules for many of the features we’ll be adding to the Raspberry Pi in this series.

Note that this is totally optional. Webmin doesn’t really give you anything that you can’t already get in other ways, and now that Raspbian images come with VNC remote desktop support built in, you can do pretty well without Webmin. It’s still a pretty convenient “dashboard” to check up on your Pi, though.

It’s pretty easy to install, so let’s get started.

You can’t just install Webmin through apt-get like the other software packages so far because apt-get doesn’t know about Webmin, or at least it doesn’t know about it yet. There are several approaches to a Webmin installation, but I’ve found that the easiest is to simply tell apt-get where to get the packages it needs for Webmin.

apt-get installs software based on a list of internet servers that it uses as sources to download from. You can edit the main apt-get source list, as I did in the previous version of this series, or you can add a new list specifically to support the one package you want to install. This has the advantage of keeping things separated rather than putting all your sources in one file together. This way, you know which sources were added to support which package.

Create a new list file just for webmin like this:

sudo nano /etc/apt/sources.list.d/webmin.list

When the editor appears, add the following line to the empty file:

deb http://download.webmin.com/download/repository sarge contrib

Note: The word “sarge” in the line above is the name of the distribution Webmin was created for. After Sarge was Wheezy, and then Jessie. Debian releases, and by extension Raspbian releases, are all named after Toy Story characters. Sarge is quite an old release at this point, but I guess the Webmin team haven’t needed anything that the Sarge release can’t provide, so they haven’t felt the need to move on yet. That doesn’t mean they’re not maintaining Webmin. At the time of this writing, the latest version in the Sarge repository was from October 3rd, 2016.

Press Ctrl-x,y,enter to exit nano, saving the file. Next you’ll need to import the signing key that verifies the packages coming from the new repository. These next few commands need to be run as the actual root user of the machine. This is the first time this series has done this, so I’ll break it down for you. Type the following to temporarily become the root user:

sudo su

Your command prompt will change, losing all of its color, and becoming more sinister, dark, and dangerous looking like this:

RPHS0401-su

You are now operating as the root user of the machine. The root user can do pretty much anything. Unlike the Windows world, Linux users try to spend as little time in “God-mode” as possible.

Type the following commands to import the Webmin repository’s signing key:

cd /root 
wget http://www.webmin.com/jcameron-key.asc
apt-key add jcameron-key.asc
exit

That last “exit” tells the system that you want to stop being the root user now, and go back to being “pi”. The final result should look like this:

RPHS0402-ImportKey.PNG

Now that you’ve added Webmin’s repository to the list of places apt-get will look for stuff, update the list of available packages again. According to commenter Kevin Liston,

sudo apt-get update

Now that apt-get knows where to get Webmin, you can install it using apt-get.

Note: You may need to install https support for apt get as well. I can’t confirm at this time because I already had it installed on all of my Pis anyway as part of other installations, but it is a good thing to have anyway, so I’ll include it here.

sudo apt-get install apt-transport-https -y
sudo apt-get install webmin -y

Once again, the “-y” will stop apt-get from asking us if we’re sure before continuing.

You can expect this installation to take a little while without providing a lot of feedback. Be patient. When the installation is complete, you can test it by opening a browser, and navigating to the IP address of your server, but specifying https and port 10000 rather than the default http port of 80. If you forget the “https” part, you’ll see a friendly page that offers to redirect you. Either way, you’ll probably also get a warning about the site not having a valid certificate, which of course it doesn’t. Since you own this server, though, it should be safe. Proceed to the page anyway, and you’ll see a login page like this:

RPHS0403-Login

Log in as “pi”, and you’ll see the main Webmin interface, which looks like this:

RPHS0404-Webmin.PNG

Poke around a bit, and see what Webmin is all about. You can monitor storage and memory usage from here, be notified about updates, apply them, manage user accounts, and a lot more. You can accomplish a lot of the same tasks over SSH, but Webmin can make things a bit more convenient, and is available from any computer on your home network without having to install an SSH client.

Look inside the “Un-used Modules” section to see all the things that Webmin could help you manage, if you had those packages installed. It’s a pretty impressive list.

Wrapping up

You’ve reached another milestone, and I strongly recommend politely shutting down the Raspberry Pi (sudo shutdown –h now), and taking another backup of the SD card or OS partition.

Posted in Computers and Internet, Home Server, Raspberry Pi | Tagged , , , | 3 Comments

Raspberry Pi Home Server v2: CrashPlan-less CrashPlan

Note: This post is part of a series. Each post builds on the previous ones. If you are just trying to add one thing to an existing system that was not built following this series, then I cannot promise that these instructions will work for you, although they probably will. If you’ve started from something other than a non-NOOBS Raspbian image, then you’ll probably need to adjust for that.

Please refer to the series Introduction for a list of all the different posts in the series.

Self-Promotion: I have recorded this series as a screencast for Pluralsight:
(http://www.pluralsight.com/courses/raspberry-pi-home-server)
If you have a Pluralsight subscription, please consider watching it. Reading the instructions is one thing, but watching it done demystifies the whole process.

Thank you!


Important notes:

Of all the parts of this series, this is the one that seems to have the most frequent breaking changes. Every time I turn my back, CrashPlan updates itself and throws out all of the patching and tweaking that made it work on the Pi in the first place, and the most recent breaking changes are pretty terminal.

At the current time, there is no simple way to get things working properly on the Pi. There are some hacks to install an old version and prevent it from updating itself, but they have problems of their own. For instance, you’ll keep getting emails from Code42 insisting that nothing has been backed up in weeks or months, even though CrashPlan itself reports that things are going just fine.

There’s also the issue of version compatibility. The CrashPlan instance running on your desktop will keep on updating itself, and eventually the difference between the version on the Pi and the version on your desktop will be so far out of sync that they will probably refuse to talk to each other, so in this version of the server, I’m going to go with a workaround that should be more permanent, but has significant drawbacks over a full installation. At the very least, this will get you a working backup for safety while I continue to research a way to get the full system running again.

You can refer to the original CrashPlan article, and the enormous tail of comments it has grown if you want to try to install CrashPlan directly on the Pi. I’m going to sidestep that and not install anything on the Pi at all.

CrashPlan-less CrashPlan

The secret is that since v4.3, CrashPlan has grown the ability to be installed on a per-user basis. This will allow CrashPlan to back up to a network location, which it can’t do otherwise. There are good reasons for this, but we don’t need to go into them here.

This ability comes with a cost, though. Since CrashPlan won’t be running as a service in the background when no-one is logged in anymore, the computer won’t get backed up until you log back in. If you’re the only user of a particular computer, then this won’t really matter. Instead of logging out at the end of the day, just lock the computer, and everything should still work just fine.

Create the backup share

Create an entirely new share as described in the Samba post, or a “backups” folder inside your existing public share. I’m creating a new share for organizational purposes. Linux or Mac OS user will need to create a symbolic link to the share somewhere in their filesystem. Windows users will “Map” the share as a drive letter or location within NTFS.

Navigate to the backup share or folder in Windows Explorer (e.g. \\rphs\backups). Right-click the backup share you created above and then “Map Network Drive”. Choose an unused drive letter, and leave “Reconnect at sign-in” selected.

Note: This screenshot is from me setting up my CrashPi as a destination.

01-map-drive

Per-user CrashPlan

Install or re-install CrashPlan on your main computer following Code42’s per-user instructions. Basically, uninstall CrashPlan if it’s already installed, and then re-install choosing “Onlyfor me” when prompted for an installation type by the installer.

02-only-me

You’ll need to go through the whole CrashPlan setup process again, signing in to your account, providing a password, etc. If you were backing up to an external hard drive, then you should “adopt” that backup to avoid starting over from scratch.

Once you’re past all of that, you can now add the new, mapped network location as a destination.

03-network-locations

After this, it’s business as usual. When your computer is on the home network, CrashPlan will see the mapped drive and back up to it. If your computer is portable, then when you’re on another network the drive will simply not be available, and CrashPlan will stop backing up until the mapped drive is available again. There’s one little wrinkle, though. If CrashPlan notices that a folder destination has gone offline, it doesn’t seem to be very good at noticing when it comes back. This presents a problem for laptops, and may require you to restart before CrashPlan will notice the location and start using it.

It’s not quite as nice as having a real remote CrashPlan instance, but it will do for now, and won’t break when Code42 pushes out an update every week. Windows may complain that not all mapped drives could be reconnected when you sign in, and you may have to reboot for CrashPlan to see the network location, which can be kind of irritating. But it works, and, more importantly, will continue to work. It just takes a little more hand-holding. If you’re backing up from a computer that’s always on the home network like a desktop, then this won’t affect you.

I’ll keep evaluating this approach, and hope that a better solution comes along, but this’ll get you a working backup solution until then.

Posted in Computers and Internet, Home Server, Raspberry Pi | Tagged , , , | 2 Comments

Raspberry Pi Home Server v2: Transmission

Note: This post is part of a series. Each post builds on the previous ones. If you are just trying to add one thing to an existing system that was not built following this series, then I cannot promise that these instructions will work for you, although they probably will. If you’ve started from something other than a non-NOOBS Raspbian image, then you’ll probably need to adjust for that.

Please refer to the series Introduction for a list of all the different posts in the series.

Self-Promotion: I have recorded this series as a screencast for Pluralsight:
(http://www.pluralsight.com/courses/raspberry-pi-home-server)
If you have a Pluralsight subscription, please consider watching it. Reading the instructions is one thing, but watching it done demystifies the whole process.

Thank you!


Sometimes you want to download something large. “Transmission” and “Deluge” are cross-platform BitTorrent servers that will run quite happily on a Raspberry Pi. They can be used to host, or “seed” a torrent for other users to download, or to download other people’s torrents for you, freeing up your main computer to do other jobs or to sleep.

What’s a BitTorrent?

Let’s say I wanted to download the current Raspbian image file. I could get it straight from the Raspberry Pi website, but that means that I’m competing for bandwidth with all of the other people trying to get that same file, and that bandwidth is costing the Raspberry Pi Foundation money, money they could be using to build more cool toys.

Torrents work by asking all of the computers downloading a particular file to talk to each other and trade the bits they already have amongst each other instead of everybody downloading the same bits of the same file from the Raspberry Pi Foundation’s server. Through the magic of BitTorrent, one computer could says to the others “Hey, I already have the first half of the file, does anyone have the second?”, and another computer might answer “Well, I don’t have the whole second half, but I have most of it. I’ll give you what I have if you give me the first third, ‘cause I’m totally missing that”.

At the center of it all is one computer that started the whole thing off by hosting the complete file first, and staying on to serve as “matchmaker” when new computers get added to the mix. In the case of the NOOBS software, that’s the Raspberry Pi Foundation’s server again. The foundation’s server started with a complete copy of the file, from which it created a .torrent file. The .torrent file describes the file you’re trying to get, providing information like how big it is, how many chunks it’s been broken into, and providing a checksum hash of the complete file so that you can be sure you got all the pieces right, and to stop jerks from ruining it for everyone by hosting files with the wrong bits in them.

You start a download of the large file you want by first downloading the much smaller .torrent file. You feed this file to a BitTorrent client like Transmission or Deluge, which contacts the original server to see what peers are online sharing the load. Then, the client starts getting bits from all the different peers in the network, and only contacting the original server for those parts that no-one else has yet.

When the download of the large file is complete, the client stays online as part of the network, and just keeps on sharing (or “seeding”) the bits of the large file to anyone else who might need them.

Torrents have a kind of a bad reputation since they have become a kind of ersatz peer-to-peer file sharing mechanism for trading things like Hollywood movies, but they can be terribly useful for anyone that wants to mitigate the bandwidth costs of distributing large files on the internet.

Transmission vs. Deluge

The first thing you’ll want to decide is whether you want to go with Transmission or Deluge. They both do the same job, but Transmission’s interface is much simpler. Transmission got a bad reputation of its own when its installer was found to be spreading malware twice in 2016. This apparently wasn’t a purposeful attack by the Transmission team, and they moved quickly to correct the situation, but some people are uncomfortable with Transmission even now.

There is an excellent guide to installing Deluge at HowToGeek, but for now, I’m sticking with Transmission for its pure ease of installation on the Pi. I may do a Deluge write-up later on, in which case I’ll update this post to refer to it, but for now I’m just going to show you how to install and configure Transmission.

I don’t recommend installing both at the same time. While their respective web front-ends use different ports, their background daemons will want to use the same port, and will interfere with each other. I’m sure you can configure your way around this, but you only need one anyway. Pick your favorite and install it.

Note: I have found Transmission to be one of the most destabilizing influences on the Pi. I have not yet given Deluge a full test, but with Transmission running, my Pi becomes very sluggish and unresponsive when downloading very large torrents. On average, this may not affect you, but I suspect it has everything to do with the size of the thing you’re downloading. I’m talking about multi-hundred gigabyte downloads here, much larger than your average download. I’m not sure Deluge would fare much better, but I intend to find out at some point. If you regularly download HUGE items, then you may want to dedicate a second Pi with its own hard drive to this task rather than your main home server.

Installing Transmission

To install the Transmission daemon (that’s a service to you Windows folks), type the following at the command prompt.

sudo apt-get install transmission-daemon

It’s a pretty simple installation, but will require some configuration before it’s ready to use.

Configuring Transmission

Before editing the configuration file, make sure the transmission daemon is stopped.

sudo service transmission-daemon stop

Transmission keeps its settings in a JSON-formatted text file. Use Nano to edit it.

sudo nano /etc/transmission-daemon/settings.json

Change the following settings, modifying the download path to match whatever you called your external drive, and changing the user name and password. I’m going to make mine match the pi user so it’s easier to remember. Don’t worry about the password being in plain text. After we restart the Transmission daemon, it will encrypt the setting so no-one will be able to read it.

"download-dir": "/mnt/data/public/downloads",
"rpc-enabled": true
"rpc-whitelist-enabled": false
"rpc-username": "pi"
"rpc-password": "raspberry"

Note: You could limit the computers that are allowed to see Transmission’s web interface by leaving “rpc-whitelist-enabled” set to true, and then entering a comma-delimited list of IP addresses. You could also set the whitelist to “192.168.*.*” to allow any computer on the local network to see the interface. Since I’m not exposing Transmission’s ports through my firewall, turning the whitelist off achieves pretty much the same effect though.

Exit Nano, saving your changes (ctrl-x,y,enter).

Once again, a program is managing its own list of passwords. You get that a lot in the Linux world. I’ve kept the default user name of “transmission” here, and used the default password for “pi”. Pick whatever you want. Finally, restart the transmission daemon (service).

sudo service transmission-daemon start

Transmission provides its own web interface, so there is nothing to add to Webmin. Open a browser and navigate to the Raspberry Pi, port 9091, and after logging in with the credentials you created in the config file, you should see the Transmission interface.

Time to give back

At this point, I’d like to suggest that you seed the archives for NOOBS and other Raspberry Pi images. Click on the open folder icon in the top left, enter the url of one of the torrent files, and click “Upload”.

The latest version of the NOOBS and Raspbian torrents are always available from the following addresses:

A row for each .torrent file you upload will be added to the list, and the torrent will begin downloading. Click on the new row to select it, and click the blue “i” icon in the upper right to get more detailed information about how the download is progressing. When all the bits have finished downloading, and a torrent goes into “seeding” mode, its progress bar will turn green like this:

image

You might consider seeding all of the Raspberry Pi images if you can spare the space. Remember to pay attention to how much CPU is being used, and don’t overtax your Pi. If you seed too many torrents, there may not be much CPU left for other tasks.

There are Transmission “remote control” applications available for many platforms that will give you greater control over the download process, but they are beyond the scope of this post. You can start by looking at the Add-Ons section of the Transmission website (https://www.transmissionbt.com/resources)

Wrapping up

Now that Transmission is installed and running, you should shut down the Pi and take a backup of the SD card or OS partition as usual.

Posted in Computers and Internet, Home Server, Raspberry Pi | Tagged , , , | 1 Comment

Raspberry Pi Home Server v2: Backing up the OS partition

Note: This post is part of a series. Each post builds on the previous ones. If you are just trying to add one thing to an existing system that was not built following this series, then I cannot promise that these instructions will work for you, although they probably will. If you’ve started from something other than a non-NOOBS Raspbian image, then you’ll probably need to adjust for that.

Please refer to the series Introduction for a list of all the different posts in the series.

Self-Promotion: I have recorded this series as a screencast for Pluralsight:
(http://www.pluralsight.com/courses/raspberry-pi-home-server)
If you have a Pluralsight subscription, please consider watching it. Reading the instructions is one thing, but watching it done demystifies the whole process.

Thank you!


Now that the Raspberry Pi Home Server is up and running off of the hard drive, we’re presented with a problem. We can’t just take a backup of the SD card anymore. In fact, what’s on the SD card probably shouldn’t change from this point on. All the important stuff is on the OS partition of the hard drive.

In this post, I’ll present a couple different methods for backing up the hard drive using a secondary computer, or just using the Pi itself and a second SD card.

Backing up from a Windows computer

I’ve been using and advocating HDD Raw Copy over Win32DiskImager in this second edition of the Raspberry Pi Home Server series because of its ability to compress the image files on the fly, and that ability can be put to good use here as well. All you need to do is hook the Pi’s hard drive up to your Windows computer, and use HDD Raw Copy to copy the drive to an image file just like you’ve been doing with the SD card. It’s exactly the same process. If you’re using Win32DiskImager, the process is the same, only the resulting image files will be the same size as the drive you’re backing up, which brings me to the downside of this method.

Both HDD Raw Copy and Win32DiskImager are going to want to back up the entire hard drive. Not just the OS partition, but the data partition as well. If you have the space to keep that kind of backup around, then good for you, you can restore the entire server, including the OS and Data partitions as well as all of their contents in one go. It’s going to be slow, and it’s going to take up space, but you can do it.

This is part of the reason I keep my actual shared stuff on a completely separate drive now. I like the separation between the devices that make up the Pi itself, and the stuff that the Pi is sharing. I only have to back up a 120GB drive, and it’s mostly empty space, so my compressed image files are not that large.

If you can build your setup like this, I highly recommend it. If not, then you’ll need to continue reading and decide which is right for you.

Backing up from the Pi itself

If, for some reason, you don’t have access to a full Windows, Mac, or Linux computer, you can back up your hard drive by using another Pi. If you’re stranded alone on a desert island and only have a single Pi with you, then you’ll need to do a little prep work, the first step of which will be establishing a power grid.

Since this is the worst-case scenario, we’ll get it out of the way now. We’re going to create another SD card specifically for making backups. The Raspbian Lite image will have everything we need on it, or you can use a full Raspbian installation too. Just prepare another SD card, exactly like we did in “Installing the OS“, and then proceed to the “Backing up from Linux” section.

Backing up from Mac OS

Mac OS is built on top of Unix, which Linux is a sort of clone of, so things work pretty much the same there. You’ll just need do the same thing as the Linux users in the next section.

Backing up from Linux

The process for backing up from Linux is exactly like what you did to create the SD card in the first place, except that you’ll be using dd to copy from the Pi’s OS partition to another spot in your filesystem. This could be somewhere on the hard drive of your main computer, but for this demo I’ll be creating an image of the OS partition on the Data partition of the same drive. Just adjust the file paths to match where you want the image and you’re set to go.

Shut down the Pi, and transfer the hard drive to your main computer, or swap SD cards to the new one you created above. If you’re doing this from a single Pi, then I would also take this opportunity to unplug any other drives you might be using, leaving nothing but the system drive attached, and then start up the Pi with the new SD card.

Use blkid to figure out where the Pi’s hard drive got attached (not mounted, mind you).

sudo blkid

In my case, the hard drive shows up at /dev/sda, and the partitions are /dev/sda1 and /dev/sda2, with sda1 being my OS partition, and sda2 being my data partition. If you’re using a separate Linux system, then sda is probably your own hard drive, and the Pi’s drive will be sdb, sdc, sdd, etc.

I’m writing my image to the second partition of the same hard drive, so I’ll need to mount it first so that I can write files to it. Since this is the first time I’m doing this, I’ll also need to create a placeholder directory for the drive to mount at.

sudo mkdir /mnt/data
sudo mount /dev/sda2 /mnt/data

Now, we’ll use the dd command to copy the sda1 partition to sda2 (or wherever you’ve decided to store the image). The dd command is part of “coreutils”, and newer versions have the ability to give you a progress report as they go. See which version you are running.

dd --version

If it says 8.24 or above, you’ll be able to get a status report with the “status=progress” switch. Back up the OS partition like this.

sudo dd bs=1m if=/dev/sd?? of=IMAGEPATH.img status=progress

Unfortunately, Raspbian is still on 8.23 at the time I’m writing this, so status=progress won’t work. If your OS partition is still relatively small, then doing without feedback is a perfectly viable option, so you can proceed like this.

sudo dd bs=1m if=/dev/sd?? of=IMAGEPATH.img

If your OS partition is very large, or you opted to have just one partition, then you’ll probably want some kind of feedback. Install the dcfldd package through apt-get.

sudo apt-get install dcfldd

The syntax for dcfldd is very similar to that of dd, but it will report its progress as it goes.

sudo dcfldd bs=1m if=/dev/sd?? of=IMAGEPATH.img

When the copy is complete, you can shut down the Pi, or safely remove the hard drive card from your main computer, plug it back into the Pi or swap your SD cards back to normal, make sure everything’s hooked back up like it was before, and restart the system.

Restoring from a backup image

If you need to restore your system to a previous state, the process is just the same, but with the “if” and “of” parameters flipped like they were when you created the original SD card. You’ll need to read from the image file and write it to the hard drive partition.

Shut down the system and move the hard drive to the computer that will be doing the restore, or swap to the “backup” SD card if you’re doing this directly from the Pi, and run the dd or dcfldd command as appropriate. Don’t forget to mount the data partition if you’re doing this from the same Pi. You might want to edit the /etc/fstab file so that this happens automatically whenever you’re using your “backup” SD card.

sudo dd bs=1m if=IMAGEPATH.img of=/dev/sd??

or, if you’re doing this from the same Pi

sudo mount /dev/sda2 /mnt/os
sudo dcfldd bs=1m if=/dev/sd?? of=IMAGEPATH.img

Easy, right?

What’s next?

Everything after this point is purely optional. Return to the Introduction, and follow whatever links you want, mixing and matching whatever additional components you want your server to have.

Posted in Computers and Internet, Home Server, Raspberry Pi | Tagged , , , | Leave a comment

Raspberry Pi Home Server v2: Booting from the hard drive

Note: This post is part of a series. Each post builds on the previous ones. If you are just trying to add one thing to an existing system that was not built following this series, then I cannot promise that these instructions will work for you, although they probably will. If you’ve started from something other than a non-NOOBS Raspbian image, then you’ll probably need to adjust for that.

Please refer to the series Introduction for a list of all the different posts in the series.

Self-Promotion: I have recorded this series as a screencast for Pluralsight:
(http://www.pluralsight.com/courses/raspberry-pi-home-server)
If you have a Pluralsight subscription, please consider watching it. Reading the instructions is one thing, but watching it done demystifies the whole process.

Thank you!


Running the Raspberry Pi off of an SD card is simple, affordable, and very convenient. SD cards are also very small compared to hard drives, though, and they can only be written to a finite number of times. That number is ridiculously large, but it can still be used up faster than you think by things like virtual memory swap files which are written and re-written constantly.

If you plan to run this server 24/7 and actually use it, you’re probably going to want something a little more robust. My current setup is using a 120GB SSD for the system drive. I’m using an SSD because it can be powered entirely from the Pi’s USB port. I could have gone with something smaller, both storage-wise and physically by buying a small MSata drive and an adapter, but in the end it was cheaper to buy a normal 2.5″ SSD and put it in a case I already had.

This SSD has two partitions on it. The first is the “os” partition, which I left free back in the post “Adding a Hard Drive“. The second is my “data” partition, and holds information about my collection such as MiniDLNA’s database. I don’t actually put my media files or public share on the data partition anymore. My public share now lives entirely on an external RAID enclosure. In the original version of this post, I used the RAID box as the system drive, but over time I have discovered that RAIDs don’t work very well in this capacity, so I just use the RAID for my shares now. Everything that is the Raspberry Pi Home Server itself lives on the SD card and on the SSD.

Your setup doesn’t need to have as many moving parts, though. A typical Raspberry Pi Home Server setup might consist of a Raspberry Pi attached to a single, very large, hard drive. You can get 5TB external drives for under $150 these days. You only need to partition off a small space for the Pi to boot from, and the rest is yours to store most, if not all, of your stuff. This is how my CrashPi works.

Booting from a hard drive

Okay, I’ll level with you. You can’t actually boot entirely from the hard drive, at least not yet. The Raspberry Pi 3 has a USB boot mode, but it’s still considered experimental at this time and you have to do some tweaks to even make it available. You can boot mostly from the hard drive today though, and it should be easy enough to adapt this post in the future when the Pi 3’s alternate boot modes are considered finished.

When the Raspberry Pi boots up, it looks to the first partition on the SD card for instructions on what to do next. That boot partition contains just a tiny piece of the boot process. You can easily move all the stuff that comes after that first step to a different device, such as the external hard drive. All that stays behind on the SD card is a very small boot partition, everything else moves to the hard drive.

The resulting system should run faster and smoother, and you won’t be using up your SD card’s limited number of write cycles on high-frequency stuff like a virtual memory swap file.

Acknowledgements

This article would not have been possible if not for others that went before me. In particular, Ted Hale’s article at http://raspberrypihobbyist.blogspot.com/2013/07/running-from-external-hard-drive.html is pretty much the blueprint I started from. In turn, that article was based on a forum post by “Rattus” at http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=10914&p=129474&hilit=resizefs#p122476.

I’ve added my own bits, such as consulting the boot/cmdline.txt file rather than simply assuming the root file system’s location, using UUIDs to identify the partitions, and expanding the existing swap file rather than creating a separate swap partition.

I’ve turned these resources into a walkthrough that matches the rest of this series, but I wanted to at least point out where my source material originated.

Shut down services

We’d like as little to be going on with this partition as possible while we’re copying it. If you have another Linux system, or another Raspberry Pi handy and a USB adapter for your SD card, then your best shot is to let another system do this copy, but for this tutorial, I’m assuming you only have the one Pi available. To make sure things are as “quiet” as possible, we’re going to want to exit the desktop, shut down any of the background services we’ve installed, and do the copy from the command line.

First, let’s boot to the command line. If you’ve configured the Pi to boot to the desktop, then unfortunately there’s no option to simply exit the desktop, so we’ll need to tweak the configuration first. Use the desktop configuration tool or raspi-config to set the pi to boot to the command line.

01-boot-to-cli

Reboot the Pi, and connect via SSH using a tool like PuTTY, or connect the Pi to a monitor and work directly from the Pi. I’ll be using PuTTY for this demo.

Once you’re logged in, shut down any of the services you’ve installed so far. For me, that’s Samba, MiniDLNA, OpenVPN, Resilio Sync, and NUT. If you have any other services like CrashPlan or Transmission running, you’ll want to stop those too.

sudo service samba stop
sudo service minidlna stop
sudo service openvpn stop
sudo service btsync stop
sudo service nut-monitor stop
sudo service nut-client stop
sudo service nut-server stop
sudo service nut-driver stop

We want as little activity going on as possible while we clone the OS partition.

Copy the old root partition to the new drive

The file /boot/cmdline.txt specifies the location of the root filesystem. You’ll need to edit this file later in order to boot from the hard drive, but for now, you just need to know for sure where the root filesystem currently resides. Show the cmdline file’s contents like this:

cat /boot/cmdline.txt

image

The part immediately to the right of “root=” specifies the device and partition that holds the root filesystem, and that’s the partition whose contents you need to move to the hard drive. In my case, it says “mmcblk0p2”. If you started from a raw Raspbian image, then yours probably says the same thing. I can’t guarantee that the default Raspbian image might not change in the future though, so it’s best to check.

Copy the existing root partition’s contents to the new 16GB partition (sda1) on the hard drive, changing the highlighted part to match the current root filesystem path from above.

Important: Be very careful here. Make sure that sda1 is the partition you set aside for the OS. If you configured your server differently, then double-check before continuing.

sudo dd if=/dev/mmcblk0p2 of=/dev/sda1 bs=32M conv=noerror,sync

This can run for quite a while, depending on how large your SD card is. Unfortunately, the dd command doesn’t give you any kind of feedback. In this case, no news is good news. As long as the drive appears to be busy, then keep waiting.

Here’s what that all means:

  • “dd” copies things
  • “if” specifies the input file, in this case an entire partitions
  • “of” specifies the output file
  • “bs” specifies how many bytes to copy in one chunk, here it’s 32 MB
  • “conv” specifies how to convert things as they are copied
    • noerror says to continue if anything goes wrong
    • sync does some padding during the copy

When the copy process eventually finishes, check the target partition on the hard drive for errors.

sudo e2fsck -f /dev/sda1

Press enter at the prompts to fix any errors that it finds. You can probably expect one about the free block count, and one about the free inodes count.

Since the image that you just copied over from the SD card needs to be smaller than the partition you copied it to, you’ll want to expand it to fill up the available space.

sudo resize2fs /dev/sda1

Uniquely identifying a drive

This next section is a partial repeat from the “Adding a Hard Drive” post, but I’ll include it again for completeness, and so that you don’t have to bounce back and forth between the posts.

Warning: Because the next section involves copying around large strings of unmemorizable data, I recommend performing the steps through a remote SSH window, or from a terminal on the X desktop. The ids you’ll need to copy must be copied verbatim, letter for letter, or you’ll find yourself unable to boot, and you’ll have to start over again from your last backup.

Currently, the cmdline.txt file specifies that the root file system is on the second partition of the internal SD card (/dev/mmcblk0p2). We’d like that to say “/dev/sda1″ instead, but there’s a problem. As I mentioned earlier, we don’t have any guarantee that this particular drive will be called “sda” in the future. What we need is a way to uniquely refer to this drive no matter what letter it get assigned on any given day.

This was why we built the drive with a GUID Partition Table. Each partition on a GPT device is assigned a universally-unique identifier (UUID).

Note: The difference between GUID and UUID is not important here, they are different terms for the same thing; a very long, randomly-assigned number.

Get the partition UUID for /dev/sda1

sudo blkid /dev/sda1

The piece of information we’re interested is the “PARTUUID” value. Take a picture, write it down very carefully, or select and copy the text if you are doing this through a remote terminal connection like I am.

Boot Configuration

The new root filesystem’s partition is now uniquely identifiable, but the Raspberry Pi doesn’t know to use it. Edit the /boot/cmdline file to change where the bootloader will look for the root filesystem.

sudo nano /boot/cmdline.txt

Find the part that says “root=/dev/mmcblk0p…” and change it to “root=PARTUUID=” and whatever your Partition unique GUID was from above. Also add the string “rootdelay=5” at the end. This will give the Raspberry Pi time to discover the USB drive before it tries booting from it.

The result should look like this (sorry for the small picture):

image

Exit Nano, saving your changes (ctrl-x,y,enter)

Reboot (Important, do not skip this step)

Before the next set of changes will “stick”, you’ll need to reboot so that the Raspberry Pi uses the hard drive for the initial load. If you don’t reboot now, nothing you’re about to do will count, and you’ll just have to do it all again. You’ve been warned.

sudo reboot

If everything goes well, you should find yourself back at a login, and you can continue. If something went wrong, go back to your most recent backup and try again.

Mounting filesystems

Partitions and filesystems are not the same thing. Linux now knows what partition to load the OS from, and that’s great, but as things stand right now, it’s still going to mount the root filesystem from the SD card.

To complete the transition to the hard drive, you’ll need to edit the filesystem table. This file controls what gets mounted where, and in what order, and it needs to know where the root filesystem is. Take a look at the current contents.

cat /etc/fstab

image

Note: You’ll probably have an entry here for your data partition that we added earlier in the series.

That third line is the root filesystem, which you can tell by the “/” in the second column. Unfortunately, it’s still loading from the 2nd partition on the SD card (mmcblk0p2). You could change this to say “/dev/sda1”, but that would only work as long as the drive continues to get the name “sda”.

Fortunately, you can use a very similar UUID-based trick here to uniquely identify the filesystem no matter what letter the device gets. Filesystems have UUIDs too, and you can see them all with this command:

sudo blkid

image

If you look carefully, you may notice a problem. both /dev/mmblk0p2 and /dev/sda1 have the same UUID. So much for being unique, right? This is because of the way we cloned the old root filesystem into a new location. It brought the whole filesystem over, including its UUID. Before you can use a unique Id to identify the drive, you’ll need to make sure it’s actually unique.

You need to give /dev/sda1 a new UUID. You can hand-assign your favorite UUID, or just let the computer pick a random one. Use the following command to assign a new UUID to the first partition on the hard drive:

sudo tune2fs /dev/sda1 -U random

Note: At the time of this edit, there seems to be an issue with the newer “Jessie” release of Raspbian, and it may prevent you from changing the UUID on the partition. If you see an error that says “The UUID may only be changed when the filesystem is unmounted.”, even though it’s NOT mounted, then you’ll need to perform one more tweak. The magic words are

sudo tune2fs -O ^uninit_bg /dev/sda1

I can’t take credit for this one at all. I just found it here. After reading the man page on tune2fs, I still don’t honestly even understand what this has to do with anything, but it does seem to do the trick, so if you get the above error, give this command a shot, then try the “-U random” command again and it should succeed.

Either way, display the device Ids again, just to be sure

sudo blkid

image

Copy down the UUID value (not the PARTUUID value) for /dev/sda1. You’ll need it in a minute. Open the filesystem table in an editor.

sudo nano /etc/fstab

Change “/dev/mmcblk0p2” on the third line to “/dev/disk/by-uuid/” and the new UUID you just assigned to /dev/sda1.

The end result should look like this:

image

Your ids will obviously differ, but the important thing is that you have pointed the root filesystem to the hard drive. Any other mounts you’ve defined should appear here as well. Don’t worry about the columns lining up, it doesn’t matter, but I’m presenting mine to the public, so I’ve gone ahead and made it pretty

Exit Nano, saving your changes (ctrl-x,y,enter)

That’s it. you’re ready to reboot again, and this time, everything should be faster.

sudo reboot

You’ll notice that the activity light on the Raspberry Pi will not blink much anymore. That’s because the SD card is no longer being accessed for anything other than the boot partition. The hard drive’s activity light will now blink where the Raspberry Pi’s activity light used to.

When the system has rebooted, double-check your filesystem table to make sure your changes are still there.

cat /etc/fstab

If you see /dev/mmcblk0p2, and no line for your data partition, it’s because you skipped that “Reboot” step above. See? I told you it was important. Redo everything in the “Mounting filesystems” section, and reboot again.

Swap configuration

One thing you may have noticed if you’ve looked at other walkthroughs for booting from the hard drive is that they usually create a “swap” partition on the hard drive to be used as virtual memory.

If you look back at the filesystem table from the beginning of this post, though, you’ll notice that Raspbian never had a swap partition in the first place. That’s because Raspbian is set up to use swap files instead of swap partitions. Raspbian’s swap file lives at /var/swap, and since we just moved the whole root filesystem onto the hard drive, the swap file came along for the ride.

At this point, you’re already running your swap file from the hard drive, and you didn’t even have to do anything. Check it out with the “swapon” command:

sudo swapon –s

This shows the swap summary, which will tell you what swaps are in use. It should have one entry in it (/var/swap). It’s pretty small, though; only 100MB:

image

The partition we created for the root filesystem is 16GB (or more if you so chose). There’s plenty of space left to expand the swap file to something roomier.

Edit the swap file configuration:

sudo nano /etc/dphys-swapfile

Find the line that says “CONF_SWAPSIZE=100”. This is the size of the swap file in megabytes. Change the value to 2048, which will create a 2GB swap file, which is a more appropriate for a server running on a Raspberry Pi 2 or 3.

Close Nano, saving your work (ctrl-x,y,enter).

We’ll need to reboot one more time to get this to stick, but there’s another change to make first. If you’d like to return to booting to the desktop, now is the ideal time to set that back up using raspi-config.

sudo raspi-config

Go to “Boot Options”, then “Desktop/CLI”, and set it back to “Desktop”. When you exit raspi-config, it will offer to reboot. Go ahead and let it.

Once the system has rebooted, check the swap file by typing “swapon –s” again. You should see a table similar to the first time you ran this command, only now the swap file is much larger:

image

Wrapping up

You now have a Raspberry Pi that boots (mostly) from an external USB drive. It also uses this drive for its virtual memory swap file. The whole system should run more smoothly now, and you won’t have to worry about using up your SD card, if that’s the sort of thing you worry about.

Although most of the important stuff is on the hard drive, you should probably make at least one more backup of the SD card for safety.

What’s Next?

In the next post, I’ll show you how to make backups now that the SD card isn’t being used for the root filesystem anymore.

Posted in Computers and Internet, Home Server, Raspberry Pi | Tagged , , , | 3 Comments