Yup. The documentation is pretty thorough and the logs are all there.
It is all up and working. I was disappointed in the responses here. To be sure there was a big red herring in the troubles I reported. My site and VPS hadn’t been updated enough so it was necessary to do lots of updating: MySQL, NPM, nginx not so much (there were updates of course, but enhancements with no breaking changes–nginx is a rock), and of course ghost, which was most troubling to update.
The big problem is that an upgrade of 2+ versions of ghost seems broken. What fixed it was never suggested here but in independent blogs that suggest things that are “not recommended” or not approved here. Basically, I crossed my fingers that the databases would be all right. This turned out to be true. I made one offline back up of the ghost directories of the two blogs and one on the VPS (so it would be faster to copy selectively back into place). Then, it was necessary to completely uninstall and reinstall ghost. For 1 blog, the uninstall didn’t work and I had to rm -R. Since I wanted to leave nginx, MySQL, Let’s Encrypt in place with all of the existing users and passwords it was ok to not thoroughly purge–in fact, essential. This is the strategy recommended on an independent blog. For the 2nd blog I didn’t even bother with ghost uninstall and just deleted the ghost directory.
I tested out the approach on the smaller of the 2 blogs, which is really just a stub for experimenting–it has no content. This worked out the kinks, which were settings and finding out really how little of the old ghost directories were actually needed–not so much stuff, but all critical.
Then I did the same for the larger blog: this is a front door to 3 complete blogs (shared instance, just split apart in top level nav) in Ghost, plus links on the front door to static web sites generated with Hugo.
The weirdness of the database I’ll never understand. I don’t know what caused it because it happened without my touching anything. One night it crashed and wouldn’t restart. I think it ran out of disk space because dropbox was syncing stuff that should have been excluded (all it needs to sync are tiny markdown files for the statically generated web pages–but, I had accreted some new directories that I hadn’t “excluded”). I think this is the best explanation.
The real breakage was the failure of Ghost to be able to update itself across 2 major versions (I was already > 1.0 so at least the cli could be used).
I had only 1 config problem as I frantically tried things that had nothing to do with the real problem. For the smaller blog, the production.json and nginx server blocks were correct. The larger blog had one leettle error that was huge: I get the port crossed with the smaller blog, which–of course broke both. But, the breakage of Ghost itself had masked this because I couldn’t even start Ghost after upgrading. After the uninstall and reinstall it started right up (both times) and then a 502 and looking at ports for running processes showed there was a port mismatch.
Also, “bootstrap-socket” is no longer used in the most recent versions of ghost–the new config for nginx simply doesn’t use it. Not clear whether this caused ghost to not start. I doubt it. With new versions of Ghost, it is not only Ghost that changes. Some of the correct or preferred settings also change. Not everyone realizes what so there is some out-of-date information about what the setting should be (note elimination of bootstrap-socket).
I got both working–the second one worked immediately with only one change for the correct port.
I then had to copy assets and some settings from the backed up old ghost directories. I did not do a bulk copy over the new (that would have been a disaster!): I compared the two and found that only a few things needed to be changed:
- settings/routes.yaml
- copy over the images (entire)
- copy over the old data.json files just to have the complete history–not functionally necessary
-
not the logs: completely out of date, so let’s start fresh
-
not the versions
-
not config.production.json: the new versions were created correctly during the prompting sequence because I had the database name, db user, and db password in a secure password store–so I just answered the prompts. Of course, the url is easy and localhost is std for a simple default installation of MySQL. The databases flowed into the new installation w/o a hitch.
-
not systems/files containing the source config files to symlink into /etc/nginx/sites-enabled. Essential to look at the old and new versions and prefer the new except for content related items from the old (locations for static files in my case).
It was unfortunate that no one here seemed to even have a hint of what needed to be done. When I pieced it together from external sources and looked carefully at the thorough install/config documenation and realized I could salvage everything–all I needed was 2 clean instances of Ghost and complete reinstallation was the only way to do that.
Once I had a strategy that would work, it took a little over an hour to do twice. Most of that time was making the offline backup of the two ghost directories across the internet. But, when I actually did the work, it was WAY quicker to just cp ghost directories to another place on the vps and was quick to copy “locally” on the vps the fragments I needed in the new installation. The fresh installs of ghost were very quick. I needed to set permissions and owner:group for the ghost directories and create one symlink because I broke the config when I was scurrying around earlier.
The cli is a bit of a mixed bag. There are great things it does for a 1st time “correct” install. Running it and skipping things works pretty well to build “config” for the reinstall if you have all of the right information for the prompts. It’s not very good as a diagnostic tool because it can give a false positive: it says all is ok when all is not ok. That is really frustrating: it is perfectly obvious the blogs don’t work or ghost itself won’t start but the doctor has no idea why. On the other hand, it doesn’t give false negatives: when the cli said something was broken it was always right and gave correction suggestions that worked 1st time. And that was really helpful.
Advice to the team: ghost needs diagnostics for upgrading itself. Or–if it detects it is upgrading for too much of a jump, it should offer to do a safe uninstall and safe fresh install. This would be made safer by ghost-cli preserving the old stuff by renaming and then giving one of its helpful hints of what to bring back. There is not that much user stuff in the ghost directory (by type: images can obviously be big but it is a safe copy or rename in place). It wouldn’t be that hard to do a safe uninstall/reinstall process. I managed to do it manually with very little work simply by inspecting the contents of the directories.
All in all: very frustrating to figure out what to do and relatively easy to actually do it. I’d say that self-hosting Ghost is much harder than self-hosting Wordpress or Hugo (not fair–it’s just files, a theme, and one executable). Ghost is more polished so it should have shown itself better. But, I think there is over-reliance on the -cli as a black-box. The black-box approach needs a deeper mode that exposes more of the underpinnings: essential when things go wrong (too often judging from the forum) and when a config is acceptable but non-standard. This seems possible. Despite all of the dependencies, under the hood the config is not that complex.
Most of the time spent blogging is writing not doing sys admin. Then Ghost is really good. One can go months and months without doing any sys admin. But, when it comes up, it is a truly a pain when we do not do it for a living.