⇚ Go Back

Systems Administration

Too long, didn't read version of this page:

I have strong experience with system administration from both a desktop and a server perspective. While I do not have as much experience with Windows servers (partially out of distaste for the closed source nature of Windows Server), I do have much more experience with Linux servers. More specifically, I have experience managing web servers, FTP servers, email servers, DNS servers, and media servers. This includes software such as Apache, NGINX, Very Secure FTP Daemon (vsftpd), Dovecot, Postfix, SpamAssassin, BIND 9, Plex, and many others. Largely this has been done for personal purposes, but I feel that I am experienced enough with them in order to apply these skills to a professional environment. As well, I have experience running Ubuntu Server, CentOS servers, openSUSE servers, and Debian servers, as well as FreeBSD and OpenBSD servers, and Docker for a more distribution agnostic solution.

My main experience comes in the form of a virtual server farm that I ran partially as a toy setup to learn more about how multiple servers can work together to form the basis of a modern website. This was done partially as an excuse to learn more about networking (which hitherto doing this was one of my weaker points as far as computing goes), but as well out of disappointment with the sad state of my Networking class that I took for my degree. In the week that it took me to get the virtual server farm set up I learned more about networking than I did in the entire semester of that course. I'm a practical sorta learner anyways, but this was a whole other thing entirely. I honestly believe that many of these skills simply cannot be learned from a textbook or a certification course. They have to be learned practically, which I certainly did. Syntax can be learned and forgotten; the logic to know where to look whenever something goes wrong has to be earned.

My first virtual server farm consisted of openSUSE as the DNS server, Debian as the web server, and CentOS as the mail and FTP server. There wasn't any particular motivation behind which distribution I used for which server; it was simply an excuse to use multiple "main branch" distributions. I will say, if I had to stick with just one, I preferred openSUSE most of all due to how easy it made it to work on the server. YaST is certainly a killer app for the distribution. Debian is certainly well known and stable, but I don't like how it customizes packages for itself. CentOS was fine to use, but I'm not as much of a fan of how 'Red Hat-y' it is. There's a lot of particularities to the way it handles its firewall, which I prefer more universal solutions such as nftables and iptables (ufw is a frontend for these, and I find myself using it more often because it's less cumbersome).

Getting the DNS server set up was simultaneously the easiest and the hardest portion of the farm. While in the real world it is much easier to just let the registrar take care of it, especially for small sites such as mine, it is still useful to know how to set up an internal DNS. My virtual server farm was done in VirtualBox, so getting the virutal machines to talk to each other wasn't hard at all. I did add an Arch client as well to the network to keep it all internally, but if I were to run something in a production environment, I'd just use something like Docker instead. Nevertheless, I installed all of the machines and set their IPs to static. openSUSE and CentOS were pretty easy to configure, but as I learned, Debian's ConnMan - as the name implies - is a horrendous liar and should not be trusted with anything. Once I got that out of the way, I was able to get the records entered into BIND in the openSUSE server, and I was able to ping all the servers from the Arch client. Most of the difficulty really came from ConnMan on this one. Otherwise, opening the ports needed by the DNS server was very easy with YaST.

The web server was fairly easy overall, thanks to the aforementioned package modifications that Debian does. I use Apache mainly because my websites are more statically oriented, but I am comfortable enough with NGINX to run a site with it. Getting this server working was as simple as installing apache2 and opening ports 443 and 80. Beyond that, I made sure to use CertBot to sign a certificate so that my website could operate with HTTPS. At that time I wasn't as familiar with writing a website as I am now, so for the purposes of the server farm, I kept it purely with the default page.

Setting up a mail server is a notoriously difficult process, but I made sure to follow a guide. The mail server on CentOS consisted of Dovecot, Postfix, SpamAssassin, SquirrelMail, and OpenDKIM. I don't have much in the way to talk about as far as complications go, as I was just following directions, but it was very nice to have a server at the end of the day that could send and receive email from Gmail. CentOS' firewall was a bit of a pain to work with, however. I'm not much of a fan of firewalld.

Finally, it was time to put everything together, and this is where a lot of troubleshooting happened. Largely the struggle as mentioned before was with getting Debian to stay as a static IP, but I also had complications with firewalld not opening the right ports that it said it had opened. Meanwhile, openSUSE was about the only one to work without any major headaches. Once I got the right records entered into BIND, I was finally able to access everything internally. Eventually I found myself somewhat strapped for hard drive space, and I had to delete that server farm, hence no screenshots for it. However, I eventually used those skills once again to launch the website you're reading right now. I've done much the same, except for the DNS server portion.

Another fun project in system administration that I undertook was using NextCloud and OnlyOffice as a replacement for Google Drive. I definitely prefer hosting my own stuff myself, and having the ability to access my own cloud storage whenever I want to is definitely worth while. However, for the magnitude of data I wanted to store, I couldn't find a host that would've been more cost-effective than just running my own solution. As well, since I don't trust the electrical wiring in my house to run multiple computers in the room with the router, and I don't feel like running more CAT6 cabling in my house, I kept it in the virtual server farm once again. Still though, it was a fun experience getting it to work as is. Unfortunately, once again as it was a year ago that I got that set up, I deleted these virtual machines along with the first farm. I can still detail my experience though.

For this project in particular I decided to work with Ubuntu Server. Partially this was because I wanted some more experience with different server distributions, but also because it was nearing a finals week at that time, so I didn't want to mess around that much with intensive configuration. It turns out that Ubuntu Server has a default configuration available for running NextCloud, so I used it, and it worked pretty much out of the box. Rather than having OnlyOffice be in its own server, I ran it in a Docker container, and it worked fairly easily. Most of the work to integrate the two was done; I just had to tell NextCloud where to look for the OnlyOffice server, and it pretty much figured it out for itself. For a purely in-house cloud storage and office suite, this combination is certainly a viable one.

The last of my experimentation with a server farm was to do a BSD only server farm. I chose FreeBSD for this project because I didn't feel like working around a ton of idiosyncracies that OpenBSD may have. However, I will say that if I wanted a server with a very high degree of security, I would definitely go with OpenBSD due to just how rigorously they've pored over their code again and again. Once again I just used Docker, and it was once again incredibly easy to set up. It is worth saying that there is a certain degree of concern to be had by localizing everything onto one machine running containers (more open ports means more attack space), but for the purposes of experimentation and learning, I wasn't too concerned.

Now as far as running this site, I'm running an instance on Vultr and am using Epik to host my domain name. This is largely because of a series of videos I saw regarding web hosting, and they seemed to be the most worthwhile. I'm not hosting a particularly large website bandwidth wise (the site in total is only about 20MB in total), so I can get away with just $3.50 a month for web hosting. The .xyz domain is again a result of me just wanting something cheap and functional. Using the experience I had with my own virtual server farm I set up a web server and a mail server. I did discover that blacklists such as Spamhaus are rather jumpy when it comes to new mail domains so I ended up having to contact them about it. There wasn't anything that was compromised on my server, but the sheer fact that script kiddies were trying to access it meant that Spamhaus thought it was a spam site and decided to add my domain to it. Eventually I was able to get my site off of the list, but I haven't re-enabled the mail server, as I quite frankly don't want to potentially have my domain suspended on suspicion of spam. Lesson learned though: for internal purposes, dovecot/postfix mail is perfectly fine, but when it's facing outward, things can get a bit dicey. Oh well, my personal Gmail still works just fine; it's just a shame that script kiddies are working so hard to try to compromise everyone's email servers. Nonetheless, the web server has been working without a single concern, and I have no complaints whatsoever on that. It's easier than ever to set up your own site, so go ahead and do it! Of course, if you need help, just contact me (It's what I wouldn't mind doing for a living after all!).