ghost-cli log destination option (and/or option to suppress logging to file)

[peterhuene]

I'd like to be able to install ghost into a location where the user account ghost is running under doesn't have write access to.

I've configured ghost such that it never writes to this directory (i.e. content directory is at a writable location), but running ghost-cli as that user causes errors because it doesn't have permission to write the ghost-cli-debug-$date.log file.

It would be nice if there was an option for the log file path so that it doesn't write to CWD (i.e. where ghost is installed). It would also be nice if there was an option to suppress file logging from ghost-cli entirely.

[acburdine]

@peterhuene this is definitely configurable via config.<environment>.json, it is just not super well documented. My thought is that two things need to happen:

1. better (i.e. centralized) docs on how to configure logging (it's powered by https://github.com/TryGhost/Ignition, which uses https://www.npmjs.com/package/bunyan under the hood). Feel free to take a look at those docs and configure it for the moment
2. Add some more config command line parameters to more easily configure logging via the CLI.

[peterhuene]

Hi @acburdine. Thanks for the response!

To ensure I'm on the same page, I'm referring specifically to the logging that happens here: https://github.com/TryGhost/Ghost-CLI/blob/master/lib/ui.js#L185. I should have mentioned that this is error logging to the debug file and not just normal logging.

It seems that this code is directly writing to the file without any possibility for configuration, or am I misunderstanding things?

[acburdine]

OH right that's what you're talking about, I misread the issue initially. My apologies 😄.
The only time Ghost-CLI writes to that file is if it encounters an error. What I can do is have it instead log to a location inside the user's home directory if that would work better?

[acburdine]

Ah I realized what might be your issue in the first place that caused the write error.

Whenever you run ghost start, it updates the .ghost-cli file at the root of a ghost installation to signify that Ghost is running under a particular environment. This is likely what's failing, causing an error to (try to) be written out to the debug log file.

So here's my suggestion: whenever you run ghost start, run it as a user with actual write permissions to the directory. If you're using the systemd ghost process manager (which is the default in a production linux environment), then you can modify the systemd service definition to run the actual Ghost process as your user that doesn't have write permissions to the directory. Keep in mind though that you won't be able to use sqlite for the db or upload any themes or images. The only thing you can do in that regard is to configure a storage adapter to upload images to s3. The theme interface, however, won't function because Ghost won't be able to save uploaded themes.

All of this is why it's recommended that the process running Ghost have actual write access to the folder it's in. Without that write access, ymmv.

[peterhuene]

That was the original issue, but this is being done in the context of a Docker container.

For now, I am doing ghost start as root to get the database setup if it doesn't exist, ghost stop to shut it down (I don't want it run asynchronously), su-exec down to a less privileged user, and then a ghost run as this is the only way I've determined I can run ghost in a synchronous manner; this is very important in the context of Docker since my init process ("tini" in this case; obviously not using systemd since this is a container) will terminate when its first child process terminates.

Note: the Ghost content directory is writable by the less-privileged user (it's actually a volume mounted into the container so that the data persists even when the container terminates).

Hope that makes sense. I'd love to see a ghost setup-database command that ensures the Ghost database is present and up-to-date (i.e. the work that ghost start does and that ghost run does not) followed by a ghost run to simply run Ghost.

At any rate, with respect to this particular issue, it would simply be nice if users could control what files the CLI tool generates into a place where it may not have write access to; writing the debug log to $HOME makes sense to me at least.

Thanks again for your quick replies!

[ErisDS]

At any rate, with respect to this particular issue, it would simply be nice if users could control what files the CLI tool generates into a place where it may not have write access to

The current incarnation of the ghost-cli tool needs to have write-access to the files inside of the folder in which ghost is installed, not just to perform installs and updates, but also to write log files, AND dot files which are critical to its working.

Seeing as ghost-cli is the tool used to setup and manage everything within this folder, not giving it privileges to access those files seems like the wrong solution here. It also doesn't seem like something we should be working around.

IMO, this is actually a duplicate of #189 - the fact that ghost-cli needs to downgrade privileges itself.

[acburdine]

Closed by #237 - error logs are now put in the home directory (under ~/.ghost/logs)

[ErisDS]

I really don't understand this change. If you run ghost-cli as one user, and ghost as another user, the logs are now under which user's account?

This is confusing and doesn't make sense to me. Again, I think we need to solve the problem of users, permissions and what the expectations are first.

P.S. IMO - this is a similar case to yarn or npm where having a local debug log makes 100% sense. If there is a clear case for moving the logs, then what is it please? And also what is the precedent for using ~/.ghost/logs as a location?

[kirrg001]

@ErisDS good questions. I am also a bit confused about having the CLI debug/error log in ~/.ghost.

[acburdine]

Apologies for the lack of clarification. The logs in question are debug logs, which are only generated if something goes wrong and is not a user error (e.g. ran a command not in a ghost instance, missing/invalid config value, etc.). Any logs generated by Ghost (not the CLI) are stored in /path/to/ghost/content/logs, the same as they would be normally. So to answer your question, the debug logs are under the home folder of the user that ran the ghost-cli command, not the user that actually runs Ghost.

It's exactly the same use-case as yarn/npm. Npm, however, no longer stores a debug log locally - it's stored in ~/.npm/_logs, so essentially we're following the same behavior as NPM. It does clean up the instance folder a bit, so you don't end up with a bunch of debug logs in the same folder. Thinking about it, npm's reason for change is probably more that npm-debug.log files were being committed to git repos (a use-case which we don't really have to worry about), but it still makes it cleaner.

Also, whenever a debug file is generated, a line is printed after the "debug info" that says "Additional Info can be found in <debug file in ~/.ghost/logs>".