I Ain't Afraid Of Upgrading Ghost On Azure

This post focuses on how I got my password back, upgraded Ghost (and Node) on Azure, and some of the things I learned along the way.

How this all began.

Like most developers, I have roughly a million passwords that I use for a variety of things and primarily due to some of the other issues listed, I can occasionally forget or mistype something five times.

Once I realized that I was actually locked out of my account, I thought that it would be no big deal. I can simply send a "Reset Password" email and be on my way. This would normally be the case, unless you forget to configure the mail service on Ghost to actually do that.

So, here I am. Locked out of my own blog and unable to actually reset my password. So, I thought, why not take this time to actually upgrade Ghost to the latest version and hack my way through unlocking myself in the database.

Updating Ghost on Azure

If you haven't played around with Ghost on Azure, it's incredibly easy to get started with it. Felix Rieseberg actually has a GitHub project called Ghost-Azure, which is basically a one-click and you have a way of deploying it up to the cloud.


If you deployed Azure this way, then you'll find that syncing your Ghost deployment can be managed entirely through the Azure Portal via a Sync button.


Clicking Sync will target the current Ghost-Azure repository and handle the upgrade process for you and that's it. Super easy right?

Well, what if that doesn't work?

Apparently, for most of the population, the previous Sync approach works just fine. I'm not part of this exclusive club I'm afraid. Upon restarting the Web Server and attempting to access my site, I was met with a blank screen.


Not good. Thankfully, the Developer Tools let me know that some kind of generic 500 error was being thrown, which is always super helpful. So, I needed to dig a bit deeper.

Meet Kudu

When troubleshooting the 500 error, there wasn't a great deal of information at my fingertips. Since the site was running on Azure, I wasn't able to easily just RDP into it and check out the Event Viewer or look at a Stack Trace.

Thankfully, Azure sites feature a service called Kudu. Kudu is the engine behind just about everything with regards to Git-based deployments on Azure, but it does so much more.



Kudu can tell you just about anything that you need to know about your applications and provides a bevy of great and useful features.

• Debugging Consoles
  The web-based portal provides both a normal and Powershell-powered consoles that allow you to execute commands within your application, run that installer that you FTP'd to the site and anything else you would need to do from a Console.
  
  
• Environmental Information
  Kudu will provide you with just about anything that you could want to know about your site. Connection strings, paths, HTTP headers, server variables, system and architecture information, etc.
  
  
• Process Explorer
  There's also a fully-featured process explorer and profiler, which allows you to see all of the current processes running on your application. CPU usage, threads, memory allocation, and more.
  
  
• Error Logs and Dumps
  Full access to streams of the applications logs, diagnostic dumps, etc. This is great for figuring out what might be blowing up behind the scenes and give you a path towards fixing it.

And all of this is provided to you automatically through Azure Web Sites. You can access it for your own site by using the following URL.
https://{your-azure-site-name}.scm.azurewebsites.net/ .

Exploring Kudu's Logs

So after digging around in Kudu for a while, I tried to figure out what exactly was going wrong and came across the following line

$ npm install sqlite3 --save
Error: Cannot find module ' D:\home\site\wwwroot\nodemodules\sqlite3\lib\binding\node-v46-win32-> ia32\nodesqlite3.node'

So, the first piece of resolving this puzzle was realizing that the actual node-v46-win32-ia32 folder didn't exist at all within the project folder.

I'm assuming that the updated version of Node was looking for the appropriate SQLite dependency that corresponded to that version. So I decided to explicitly tell Node which version to use by updating the package.json file located within the wwwroot directory as follows,

This would force Node to check for the more appropriate version of the SQLite module that matched our existing location of ~\sqlite3\lib\binding\node-v11-win32-ia32, which actually exists.

Still Locked Out.

So, the good news is that the site is actually running, the bad news is that I still cannot log into it. So, I decided to locally download the ghost.db database onto my local machine and use DB Browser for SQLite to dive in and see what my data looked like.

Thankfully, Ghost made this insanely easy to figure out as I just had to take a look into the users table.



As you can see the status field is set to locked. That's no good. After looking at Ghost's documentation, it seemed that a quick SQL query could fix this up with an UPDATE query.

UPDATE users
SET locked = 'active'

After making this change, I FTP'd up this copy of the database and restarted the site to find that everything worked as expected.

After nearly two months, I was finally able to log into my own blog.



TIL

Despite being a pain, this process definitely made me more comfortable with Azure and introduced me to Kudu, which is a kick-ass service. Since I like bulleted lists, let's use one.

• Don't Forget Your Password / Get Locked Out.
  This obviously goes without saying, but things get much easier if you don't get locked out. If you do, just download your database, unlock yourself, and try again.
  
  
• Set Up A Recovery Mail Provider.
  Alternatively, you can use MailGun or an SMTP provider to handle the e-mail recovery process for you. It's seriously two lines in a config file.
  
  
• Consider an Automated Backup.
  Azure Web Sites provide numerous ways to schedule an automated back up, which could help curb some of the pain of this process via a one-click restore.
  
  
• Kudu is great.
  Ghost aside, Kudu is as close as you'll get as far as manually remoting into the server and digging around. The logs, the consoles, available dumps and information help alleviate some of the crap that gets in the way of troubleshooting.

Overall, this was a fun exploratory process that I hope that I don't have to go through anytime soon. Hopefully, it will be helpful to some of the folks out there that have encountered this or similar issues, or at least introduce them to Kudu to help ease the process.