My Summer Spring Cleaning, Part 1

Over the past few weeks I’ve been upgrading large parts of my personal server infrastructure, including new hardware in my home and different hosts in the butt cloud^TM.
Since I spent half the time of the setup reading through blogposts/tutorials/documentation to get everything going, I thought it’d be a nice idea to summarize the stuff I set up in one blogpost, also giving me the excuse to brag about the stuff I did, to my surprise, without any lasting damages.

My Personal VPS

My personal VPS was probably the oldest part of my infratsructure. I rented it a few years ago, initially just for shits and giggles, then to run the wurstmineberg Minecraft server, then to run the wurstmineberg creative server¹, and in the meantime I was using it to host websites, the occasional ZNC, twitter bots, Wordpress sites, R scripts that produced things like this², and of course a shiny server for my trakt.tv webapp.

I probably forgot a few things here and there, but that probably just shows that this was my one-for-all hosting box.
And it also sucked big time. It was a Ubuntu 12.04 LTS machine, a single 32bit CPU core, 1GB of RAM which sometimes could be bumped up to 2GB³. All in all not ideal for pretty much anything that happened after 2012. I vaguely remember that I had to build the shiny server from source because there is no 32bit package, which was not a fun thing to do, but alas, I went with it.
The machine also cost be 8€ per month⁴. Nowadays, there are much better options for cheaper prices.

I was expecting to move this server to DigitalOcean because they seem to be popular and I’ve been using that for the Tadaa, Data server (see below), but then @bl1nk recommended scaleway to me, and boy did these prices look good.

Welp, now I’m running a Ubuntu 16.04 LTS VPS with 4 64bit (finally) cores and 4GB of RAM. This has the added bonus that I could use more recent tutorials for stuff, because boy am I thankful for DigitalOcean’s extensive community documentation and tutorials⁵.

So here’s the gist:

NGINX, MYSQL, PHP, SSL

I was very happy to see that most of the basics are apparently covered in the LEMP stack, whatever LEMP stands for, but oh well, I’m only a part-time nerd so I don’t have to know everything. Or anything at all. Anyway, here’s the DO tutorial for the basics you need for stuff like wordpress. I prefer nginx over apache for the very intellectually stimulating reason of being used to it and people I trust recommending it.
When it comes to SSL, I’m proud to say that every webpage I’m kinda responsible for has SSL certificates thanks to the wonderful LetsEncrypt project, and of course there’s a tutorial for that. Getting this set up was much easier than I remember from a few months back where I had to clone a GitHUb repo and build stuff from source. Having an installable package makes things much more pleasant.

When it comes to mysql for my wordpress sites, I realized I could make my life tremendously less difficult by just writing down the required commands I need for datapase creation and basic user management. Now I don’t have to google that every time. It’s almost like knowing stuff. For the record, it looks like this:

1
2
3
4

CREATE DATABASE project;
CREATE USER projectuser@localhost IDENTIFIED BY 'thanks1passwordforexisting';
GRANT ALL PRIVILEGES ON project.* TO projectuser@localhost;
FLUSH PRIVILEGES;

You either already knew that or you know where to find it, but I felt like I should point this out here.

While we’re talking about wordpress prerequisites, there’s also the issue of PHP. The only things I know about PHP is that most people in my technology-interested social circle either make fun of it or just plain hate it for various reasons I have no opinion of on my own because I only vaguely understand Shell and only comfortably understand R, sooooo… whatever.
The thing I wanted to mention is the migration from my old wordpress installs to the new host: My new VPS runs php7 instead of php5 on the old one, so when setting up your nginx config for the new host, you need to include something like this:

1
2
3
4

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

It took me about 5 minutes to figure out I had to change the fastcgi_pass path because both the version number and the actualy directory where the sock lives are different now.

Anyway, once I figured that out both my wordpress sites and my h5ai directories where working fine and I could move on.

R stuff! Shiny Server! Magic!

Now that I have hardware supported by shiny server, setting things up is basically trivial. If you’re curious about RStudio Server, you’ll be happy to know that setting that up is basically the same process, so if you’ve already set up an R installation, adding the RStudio Server is pretty much 2 lines of Shell.

The thing about an R installation is that you usually have multiple libraries⁶, and if your setup is similar to mine (R used by my own user and the shiny server), you may want to centralize you’re installed R packages if you don’t have any particular reason for allowing specific users specific packages.
In my case, I added the following line to /etc/R/Renviron:

1

R_LIBS_USER=${R_LIBS_USER-'/opt/R'}

I’m still not entirely sure I understand R’s startup process, but as far as I can tell my approach didn’t cause any explosions yet. What I did there was just telling R to install packages in /opt/R, a path I made accessible for all the users that need it, so every user can install packages and I don’t have to run installations via sudo every time I add a new dependency to a shiny app or a script I run on the server.
Another thing you’ll want to set is in you /etc/R/Rprofile.site:

1

options(repos = c(CRAN = "https://cloud.r-project.org"))

This will set your CRAN mirror so you don’t have to manually select one from a menu every time you install a package. The CRAN mirror above will probably work for most locations and uses HTTPS, so if for whatever reason you’re having trouble with HTTPS mirrors, just use the above URL with https:// and you’re good to go. Intrinsically wrong because of the lack of SSL, but good to go.

Is it still called deployment if I just sync stuff?

Now that I have the infrastructure set up for filedumps, it’s time to think about how I want to deploy these things. I could do some fancy stuff via git and autodeployment via webhooks I don’t understand, I could also set up deployments via rsync and scripts and stuff, or I could just go the easy way and continuously sync local folders to remote folders via syncthing.

In the past, I tried the rsync approach with octopress, I tried the git thing with… Okay, I didn’t really try it, but wurstmineberg people set stuff up and it kinda worked? Anyway, I’m a big fan of the whole “just two folders syncing” approach, and I’ve been a satisfied pro user of BitTorrent Sync Resilio Sync in the past, but I ran into a few small issues and inconveniences here and there, so I decided it was time to check out Syncthing.
Syncthing has the advantage of being open-source, so I can check out GitHub for issues and feature requests, it’s a little more flexible because it doesn’t require to me handle identities, and it doesn’t assume I have a bunch of folders I wanna share with strangers, but rather let’s me add a bunch of devices I want to connect to eachother.

So now I have backups to my local NAS from my laptop, various websites and filedumps from my laptop to my NAS to my VPS, and a bunch of other stuff all running smoothly. It’s also very configurable, which is a nice change, and it has this nifty data page which you can choose to contribute to by opting in to anonymous data collection. It also works fine on android, providing a fast and reliable way of quickly accessing my phone’s photos from my laptop without Dropbox Camera Upload hogging my Dropbox space.
If I remember correctly, Syncthing is fairly young compared to services like Bittorrent Sync Resilio Sync or even Dropbox, but it’s already pretty damn good, so I have high hopes for this one. Please don’t crash and burn Syncthing. Please don’t.

Conclusion

I’ve had this document open for over a week now and it turn’s out I don’t have the time to finish the rest of it these days, so yeah, first multip-part blogpost, wheee.