Expand and Extend
With the foundations now laid, our server project can be tailored to just about any purpose you require
WE’VE DONE MOST of the groundwork required for any server, but we haven’t really considered security, and it’s worth saying a few words about this. Having only SSH visible to the outside world is a good start, especially if only key-based access is possible. If the key is stolen, though, or the password is guessed (if you were lazy and allowed password access), your whole machine is vulnerable, because that user has sudo rights. Some people only allow non-sudo users to log in, but this then precludes being able to do grown-up tasks. Trade-offs between security and convenience are commonplace. Having our services only visible to the LAN relies on the fact that our network hasn’t been compromised. Certainly, as long as our home network is IPv4-based, our server is shielded from direct outside access. But what if our router or another machine on our network is infected, punching a hole through that convenience?
Putting behind us the gloomy and thorny issue of security, let’s consider what to do next. Ultimately, you’re only limited by your imagination. For a start, if you have a spare pair of speakers (or if your server’s in the living room, hook it up to your amp), look into setting up mpd. It’s a lightweight Music Player Daemon that can be controlled via a web interface, client programs, or apps on mobile devices. Some client programs enable you to connect your listening with social services, such as Spotify and Last.fm; some (such as the glorious ncmpcpp) can be run entirely from the command line. If you really want, you could then connect your server to your television, but to make the most of this arrangement would require installing a GUI on the server. And that wasn’t a road that we wanted to venture down for this guide.
When connecting to the Internet from public Wi-Fi, it’s wise to use a VPN to protect your traffic. There are commercial offerings here, but why not set up your own OpenVPN server? Again, tunneling it via SSH might be the best option, or at least changing the default port. It’s easy enough to set up, but you need to understand a little bit about how certificates, TLS, and things work. Armed with that knowledge, you can secure all traffic between the questionable hotspot and your server, and if you trust your ISP (or at least are browsing via HTTPS), you have a lot less to worry about. In the interests of energy conservation, it’s a good idea to put your server to sleep overnight if no one’s going to need it. This requires recent hardware, but no additional software— the machine commences Zs as soon as you tell it
$ sudo systemctl suspend . Apropos to this, one can also configure Wake on Lan (WoL) so it can be woken up again from anywhere on the network. The ethtool program needs to be installed on the server, and the wol package on any machine from which you want to rouse it.
Finally, we should discuss some options to minimize the damage in case your server is struck by lightning or overzealous use of the rm command. It would probably take less than half an hour to reinstall the system— it would be quicker if we had copies of the relevant configuration files to hand. Small files like this are ideal for backing up to the cloud (so long as they don’t contain passwords or other sensitive material). WE NEED TO TALK ABOUT BACKUP This can be automated for services such as Dropbox, but it also isn’t too much of a chore to periodically do this manually. In this guide, we could back up our Samba, fstab, and APT sources lists. One method by which h the backup could be done is by rsync-ing to another servererver via a maintained list of files to back up. Rsync is a hardcore protocol that can do deduplication, so it’ss good for transferring large files efficiently, provided you u have somewhere suitable to transfer them to.
Sending large files to the cloud rapidly becomess timeconsuming and logistically problematic. There is free storage available, but whether you can find enough ough of it, and whether it can be accessed without some e nasty proprietary app, is a different story. If you have a fast network connection and unlimited funds, a remote e rsync machine is the best option. Good practice dictates es that off-site backups are good, but cloud storage is expensive, ensive, and people aren’t very good at deleting things no longer required. The next best thing would be to back up the important files on your RAID to an external hard drive (or perhaps a NAS), and store this off-site.
We should discuss options to minimize the damage in case your server is struck by lightning or overzealous use of the “rm” command.