Protect against existing settings folder #776
Labels
Comments
|
PR incoming! |
|
I think it doesn't really matter how the user came into the situation? Checking if the folder already exists is anyway needed (in case you create the folder manually). Thanks! |
vikaspotluri123
added a commit
to vikaspotluri123/Ghost-CLI
that referenced
this issue
Aug 8, 2018
issue TryGhost#776 In production sites, when the ghost user is used, the content/* folder needs to be owned by the Ghost user so the ghost application will not run into permission issues. In the migration, to make sure this happens, we run the `mkdir` command using sudo (i.e. `sudo -E -u ghost mkdir {path}`). When the Ghost user isn't needed, we use the `fs-extra` library to make sure the directory exists (specifically `ensureDirSync`). `fs.ensureDirSync` is equivilant to `mkdir -p` (not `mkdir`), so the behaviour differs. By adding the `p` flag to the `mkdir` command that's run when the Ghost user is used, the behaviour between the two cases are equalized.
vikaspotluri123
added a commit
to vikaspotluri123/Ghost-CLI
that referenced
this issue
Aug 8, 2018
issue TryGhost#776 In production sites, when the ghost user is used, the `content/*` folder needs to be owned by the Ghost user so the ghost application will not run into permission issues. In the migration, to make sure this happens, we run the `mkdir` command using sudo (i.e. `sudo -E -u ghost mkdir {path}`). When the Ghost user isn't needed, we use the `fs-extra` library to make sure the directory exists (specifically `ensureDirSync`). `fs.ensureDirSync` is equivilant to running `mkdir` with the `p` flag, so the behaviour between sudo and no-sudo differs. By adding the `p` flag to the sudo command, the behaviour between the two cases are equalized, and the migrations won't fail if the content/settings folder exists when the Ghost user is used.
acburdine
pushed a commit
that referenced
this issue
Aug 13, 2018
issue #776 In production sites, when the ghost user is used, the `content/*` folder needs to be owned by the Ghost user so the ghost application will not run into permission issues. In the migration, to make sure this happens, we run the `mkdir` command using sudo (i.e. `sudo -E -u ghost mkdir {path}`). When the Ghost user isn't needed, we use the `fs-extra` library to make sure the directory exists (specifically `ensureDirSync`). `fs.ensureDirSync` is equivilant to running `mkdir` with the `p` flag, so the behaviour between sudo and no-sudo differs. By adding the `p` flag to the sudo command, the behaviour between the two cases are equalized, and the migrations won't fail if the content/settings folder exists when the Ghost user is used.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From https://forum.ghost.org/t/trying-to-upgrade-from-1-8-6/2318/13. Please read conversation.
I am not sure how this user came into the situation. Somehow he upgraded from an older Ghost version and Ghost-CLI complained that the
content/settingsfolder exists already. I think we should just add a protection to our migration file, see.Any help is welcome!
The text was updated successfully, but these errors were encountered: