Blog Migration H-Eeeee-Double-Toothpicks And Why I Left #AWS


Due to (technical) knowledge constraints I thought I overcame, I recently gave up hosting my blog with AWS. According to the conspiracy theorist inside my third-eye, I think the problem I had hosting at AWS was due to the fact that they couldn’t up-sell me and my lolly blog from being free-tier to being (insert $-amount) per month. Yeah, “free-tier” at AWS is only worth it if:

  • You don’t get many hits at your blog
  • You’re a webserver expert.

The only way AWS would help me with any problems was if I paid them for the help. In other words:

  • Free-tier web hosting at AWS is cool until you need even the slightest amount of help.

Now ain’t that suspicious? It’s especially suspicious when it’s obvious that a problem occurs not because of what I did but becuae of what AWS did which amounts to things being:

  • Suspicious.

But don’t get me wrong. I’m only blowing off some steam here. The problem I had with hosting my Worpress blog at AWS was solvable. I just didn’t know how to solve it–and something was telling me that if I’m gonna have to pay to have that amount of limited service, AWS isn’t for me.

The pseudo dream has always been to actually set up my own server at home and run my compulsive writing blog there. It’s really a rather simple thing to do. That’s what makes it extra frustrating that I couldn’t solve the problem at AWS. All one has to do is connect a home webserver to the outside world. For this you need the proper bandwidth. It’s no coincidence that we all can get high downloads speeds with our home Interent connections but only measely upload speeds. In Germania, as well endowed with phone lines and cable lines as the country is, I’m sure that the powers-that-be don’t want people to start hosting their corners of the internet at home. Indeed. And so. I constantly had the following error while hosting my blog on a Linux server at AWS:

  • “Error establishing a database connection”

As best I can tell this “error” is due to a mix-up between WordPress, which is my blog content management system, and AWS’s management of its server iterations. The mix-up or “error” occurs when one or all of the following happens while hosting a WordPress blog:

  • Free-tier blog gets too much traffic
  • AWS fiddles around with its systems and thereby forces changes to WordPress configuration files.

The thing is, I don’t feel like going that deep into all this technology krapp. It was actually a fun project a few years back when I went from 1und1 hosting to AWS. Installing Worpress on AWS was cool. But it’s now clear that free-tier doesn’t mean what you think it means. And that’s fine. I can deal with that. And I can even pay a couple of bucks a month to WordPress in the hope that all those database error messages are over.

We’ll see.

Rant on.


A Very Beginner's Guide To Migrating & Hosting WordPress On AWS


Update: After about a year of useage, as of the end of 2016, I’ve given up on AWS and moved my blog to Reason? I was consistantly getting an error notification that my blog was “down”. This happened at least once a week. The only way to deal with the problem was to reboot my instance. According to the web, this is not an uncommon problem with self-hosted AWS blogs. The cause of this problem I’ve never figured out. WordPress claims that it’s a problem with AWS. AWS claims it’s a problem with wordpress. At this point I don’t care anymore. What is clear is that there is a level of complication at AWS that is dependent on paying AWS for any level of service–which renders the service a paid-service–NOT a free-tier service. I’m sure that more tech saavy blog users can deal with this issue but I’m obviously not one of them and although I can install wordpress on a server and get it running, I’m not about to start fiddling with win95-krapp like mySQL, i.e. the database system where wordpress stores blog content. Also. If you ask me what the problem really is and you’ll allow me to best-guess it, I’d say it’s this: once an AWS self-hosted, free-tier blog gets traffic AWS breaks the connection between wordpress and mySQL. Unless fixed within the code of your wordpress install and/or a few adjustments are made to your mySQL database, the problem creeps up everytime your blog gets too many hits. After trying and not getting any AWS tech-help it become obvious to me that in order to get things going without having to restart my blog every week, I’d have to go to a paid-tier level of useage with AWS. I concluded that if I had to start paying for this level of service at AWS that maybe I was in a bit over my head. In the mean-time, I’ve tried hosting my blog at Bluehost–but concluded that, although they had good service, I just didn’t feel like the whole back-end krapp of keeping my blog up. I’m now paying to host my blog. We’ll see how it goes. And now, on to the original post…

If at first you don’t succeed… rest before trying but most definitely try again. As mentioned here, I recently migrated from 1und1 hosting to Amazon Web Services (AWS). Why? Well, nothing against 1und1 but the service I migrated to makes 1und1 look a bit old and dated–and AWS is much cheaper. In fact, unless I get a lot of traffic to my site, AWS is free. Plus, I am moving to India soon and I thought it better if I oriented my web content around a service that is a bit more international. But before I get into complaining about 1un1, here’s what I did to make this move. Good luck.

Step 1

  • Backup blog.
  • Put backup file in a safe place.
  • Install and use the WordPress (WP) plugin All-in-One WP Migration to export blog to download folder. Make sure it’s there and make sure you can find it.

Step 2

  • Sign up with AWS.
  • Go to EC2 and launch, setup Instance.
  • Pick your server. I picked Basic Amazon Linux. Go through the setup process following all the default settings. There are a couple areas where you have to name things and provide input regarding web hosting but all-in-all getting the Instance running is easy.
  • Here’s a great webpage that provides pics on how Instance setup is done.
  • Btw, “Instance” is just another word for Server.

Step 3

  • Migrate your domain names using AWS Route53. I was not only moving my website to a new host but I completely forgot about my domain names that were still at 1und1 when I started this.
  • With that in mind, this could just as well be step 2. This did cause me some problems later during my first install attempt. (That’s right. I went through all of this more than once.)

Step 4

  • Establish SSH connection using the Mac’s Terminal App.
  • Note: during Instance setup you are given a security “key” in the form of a file that you must download to your computer. Save this “key” on your computer and always know how to access it. Do not lose it or throw it away.
  • Use Terminal and the Linux chmod command to change the access rights of the key .pem file accordingly. Actually I’m not sure if this is required. I don’t think I did it on the second install. Oh well.

Step 5

  • Using your SSH terminal connection to your AWS Instace, install LAMP. Linux Apache MySQL PHP. This is where things get fun with the CLI. If you follow AWS documentation, though, it’s a no brainer. Seriously. I did this twice and it’s the easiest part of the whole thing.
  • Here’s a AWS LAMP install tutorial.
  • When this is done your webserver is running–but you’re far from home.

Step 6

  • Install WP.
  • This is where things get fun. And allow me to add this slight poke at WP.
  • Considering the requirements of launching a AWS Instance and then installing all the proper software for a webserver (LAMP), you would think that installing 7mb of files from WP would be a piece of cake. Well, it ain’t. This is the hardest part.
  • AWS tutorial installing WordPress.

Take a break. Don’t drink alcohol. Espresso. Espresso. Espresso with sugar.

Here a bit about how Step 6 is the hardest. As noted (with pic) in this post, the biggest problem with WP install is being given the choice of where to install its files. This is totally confusing. I guess the choice is about whether or not you are gonna install more than one blog or if you’re a stickler for sub-directories. I still don’t know how sub-directories determine more than one blog but since I only want to get one running, the issue is mute. Anywho. After initially screwing this up and then thinking about it, this is what I’ve concluded about how to deal with this simple but devastating issue.

The Linux folder that Apache (the webserver) accesses when delivering http requests cannot change once it’s set–unless you want to configure Apache, too. No thanks! Therefore, you must install WordPress within the proper Apache directory. Hence, the AWS tutorial has you download WP with the wget command to your Instance root directory–where there is no Apache. Later on you have to move the WP folder to the proper Apache directory. Keep in mind, the way Apache is setup is that it will only deliver http requests from the Linux folder “/var/www/html”. Aghast!

Why AWS has you go through this directory mess during a simple single blog install makes no sense and is obviously confusing. If you make a wrong choice here, you basically kill the entire install when you setup WP. Also. When installing WP to a sub-directory (i.e. the Apache /html/directory) you are required to add that location to a WP-Config.php file. Why would a simple install of such a simple thing require the complexity of editing a .php file? And so. On my first install I got the directory right–probably because I didn’t think about it. But I screwed things up when I went through the WordPress setup. This also the area where I realised my domain names were still at In the end, I did not want to access my site through some lengthy, computer generated URL. When I went to change that to in WP>general>settings, I broke the whole thing because Apache couldn’t know where to find the html files. Aghast, aghast!

When I first made this mistake I thought I could fix it from within the WP>general>settings. Wrong! Then I tried to follow some other documentation after googling and requesting help from AWS support. That lead to actually going so far as to use the Linux nano editor to edit .php files. Again. It didt work. What a mess. Oh yeah. Aghast!

The only solution I could find to the problem was to terminate the whole Instance and start over. Which I did. What a waste, eh.

I repeated everything on a new Instance. I was very careful when choosing where to install WordPress in Step 6.

Step 7

  • Once WordPress is running, use All-in-One WP Migration plugin to upload/import the file you downloaded in Step 1.
  • Re-initiate your connection to WordPress.
  • Log-in
  • Bang.
  • Done.
  • Happy worstwriting, baby.

For those interested, here’s a pretty decent bunch of videos that I came across from two guys who mastered the struggle a bit better than me.

Rant on.


Arduous Feet Amongst The Intrepid Or Peace Pumpkin Cake While Changing Hosts


Note: an update and follow-up to this post is here.

It began on Thursday. It ended the following Monday in the wee hours. What is ‘it’? Well, I finally got around to changing my Internet host. Appropriate (or not) since I’ll also be changing countries soon. (But that’s another post.) It’s not that I was, am disappointed with my previous host. In fact, I moved to a much more complicated hosting service. Complicated in the sense that there was more person to person tech support at my old host. On the other hand, my old host was boring, it was connected to an archaic landline telephone system that I don’t use anymore and every year, usually around this time of year, the host’s Internet, aka also my ISP, goes down for a week. (I think it has to do with the Cebit and Germany not allocating enough bandwidth to private users during the huge trade-fair so they scrape bandwidth away form paying customers. But at least I got a “data stick” from them last year–which I have never even used. But I digress.) Wait. Let me put things another way.

I did receive tech support from my new hosting service but it was only in the form of email. The guy that helped me was named Evgeny. Can’t tell you how curious I was to ask him where he was from. But when I would write something off-subject in my email response, his response was always on subject. No fraternising there, eh. Until, of course, it came down to the WP install and setup. Evgeny helped me with all the Apache, MySQL and PHP and Linux stuff. He even helped me understand the difference between “Istance” and “Server”. (There is no difference, btw.) Which brings me to a question I tweeted while pulling the hair out of my chest for two days after I screwed up one basic setting during the WP install.

Why can’t the install process of WordPress, my all-time favourite writing software/tool, be a little less hacker-fied? (Is that a word?)

I mean, I don’t mind all the Linux commands I had to cut & paste from the install documentation provided by my new host. It’s just that, eventually, there is a sy of relief when you finally encounter a GUI again. Linux command lines be damned! On the other hand, I got through the CLI with flying colours. Not one misplaced single-quote (‘) or semi-colon (for PHP code) or one misuse of the most feared asterisks (*) when using the command “mv” with files or directories.  Which means you go from this (example):

[ec2-user ~]$ chkconfig --list httpd
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

To this:

wp general settings screw up
WP general settings screen where life can be good or…

Indeed. Get through all the Linux coding and then finally get a GUI to work with but then make the stupid mistake of inputting the wrong web addresses in the right place because you’re kinda blinded by all the CLI interaction after five or so hours. That’s all I did. I made one little, stupid mistake. After that, no more access to wp-admin or your domain. No more access to a setup screen or even restore or backup file. I tried everything. After googling the problem and reading various forums and blog posts, there was nothing to be done. Manipulate this .php file or that .php file. Nothing worked, nothing got me back into my website once I screwed the pooch during the WP setup. Talk about über frustrating.

After trying for two days to fix my error I finally gave in and terminated the Instance and started anew. I know. I know. Real hackers would find a way to solve the problem. But I’m just a lonely wannabe hacker. I only like the idea of coding and networking and unpacking, unzipping, tarball file manipulation. Plus, all this meddling around only took away from worstwriting. Yeah, blood was boiling. Anywho. Long story short. After about four days I was finally able to migrate my website from one host to the other–including the migration and transfer of my domain names. The only thing I lost in the process was a bit of sanity. What I gained? The reassurance that tech-geeks the world over deserve their big bucks.

Oh, one last thing. As good as the email tech support was with Evgeny, nothing can replace having a neighbour that is a professional network manager. So. If you ever undertake such a task as this one and you have absolutely no training in webservers, Linux and wordpress installations, make sure you at least have the neighbour(s) to call on when you’re pinched. Yeah. They come in handy. The best part is, after he’s helped you get your site back up and running, you can offer him his favourite cake–which I found out from his wife after she complained about me stealing her husband for so many hours over the weekend.

Here’s a great recipe for pumpkin cake.

Rant on. -Tommi