Expand and extend
With the foundations laid, our server project can be tailored to just about any purpose.
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 (if you were lazy and allowed password access) the password guessed then your whole machine is vulnerable since 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 us consider what to do next. Ultimately you’re only limited by your imagination here. 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 will allow 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 wanted, 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 feature.
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’ll need to understand a little bit about how certificates and 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) then 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 will commence Zs as soon as you tell it $ sudo systemctl suspend . Apropos to this, one can also configure Wake on Lan (WoL) so that it can be woken up again from anywhere on the network. The ethtool program will need 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 minimise 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 like Dropbox, but also it isn’t too much of a chore to periodically do this manually. In this tutorial we could back up our Samba, fstab, and APT sources lists. One method by which the backup could be done is by rsync’ing to another server via a maintained list of files to backup. Rsync is a hardcore protocol that can do deduplication so it’s good for transferring large files efficiently, provided you have somewhere suitable to transfer them to.
Sending large files to the cloud rapidly becomes time consuming and logistically problematic. There is free storage available, but whether you can find enough of it and whether it can be accessed without some nasty proprietary app is a different story. If you have a fast network connection and unlimited funds, then a remote rsync machine is the best option. Good practice dictates that off-site backups are good. But cloud storage is expensive, 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.
“For a start, if you have a spare pair of speakers look into setting up mpd.”