My last two posts talked about how I used a Raspberry Pi to act as a low-power home server that now mainly serves two functions: as a NAS box and as a Torrentbox. Now, there are a multitude of other things that we can do with the Raspberry Pi, and a lot of them are controllable using a web-based interface. This gives us ease of control using a lot of devices, but still limits us to the confines of our local network. This post will attempt to address that.
Why I Did It
I don’t have a static IP assigned to my home internet connection. This means that each time something forces my modem to disconnect and then reconnect, I will have a different public IP address. Not good if I want to set up remote access for, let’s say, my Deluge web interface, because I’d have to first figure out what my public IP address changes to, which means I’d have to go home and… well, you get the idea.
Hence, Dynamic DNS, or DDNS.
Port Forwarding
The first thing I need to do to make this work is to enable port forwarding. If you don’t know what it is, a simple Google search will get you all the info you need. For the sake of example, I’ll be forwarding port 22 to my Raspberry Pi’s port 22 so that I can access its ssh from outside my network.
Next, I need to set up the Dynamic DNS service. What it does is basically enable me to route all requests to a particular URL so that it reaches the IP address of my choice. There are two ways to go about doing this.
Free Dynamic DNS Service
A popular free Dynamic DNS service, DynDNS, apparently has stopped its free service. One of the free alternatives that many people start to use is NoIP. After signing up for free, I get to choose my subdomain.
Why a subdomain? Because it’s free.
After I have my subdomain setup, I can go ahead and download the DUC Client for Linux. There are plenty of instructions on the internet on how to set this up on a Raspbian Wheezy. After I got it up and running on boot on my Pi, I can sit back, relax, and have my Pi update its public IP address to the NoIP service. I can then access my Pi’s secure shell from anywhere by instructing PuTTY to connect to [mysubdomain].[my-no-ip-domain] at port 22.
There’s a catch, though. I’d have to reactivate the free subdomain every 30 days. Well, they gotta do something to get me to buy their paid services, right?
But wait… there’s another way.
Free Dynamic DNS Service With My Own Domain
One of the perks of having my own domain and hosting at IdWebHost is that I can have as many subdomains as I’d like, and it’s dirt cheap. Check their pricing tables for more info, and I also have to say kudos to their customer support team that runs 24/7.
Before I do anything else, I setup a subdomain and confirm that it is indeed accessible. I also check my A records using the Zone DNS Editor. This could be different for each hosting company, so I won’t go into its details here; it’s best to ask their customer support directly.
The Dynamic DNS service of my choice is CloudFlare. I’ve heard a lot about them, and most are positive reviews. Most important, though, is that they offer a free service package. I then enter add my domain and let CloudFlare scan my DNS records.
After the usual sign-up – confirm email – activate 2-factor authentication routine, I proceeded with setting up my domain. I let CloudFlare scan my DNS records, and make sure that the new subdomain I added earlier is detected. If not, I just manually add a new A record, copying settings from my domain’s A record.
Next, I go and read an article about how to set up a custom script both on my hosted web and on my Pi to automatically check for public IP changes every 5 minutes. Just for fun, I changed the PHP script a bit so that it sends me an email every time it detects that my public IP address has changed.
Finally, I have to actually make the internet use CloudFlare’s DNS to make this all work. So I go to my IdWebHost management page, and set my nameservers to point to CloudFlare’s nameservers instead of IdWebHost’s. People usually say that DNS update propagation is slow as a slug and it takes up to 24 hours at a time to make the updates propagate. Not the case with CloudFlare. I just need to issue a “ipconfig /flushdns” on my Windows command prompt a few times to force an update.
A word of caution for this setup: because of the way some web hosting companies setup their CPanel sites as [domain]:[port], in other words it doesn’t use a subdomain for CPanel, you may need to tinker a little bit with your DNS settings so that CPanel doesn’t run through CloudFlare’s CDN. I chose to completely bypass CloudFlare’s CDN, except for this blog, because really the only thing I’m using from them is the Dynamic DNS service. Your mileage will vary.
Aftermath
Now, I have access to my home network that I can configure simply by configuring port forwarding on my router, and I don’t have to worry about my public IP address changing after a blackout (which unfortunately is a common thing on this side of the world).
As a matter of fact, my house just experienced a blackout today at about 9 a.m., at which time everybody was out working. At about 3.15 p.m., I was able to access my torrentbox from my cellphone. A query on my Pi’s uptime showed 12 minutes, which means that within 12 minutes of my Pi starting up, my new public IP was successfully propagated. Awesome!
This article is a follow-up of my earlier post about how to run a Raspberry Pi box as an always-on NAS box. I figured that since I only have a theoretical maximum of 4 concurrent clients in the house, and none of them are intensive users, I might as well squeeze out some more juice out of the Pi to run as an always-on torrentbox. Internet speeds in Indonesia are notoriously slow, and even downloading the Raspbian Wheezy image takes quite a while. Scheduling the download for off-peak hours (middle of the night, or mid-day when nobody is in the house) seems to be reasonable. I could even schedule the machine to be a seeder during those hours, and for once give back to the torrent community. (confession: I’m usually a leecher and stop seeding once my download is completed)
Choice of Clients
I like the idea of thin client access, which minimizes resource usage on the Pi itself. That’s why I chose Deluge. I did try using Transmission, and the fact that I need to run the Transmission desktop client on X so that I can access its web UI appalled me. So there you go, Deluge FTW!
Thin Client Installation
To install Deluge Thin Client, I did this as the pi user:
I log in as mysambauser to do everything, so that the thin client will run as mysambauser. Why? Because I think running it as a user who already has access to the USB HDD mounts makes a lot more sense than adding pi to the sambausers user group. If I wanted to be more careful, I’d create an entirely new user, let’s say deluge-user, put it in the sambausers group, and work from there. But I’m too lazy for that. Ha!
Alright, let’s login as mysambauser:
su mysambauser
Now let’s run deluged so that it generates a config file and then kill it afterwards:
deluged
pkill deluged
Alright, that should do it. Now, let’s create a backup of the config file:
Go the end of the file and add the user/password/access level of your liking. I went like this:
mysambauser:mysambauserpassword:10
Not the best, I know, but for the sake of example it’ll do. Now, go into the console:
deluged
deluge-console
Once inside, I went:
config -s allow_remote True
After that, I went like this to check that the setting is indeed changed:
config allow_remote
After I was sure remote is allowed, I exit the deluge console by, surely enough, typing exit. Then, I restart deluge daemon:
pkill deluged
deluged
Setting up remote access.
Right. All done for the Pi for now. Time to install Deluge client on my PC. Downloads are available at the Deluge website. After installing it, I fire it up and go to preferences:
Preferences menu.
I then disable classic mode by unchecking that first checkbox:
Disable classic mode.
I then have to restart Deluge client to load the classic interface, and be presented with the connection manager.
Connection manager.
Next, I enter mysambauser’s credentials (leaving the port alone for now), and click connect.
Host credentials.
Alright, so now I can control my Pi’s torrents from the comfort of my PC without having to keep my PC on to do the actual download. Cool bananas!
Web Interface Setup
Now, I’d like to have web access to my Deluge thin client. First, I log out of mysambauser’s shell to get back to pi’s shell by pressing Ctrl-D, then:
Then I run deluge-web and kill it, to make it create a configuration file that I can edit:
deluge-web -f
pkill deluge-web
The -f flag up there tells deluge-web to fork the current interface. If you don’t do it, the console will just sit there and wait and you’d have to exit by hitting Ctrl-C. Not pretty. Deluge should’ve given some warning about this. Anyway, I go and edit the configuration file:
sudo pico ~/.config/deluge/web.conf
I just change the port. I don’t like using the default port. Alright then, now I start deluge-web again:
deluge-web -f
Next, I browse from my PC to [Pi’s-IP-address-here]:[deluge-web’s-port]. I log in using the default password “deluge” and chose to change it immediately. Done.
Download Locations
I’d want my downloads to go to my external hard drive, lest my SD card become crowded and eventually run out of space. I do this by going to Preferences, Downloads, and set up my directories there. This is the reason why I use the mysambauser user instead of the default pi user, because pi doesn’t have access to my external hard drive.
I create four directories under /media/USBHDD1/Torrents: Backup, Completed, Incomplete, and Watch. Next, I add a samba share location to the Torrents directory. This way I can just drop torrents into the Watch folder or copy completed torrents from my Completed folder. Easy.
To test, simply copy a torrent file into the Watch directory. It’ll immediately disappear and be whisked to the Backup directory, and if you’re watching your desktop client or web UI, the torrents will show up and immediately start downloading. Delightful!
Setting Up Deluge to Start On Boot
To have the Pi start Deluge on boot, I’m going to skip the scripts and just use the download link the guys at HowToGeek.com provided:
After rebooting, if you can’t find the web UI, there’s something wrong either with the permissions, the hard drive mounting, or the init script itself. I won’t get into it as I experienced no problems at this point.
So, there you have it, I now have a Pi box capable of leeching (and seeding torrents) automatically just by dropping a torrent file into the Watch folder, and can be controlled either with a desktop client or web UI. As before, any comments or suggestions are welcome. Cheers!
I finally bought myself a Raspberry Pi Rev B from Element 14. I got it from an importer in Bandung, and I decided I’d go for a little shopping myself to the computer store to get me the tidbits. So here’s my kit.
Ralink RT5730 USB WiFi dongle with rotatable antenna (not shown)
The Pi, made in the U.K.
The plan is to get it to work with my existing Western Digital MyBook 2TB external hard drive. I found so many tutorials on the interwebs about how to do this, but I guess I’ll just share my experience.
Hardware Assembly
The hardware assembly is pretty straightforward. The acrylic case snaps together without any problems, and voilà, my Pi’s got a casing.
Pi In A Box
Operating System
Next, I need to flash the SD card. It’s already got NOOBS on it, but I won’t be using it because I want to use the latest Raspbian Wheezy. I downloaded it from the Raspberry Pi website and flashed my SD card using Win32 Disk Imager. No problems here.
First Boot
OK, so here’s the first problem. I have two 22″ monitors connected to my PC, and nothing else. So I had to hijack the TV in the living room to do the first boot. Luckily I have a wireless mouse/keyboard combo handy, so less cables and it plugs into just one USB port on the Pi.
My Raspberry Pi Rev B, with 8GB SD Card, connected via RCA to my TV, controlled using a wireless keyboard. Yes, that’s a clay cat.I had to do this to install the Pi and enable SSH. Yes, I have three clay cats. Meow.
Default username is “pi” and password is “raspberry”. Upon first login, the Pi will automatically enter the raspi-config utility. Here’s my checklist on first boot (and second boot, for that matter):
Expand the filesystem. This needs a reboot. Do this to enter raspi-config:
sudo raspi-config
Enable SSH. To do this go to Advanced, SSH, then Enable SSH.
Exit raspi-config, and run the following command
ifconfig
Take note of the hardware address shown, because it’ll come in handy later on when I reserve an IP address for the Pi.
The Pi is now capable of running headless, so I shut it down.
sudo halt
Then I moved it to a better position, and connected it via UTP to my router. I also plugged in my external hard drive. I’ll be continuing on the setup remotely from the comfort of my PC. Before powering it up again, I decided to go ahead and reserve an IP address for the Pi, using the web-based router management UI. I won’t go into this because every router is different, but the point is to “map” the MAC address of the Pi’s network interface card to an IP address typically assigned by the router’s DHCP server. Alright, now power up!
System Update
The first thing I did after getting the Pi accessible by SSH (I use PuTTY for this) is to do a complete system update.
sudo apt-get update
sudo apt-get dist-upgrade
The upgrade process required that I download 460MB worth of debian packages. After the update completed, I decided to create a backup of the image, using Win32 DiskImager that I also use to write the system image on the SD card. This way, when I want to do a fresh install, I have the Pi updated to a more recent version and ready to run headless.
After saving the updated image, I decided to run raspi-config again to change my hostname. This is probably a good idea because if I buy another Raspberry Pi and run it using the image I just created, the two of them won’t have the same hostname.
Formatting The Hard Drive
I use a 2TB external hard drive connected via USB. I chose to format it using EXT3 for reasons I’ll explain later. I just went along with instructions I found using Google Almighty. First, I go into fdisk:
sudo fdisk /dev/sda
I deleted the one and only partition existing on the hard drive, and created a new primary partition that spans the entire disk. This is probably the scenario if you’re using a new hard drive. If you are going this route, just make sure you don’t have any data worth keeping on the disk. You have been warned.
Command (m for help): p
Disk /dev/sda: 2000.4 GB, 2000365289472 bytes
58 heads, 60 sectors/track, 1122690 cylinders, total 3906963456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00064002
Device Boot Start End Blocks Id System
/dev/sda1 2048 3906963455 1953480704 83 Linux
Command (m for help): d
Selected partition 1
Command (m for help): p
Disk /dev/sda: 2000.4 GB, 2000365289472 bytes
58 heads, 60 sectors/track, 1122690 cylinders, total 3906963456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00064002
Device Boot Start End Blocks Id System
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-3906963455, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-3906963455, default 3906963455):
Using default value 3906963455
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Explanation of commands in the order they are issued:
p: list partitions
d: delete partition
p: list partitions, to check that the partition is indeed marked for delete
n: new partition, and then just accept default values for a single primary partition
w: write the changes to disk
I then check that the partition is indeed available.
sudo fdisk -l
That command spits out the following result:
Disk /dev/mmcblk0: 15.7 GB, 15720251392 bytes
4 heads, 16 sectors/track, 479744 cylinders, total 30703616 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b5098
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 30703615 15290368 83 Linux
Disk /dev/sda: 2000.4 GB, 2000365289472 bytes
38 heads, 36 sectors/track, 2855967 cylinders, total 3906963456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00064002
Device Boot Start End Blocks Id System
/dev/sda1 2048 3906963455 1953480704 83 Linux
Alright, now that I have the disk recognized as /dev/sda1, I need to make the filesystem.
sudo mkfs /dev/sda1
It takes a while to make the filesystem, so grabbing a cup of joe at this point might be a good idea.
Mounting and Sharing
After mkfs, the drive is ready to use but not yet mounted. So I prepared a directory for the share mount point:
sudo mkdir /media/USBHDD1
I decided to just add an entry into fstab and reboot the Pi so that I know for sure it works.
sudo pico /etc/fstab
In the editor, I added the following entry:
/dev/sda1 /media/USBHDD1 ext3 noatime 0 0
Next, I reboot the machine.
sudo reboot
After logging in, I tried running df to see if the hard drive is properly mounted.
Now that I’m sure I have the drive mounted properly on boot, it’s time to install samba. I found some instructions for how to do it, but it uses NTFS-formatted hard drives and is different than my setup. The samba part is, however, pretty much the same.
sudo apt-get install samba samba-common-bin
Next, it’s always a good idea to store a backup of any config file before editing it.
First order of business: activate user-based security. So I find the following line:
####### Authentication #######
# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
# security = user
I uncommented the last line to activate user-based security by removing the hashtag:
# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
security = user
To add shared folders, I add the following section to the very end of the configuration file:
[Public$]
comment = Public Shared Folder
path = /media/USBHDD1/Public
valid users = @sambausers
read only = no
[Apps$]
comment = Applications Repository
path = /media/USBHDD1/Apps
valid users = @sambausers
read only = yes
write list = mysambauser
[MediaCenter$]
comment = Media Center Repository
path = /media/USBHDD1/MediaCenter
valid users = @sambausers
read only = yes
write list = mysambauser
[private$]
comment = mysambauser's private folder
path = /media/USBHDD1/Users/mysambauser
valid users = mysambauser
read only = no
I repeated the private folder for every user I plan to have in the network to provide them with personal space. This would probably not be necessary if I had a huge SD card because I could just activate their home folders with read-and-write access. Unfortunately, that is not the case.
Now, I could just go ahead and create users who will have access to the samba shares, but I like to put them in a group together so I can easily assign privileges as a group. Thus the new user group sambausers:
sudo addgroup sambausers
Next, the users that will be in the group:
sudo adduser mysambauser -m -G sambausers
The -m flag creates a home directory for the user (in case we need it later), and the -G flag adds the new user to the sambausers group. I do this for every samba user I have. After that’s done, I set UNIX passwords and samba passwords for them (also repeat for all intended users):
sudo passwd mysambauser
sudo smbpasswd -a mysambauser
Now, I need to change ownership of the mount point, set its permissions, and create the correct directory structure inside it to match the samba configuration file.
I won’t go into the details of creating the directories, but I will point out that this will need to be done as the mysambauser user. All done! Now I can log out as mysambauser (and return to pi user) and start the samba service.
sudo /etc/init.d/samba start
Now I can browse to \\HOSTNAME from any Windows machine and map a network drive to the shares I just set up.
NOTE: If you use a firewall of some sort, please make sure your firewall allows access to ports 137, 138, 139, and 445 using TCP, and also port 137 using UDP. These ports are in use either by Samba itself or Windows hostname resolution (NetBIOS).
Performance and Conclusion
This article actually documents the second build. That’s why you may have noticed that the SD card in use is 16GB instead of 8GB. Also, I chose to use a wired connection to my router, I’m saving the Ralink for a second unit later on.
Performance is a lot better on this build. Here are the figures:
Test
Wireless Connection
Wired Connection
FAT32
EXT3
FAT32
EXT3
Copy 3GB file from desktop to Pi
400 ~ 600 kB/s
600 kB/s ~ 1 MB/s
600 kB/s ~ 1.5 MB/s
700 kB/s ~ 3 MB/s
Copy several files (2 ~ 10 MB each) from desktop to Pi
450 ~ 800 kB/s
700 kB/s ~ 1.2 MB/s
700 kB/s ~ 1.8 MB/s
700 kB/s ~ 4 MB/s
The figures are approximations only and should be taken with a grain of salt. I am by no means an experienced tester, and these are just some real-world results that I’ve got from my week-long use of the Pi unit. Further testing should include simultaneous read/write operations serving anywhere from 2-10 clients concurrently, but I’ll leave that to Anand or Linus or whoever else wants to do the testing.
Any comments or suggestions are welcome. Until next time. Cheers!
