Did you see it?

You know, I bet you didn’t! I moved servers again! It has been less then a year since it happened last, which is quite dissapointing. There are a few reasons for this. I’ll be kind and fail to disclose the company as the support has been first class. The VPS industry is becoming alot more competative, however.

A current distro wasn’t available at time of setting up. Meaning I had no choice but to use an Ubuntu 14.04 image which was already ageing at the time of setting it up. Although I was pretty comfortable and familiar with using it, the LTS clock was ticking.
I can say now, even though there’s a little time left, 14.04 is really showing it’s age.

Sluggish. Yes it was hard to tell if the software, configuration, OS or I/O was the issue, but it slightly hindered me none-the-less.

Manual backups… eeeugh. I could have paid more to have automatic backups, but I felt I was paying enough taking into account the previous points. Also it was a chore… my policy was to backup every month which wasn’t enough (even though this isn’t a business site). It was more difficult whilst having an hour or so spare on a slow internet.

Price, which is an important factor when you’re hosting a site as (at the moment) a hobbiest. Again, taking in all of the above, I felt I was paying way too much compared to other places.

I found myself staring into the VPS void. Again. Unsure of which direction to throw my money. OVH did not have a UK server location, my last experience with 1and1 left me feeling like a sudo user. I wittled it to 2 new hosts, dive into DigitalOcean or try Vultr. I credited both sites and spun up a vps and had a play around…. and was really impressed.

I bit the bullet and went with Vultr. I like the way the site is layed out, how easy going it seems. Its a nippy server, its alot cheaper (including automatic backups), it’s located in the UK with many images to choose from, and has a good solid self-help database which covers alot of different topics.

It took alot less time to set up then it did with the previous host too, which might not be surprising as 14.04 was alot more configuration intesive. Newer software with 16.04 kind of solves this with hardened config  as standard (although you still need to check)

Lastly, one feature I’ve really taken to Vultr’s login page! All the previous hosting companies have allowed (some of them weak passwords) just a user/email and password to login! You spend hours hardening the VPS, but you can guess a password and delete/change anything you like. This really needs to be looked at but thats a different story.

It’s early days but I’ve really enjoyed the experience so far! You can check vultr here!

Server Musings

It has been a nice while since I had anything to report about the server. Nothing to report! Brilliant!
It has been running really stable with no issues and now seeing long up-times between the usual software and kernel updates.

It’s time, however that I started to think about the future. Time is slowly but surely ticking for the LTS support end date for Ubuntu 14.04, and now I need to put plans in place for a migration to the new system. I am a bit worried, however.

Ideally, I want wait for Ubuntu 18.04 to be released as it is a nice crossover point to make a jump from an ageing LTS to a brand new LTS. I’m worried because previous experiences will tell me that Ubuntu doesn’t like to be involved in major upgrades.
How my VPS host handles different kernels and OS images is also concerning.

My primary idea was to create a local installation, adapt it to the remote server’s configuration, upgrade databases, reinstall and reconfigure software and finally unpack everything remotely. I think that I would like to test it on a “spare” server some day, just to see if the process works. If so, it would be my #1 choice to upgrading the OS.

My Wiki Obsession

Bad news; the wiki is working. Bad because I want to expand it already.

I like the idea of a NAS but I couldn’t justify paying for a commercial NAS unit as I probably wouldn’t use it that much. It would primarily be for backup, mainly. Now I can see a purpose. Perhaps on my internal wiki, I have a page for ubuntu, with distro related info going on there. I currently have a neat folder tree on my 2tb VAULT drive with ubuntu ISO’s, Debian ISO’s… . You get the picture! If I were to create a download directory on the web server, I could link and subheading all of these files. Not only to preserve the files but also include information about them.

“Now what’s the point in that? You can just download it off the web, surely!” Well this is one specific example but it can be replicated across all files that I have for that ‘just in case’ moment. It will allow me to archive some of these already existing files. It can also allow me to have stuff on demand for other computers; like when I need drivers or game installers. (Getting excited about the prospect of keeping computer drivers archived in this way) Continue reading “My Wiki Obsession”

Home Wiki Server

I woke up on Sunday and thought it would be nice to centralize all of the snippets of information that I find useful and have saved up. Being a casual sysadmin, there’s alot of things I do not use on a regular basis and gets scrambled up with mundane real life.

I currently have these infobytes scattered in my OneDrive, separated into different text files. I suppose this is handy to have on demand everywhere, but to be able to organise and retrieve information in a less painstaking way would be better. Continue reading “Home Wiki Server”

MYSQL Crashes… FIXED!

I was awoken today with a rather rude message indeed. An email from Jetpack plugin notifying me that the website was down. I often get this message at the most awkward of times, mainly whilst unable to log in to the server.

Opening up the site shows me an alarming message “Unable to contact database”…. the worst kind of messages. Databases have never been my strong point… I find them terribly complicated and I tend to just leave them alone as much as I can.  Now what? Annoyingly MYSQL seems to quickly zip up any MYSQL error log files, often leaving the latest error log almost completely empty. Another annoyance.

Trawling through the logs, I can see MYSQL has shut down, restarted, shut down, restarted, until it finally gave up. Quickly found the error…

innodb is trying to pass over 130MB of indexed(?) files to the allocated defaulted 128MB buffer size pool. After a bit of tinkering and increasing the size, the site not only has greatly improved response time, but it should cure the site from going down regularly.

It’s not fixed until the fat server sings…

It’s early days but I’m confident the issue is resolved. I will monitor the situation to hopefully find 30 WHOLE DAYS of uptime. Here’s hoping.
( that is not an invitation btw 🙂 )