A stock image of a server room, since I don’t know what the server room my VPS is hosted in looks like. Image by Elias from Pixabay
The Upgrade Treadmill
I seem to have gotten into the habit of upgrading my server and website configurations every other year. My last server migration blog post was in 2018 and saw me upgrade from Ubuntu 16.04 to Ubuntu 18.04, with updated versions of PHP and a better database and things like that. I didn’t do a post about my 2020 server upgrade, but that was a big one. I switched to a mostly Docker based setup, with Nginx just reverse-proxying all the containers.
My 2020 setup had some enormous flaws though. I had no backup plan – as in, I wasn’t doing any automated backups. As you might expect, I wasn’t doing regular manual backups either. I wasn’t good on backups before the Docker-based setup either, but now it was so much easier to update the software I was running, but that would also have made it easier for a botched update to take everything down. I did make one thing a little easier: I moved a couple of WordPress sites onto a single WordPress multi-site installation. While it is certainly more complex to have a multi-site installation, it also meant I only needed to go to one spot to update themes and plugins which made it a lot easier to remember to do!
My goal with my 2022 upgrade was to make my setup much more robust. I wanted automatic backups, and I wanted to have the entire setup running within Docker so that if I wanted to move to a different provider, I could just spin up a new VPS, install Docker, restore the backups, and update the DNS for my domains. No manually setting up Nginx configurations, or anything like that. Importantly, with the automated backups I would be able to restore my setup with less than 24 hours of data loss if I had to move providers through no fault of my own.
For my most recent server migration I moved to Hetzner and their new US-based AMD-powered servers. The good part is that I’ve now got 4GB of RAM instead of my old 2GB, and it’s a little less per month. The bad part is that, as a Europe-based provider, they bill in Euros. While the credit card I use has no foreign transaction fee, the currency conversion means that my bill is never quite the same from month to month. They also only had servers in Virginia at the time I signed up, so I have higher latency than I had before when I was using a Vultr server in Seattle, though they’ve added an Oregon datacenter since then. (Maybe it’s time to do another server migration!)
The Software I Use
Now let’s get into the software I use:
For an RSS reader, I replaced Tiny Tiny RSS with FreshRSS. While it seems things have improved in recent years, the primary developer of TT-RSS was known for being a little hostile towards people asking questions or suggesting improvements. FreshRSS just seemed to have a better community, and it’s a lot simpler to set up too. I pair this with a private RSS-Bridge instance to get RSS feeds for sites that don’t bother to use RSS anymore (boo).
I’m using Offen Docker Volume Backup to automatically backup all my Docker volumes daily, weekly, and monthly both locally on the server and to S3-compatible storage. This container also manages removing the old backups to keep the storage from getting out of hand. It feels good to finally have everything backed up in a robust manner.
For website analytics, I replaced Matomo with Plausible Analytics. Matomo is trying to be a full replacement for Google Analytics, but that’s just more information than I need or even really want. Plausible focuses mostly on page views, which is all I really care about with my personal site.
Of course, WordPress, which powers this very blog, is still the same. In fact, it was one of the easiest things to move to the new server, as there were almost no changes to the configuration. I’ve been using WordPress consistently since early 2011, and off-and-on since probably 2006, so while I’ve considered moving to a static site generator, I like the familiar security blanket feeling that WordPress provides.
Vaultwarden also stayed the same. I use it as my password manager, though I’m eyeing Bitwarden’s new unified Docker container that’s in beta as it will likely go through security audits after it leaves beta.
I use a neat little tool called Your Spotify to keep track of my Spofify listening habits. It’s like having my own version of Spotify’s annual summary whenever I want it!
I added a single-user Mastodon instance at the end of October thanks to the Birdsite’s new owner starting shenanigans immediately – that’s been a bit of an ordeal with its ever-increasing disk usage, though just this week I migrated it to using S3-compatible storage for its media storage and that has solved things, though I won’t fully call it solved until I’ve given it a week or two. Follow me on Mastodon!
I use Portainer to view logs and clear out old images and stuff more easily.
I’m running Uptime Kuma on a separate VPS with a separate hosting company to monitor everything and let me know via Discord if anything stops working. It’s really a very polished tool and is easy to use while having tons of configuration options.
Finally, I use Watchtower in notification-only mode to let me know when a container has an update available. I don’t have it set to automatically update so that I have the chance to read the release notes and make sure there’s nothing I must do besides pulling the new image and restarting the containers.
Conclusion
Overall, I’m incredibly happy with how this server migration has turned out and I don’t foresee any major changes to my configuration in 2024 as things finally just work. I love how good this setup is in comparison to my old one!
I recently finished moving this website to a new server. I didn’t change the server provider or anything like that, but I wanted to take advantage of some new stuff. Here’s why I did it, and some of the difficulties I encountered.
Why did I do a server migration?
I wanted to upgrade to Ubuntu 18.04 to take advantage of newer PHP and nginx versions. I could have attempted to upgrade from 16.04 to 18.04 in place, but there were a lot of changes between those LTS versions, including how networking is handled. It seemed like the risk was just a little too high. I opted instead to build the system out on a new server, and then move all the website data to the new server. This had a few additional advantages as well:
I could switch from MySQL to MariaDB, a community developed version of MySQL that has gained support from several major tech companies. It also supposedly runs faster in some situations.
I could simplify my nginx configuration files. For each of my sites, my nginx configuration files are almost identical. Pretty much the only different parts are the server_name, paths to the ssl_certificate and ssl-certificate_key and the root for the website’s files. In building out a new server, I could move almost all of the configuration into snippets, making it easy to make changes to all of the sites at once. This will be useful in the future when some things change (like a newer PHP version).
I could entirely remove the andy-bell.com files. For a while I’ve been redirecting andy-bell.com to andy-bell.com, but I was doing so using a WordPress redirection plugin. Since andy-bell.com was literally just cloned from a backup of andy-bell.com, everything’s the same except new stuff. I took the opportunity to just nuke the old files and do the redirect from andy-bell.com to andy-bell.com solely in nginx. This also saved some time, since I wouldn’t need to move the files or database for andy-bell.com.
I use acme.sh for my SSL certificates. I was able to slightly improve things as I re-provisioned all the certs on the new server. (I just issued new certs on the new server so I wouldn’t have to move all the old ones over, plus now they will all renew on the same day, which will help me keep track of it better.)
Moving to the new server
It turned out to not be too difficult. Once I got the new server set up with nginx, PHP, and MariaDB, it wasn’t very hard to move all the old files over (I zipped them up on the old server, moved them straight from one server to the other, then unzipped them). Moving the databases wasn’t much harder. The only issue I had with the databases was one particularly large database that I had trouble with due to the file size. It was actually surprisingly smooth. To help ensure the move from one server to another moved quickly, as soon as I knew I wanted to move servers I changed the TTL (Time to Live) on my DNS settings to 5 minutes, so that it wouldn’t take too long for the DNS changes to propagate. Then 48 hours after I completed the move I turned the TTL back to the default setting!
I’m pretty pleased with the server performance, and I’m happy to be running on the latest Ubuntu LTS release. This should help keep things moving quickly and smoothly for years to come!
(Note: those Vultr links are affiliate links, because I really do like Vultr. If you use either of those links, and are active on Vultr for 30+ days with more than $10 in payments, then I’ll get a $10 credit, which is enough for 2 months of hosting for this site, not including tax.)
I’ve been a DreamHost customer for almost 3 years now. They’ve been around for a lot longer than that though: this is their 16th anniversary. I’ll get back to that in a couple of paragraphs, but I want to start with my own history with creating web pages. I think my family got its first dial-up internet connection around that same time. I’ve been interested in creating websites for just about as long as I’ve had an internet connection. We had a program called Print Shop Pro and as part of its suite there was a page to make websites. I shudder to imagine what the coding of those pages looked like. (Memo to self: break out that old hard drive and see if anything’s still there.) The sites were also pretty ugly: the templates definitely were part of the 90s, and that was a dark period for web design.
That led me to eventually learn how to code myself though. I downloaded a little tutorial program that guided you through the basics. Of course, most of that knowledge I gained doesn’t apply today. It tought me to make text bold by using the <b> tag. CSS wasn’t common back then. Even though I had learned to use basic HTML code, it still felt intimidating. I primarily used Netscape Composer (and its successors) to create web pages, even until around mid-2007 (the year I graduated high school). From there I moved onto WordPress, really getting serious about it in late-2010 (though I had messed around with it since about late-2006, even before WordPress.com launched!). These days, I’ve started getting more serious about learning to handwrite HTML and CSS. Last fall I took a class about HTML, CSS, and PHP. Now I tutor for that class and use it on a regular basis. In fact, my latest website project is a series of tutorial articles about HTML and CSS. It’s written using Jekell on Github Pages, so it’s mostly hand coded, with Markdown making things a little faster.
That leads me to web hosting. I remember our family getting junk mail back in the late 1990s urging us to get a domain name. Yes, we got snail mail to get real domains. While I don’t remember too well, it seems like those domains were very expensive. I don’t know if they included hosting or not, but the point is that getting online cost a lot of money back then. (I think part of why we got that mail is that we got film developed and printed through an online company, and even got the photos back in digital form! That made us progressive, I think, and probably made us more likely to want a website.) Whether it actually cost a lot of money or not, it felt like there was a much higher barrier to creating websites in the early days of the internet.
Since that time, we’ve seen a serious democratization on the internet. In the early days we had tools like Geocities. Personally, my first website accessible on the internet was created using Tripod.com (hey look at that, it’s still around), based on an article I saw in Boys’ Life magazine(edit: I found the article! I think my first site on Tripod was about Pokémon or something.). Of course, those tools were restrictive. I’ve never liked restrictions. As I got more serious, I started to look for free web hosts. I don’t remember the names of any of those, and I doubt they’re around anymore (at least in any recognizable form). I also had a little web server on my home computer with a free domain redirect pointed to the IP address during senior year of high school. I had a small WordPress installation there (and a little proxy script to get around blocks at school). I knew that wouldn’t cut it for critical uses though. In fact, in 2007 for an e-commerce competition for the Washington State FBLA I got a charitable person to give me some space on their SSL secured server for me to make my entry site because I needed it to be secure and stable. Now there’s great blog tools like Blogger and WordPress.com that are easy for just about anyone to use. Social media and easy blog tools (that can be adapted to make easy websites) make it so anyone can have a voice. (Side note: I hate it when people call Blogger “Blogspot.” Small pet peeve of mine. Thank goodness the BYU-Idaho Department of Communication is pushing WordPress on us. Of course, now people get confused about WordPress.com vs. WordPress.org. Exchange one problem for another I guess.)
After my LDS mission, I knew that I wouldn’t be able to do an on-my-computer web server if I wanted a website. So I set about looking for a domain name and web host. There’s a lot of choices, and I wish I had done more research (finding a web host is something that you should research out but I didn’t have much patience for that), but I knew I wanted one that would work with WordPress. I wanted to use that for a blog, and I was planning on using Joomla or Drupal for my main website (though I eventually switched everything over to WordPress). I figured a good place to start was with WordPress’s own site. Fortunately, they had a page with some recommended hosts! I ended up choosing DreamHost. For one, their web panel is very different from the others, but in a good way. I’m fairly tech savvy, but I was new to many hosting concepts, but DreamHost’s web panel lays things out very simply. It’s intuitive and provides all the tools you need easy access to. Their one-click installs have WordPress, Joomla, and Drupal: all the things I was wanting. And the price was competitive, while offering unlimited everything: great for someone who likes to tinker with stuff (I’ve tried out a lot of web software on various subdomains). One of the most reassuring factors though was their age. They were 13 years old when I signed up with them. That’s basically ancient in internet years. They’re still going strong today.
Have they been perfect? Of course not. There have been some spots of downtime, even some extended ones, but every host has that at some point. It’s technology: it will always fail at some point. I’ve been pretty happy with them overall. They make things easy for newbies, but they’ve got the power for experienced users as well. It would be nice if, one day, my site just grows so large I have to go find some crazy expensive hosting from some specialized provider, but for the foreseeable future, DreamHost has everything I need. There are tons of great hosting companies out there, but DreamHost is up there in the top tier, and I wouldn’t hesitate to recommend them.
Full disclosure: I am writing this post to enter a contest to get a free year of hosting from DreamHost. If you are a current DreamHost customer, you can enter to win too until midnight tonight. Keep an eye on that page though: there’s a different deal or giveaway every day, some for new customers, some for current customers, and some for anyone! The first link in this article is an affiliate link: I get some cash if you use that link. Thought you should know.
One of my jobs is tutoring for COMM 310 at BYU-Idaho. The course is called “Creating Online Media,” and in it we learn HTML, CSS, and a little PHP. PHP is one of the biggest stumbling blocks in the class. I had a couple tutoring appointments earlier today on the subject, and in preparation for those appointments I made this presentation. I’m posting it here for two reasons: to possibly help other people, and to get feedback. Let me know if it helps you, or if you would make any changes!
With all the different social media sites out there (Facebook, Twitter, Google+, LinkedIn, Pinterest, and more), it can be hard to figure out the best way to link to your different profiles and get people to like, follow, etc. The matter is complicated further by deciding whether to use interactive buttons, images, or just plain text links to your profiles. There’s so many choices to make, and so many methods, so let’s dive in.
First, you need to choose which method you’re going to use. If you’re going to just use a text link, it’s pretty easy. Just find the link to your profile, and wrap it in a standard HTML link. If you’re going to use an image, it gets a little more complicated. You’ll need to find an image to use. Then just use a link like before around the image. Don’t know how to find the link to your profile? All the information is below!
If you’re going to use an interactive button, it gets a little more complicated. The good news is that I’ve included instructions for each social network below! Just click through to the full post, choose the network(s) you want to use and go!
NOTE: Google+ has updated their cover photos again to be even larger. That makes my templates outdated. I haven’t put together updated templates yet. The Facebook ones are still good though.
Google+ introduced an entirely new layout yesterday. Pretty much nothing was left untouched about the design, and that includes profiles. Profiles didn’t change that much except that they got much more visual. And by that I mean that they copied Facebook’s cover photo feature. Don’t get me wrong: that’s a good thing! The cover photos are beautiful and can really help add personality to a by-the-numbers profile.
However, Facebook and Google+’s cover photos don’t work exactly the same way. The profile pictures are in totally different spots, the sizes are completely different, and most importantly, there’s two different layout options with Google+. So I’ve broken down the exact layouts of the new Google+ cover photos! I’ll go over the different layouts, and as a bonus, I’ve also included Photoshop documents with the exact layouts, so you can get things looking just the way you want them before uploading anything!
