Pre-requisites & expectations for running Ghost-CLI

I’ve been taking Ghost-CLI out for a spin in a production environment, and I’ve run into a few high-level conceptual questions about the high-level pre-requisites & expectations around running Ghost-CLI.

The TLDR; question here is how should your server be configured, what user & privileges should be in place, before installing & running ghost cli.

Use Cases

I think there are 3 main use cases for installing Ghost-CLI on a server, which need consideration, in order of importance:

1. Brand new blog on brand new install of Ubuntu (E.g. Fresh server)
2. Brand new blog on an existing install of Ubuntu (E.g. Adding Ghost to other software)
3. Switching from Ghost LTS to Ghost 1.0

We should absolutely optimise for case 1. This is the most common expectation for self-hosters. Case 2 should be rarer, but supported. Case 3 is temporary and so it doesn’t need too much attention.

Problem

Pre-requisite steps are mostly a documentation topic, however there are three areas where I think there needs to be some attention to the expected flow as they impact on how the tool needs to work:

1. What configuration of user(s) should be used to install, and then run ghost-cli?
2. In what order should domain setup be done vs running the ssl setup, in order for that to work smoothly?
3. What configuration does MySQL require prior to running ghost install?

These 3 areas are where I tripped up attempting to get from a fresh install to fully working Ghost. There are a couple of related open issues to do with sudo and ssl and in particular the combo of questions 1 & 2 means I’ve not really managed to get ssl setup smoothly yet - I keep getting Exit code 1 and it’s not possible to tell whether it’s failing because of permissions or because the domain isn’t reachable.

I have put together a gist containing all the steps I eventually used to get a working Ghost install. Inside it are several notes which clarify where the confusion comes & what steps don’t work in an obvious way.

I would like us to have a clear and consistent set of steps for the setup prior to running a ghost command in all 3 use cases, so that we can write this up in documentation.

I think we probably need to make some small adjustments for each of my 3 problem questions above, e.g. making sure ghost-cli can handle/expect the right level of user privileges & making it easily possible to run the ssl setup step as a detached second step if needs be.

[sebgie]

This is a summary of the current state and which mechanisms ghost-cli follows when being installed:

Enforced by ghost-cli:

• a system user (ghost) is used for running systemd

The requirement to run with a system user makes it necessary to change the ownership of the /content directory. This also means that whenever a user needs to manually edit/add/delete a file in the /content directory they will need super user permissions (aka sudo). This could lead to the situation where single files or folders don’t belong to the ghost user anymore. To fix this situation ghost repair-permissions and ghost exec (#317) will be implemented.

As it turned out during implementation the ghost run command is using the user that executes the cli command to run Ghost. This led to permission errors because the /content folder is owned by ghost. To overcome this problem the addition of a system user became mandatory for every Linux installation (#334).

• a new mysql user is generated if the mysql root user was provided

Adding a non-root user to mysql is done by ghost-cli (implemented in #191).

Not enforced:

• use a non-root user when using ghost-cli

This is highly recommended and all documentation assumes using a non-root user. The main difference when using a non-root user is that sudo is required to execute administrative tasks (install software, execute as another user…).

[acburdine]

Closing this as all of the smaller remaining pieces of this issue have been split out into separate, smaller issues.