Who in this godly world thought it’s a good idea to force you to make your webserver user have to be sudo?
My setup is an Ubuntu 20.04 bare metal server. The server software I use is Caddy v2 running under www-data
I’m looking at alternatives to WordPress and found ghost.
However during install, it’s demanding my sudo password. Huge problem as the webserver user has no password and doesn’t have and never will be given sudo access (security nightmare!).
Can I manually run the commands under my normal user account that does have sudo access? If so, what do I need to run.
Do note just give it sudo access is not an option, I have never and will never give an Internet facing application that’s not behind 4096 bit RSA key authentication (and that’s only for SSH!) privileged access
Ffs it’s not even letting me run it as root, so you’re literally forcing me into a security nightmare.
Yeah let my internet accessible application have unlimited privilege great idea!
Also how do I work around it wanting to run as ghost user? I have multiple sites behind Caddy and all of their files are owned by www-data with 700 permission
The Ghost CLI is used to help automate installation and management of Ghost instances for self-hosters. Part of the process for full installation requires configuring a process manager (systemd) which may require root permissions. Configuring nginx (the default web server) also requires root permissions.
If you don’t want the CLI to do any of this, you can tell it not to. It’s more than possible to use the CLI for installing and updating Ghost without any other integration with the system. Of course, you’ll have to configure some stuff yourself.
Before posting again, please take a moment to review the Ghost Code of Conduct. I understand that you’re frustrated, but making incorrect assumptions and inflammatory statements are not acceptable.
To be clear, the system user that runs ghost will never need sudo access. The user that installs Ghost might need sudo access.
And of course, the install docs mention absolutely nothing about any other install methods than the default one.
I really don’t care about system integration:
- I’m not using NGINX
- Caddy has built in SSL certificate management (reason #1 I use it
)
- I’m more than capable of writing my own systemd services (caddy is using one since I built it myself)
And of course I’m going to run the install as the user it is going to be running as, otherwise it’s going to not going to have access. This is a multi user server and multi service server; permissions are very restrictive by design (sudo group doesn’t have sudo access even - that’s limited to my user only).
At any rate, you told me there is a way around it and didn’t mention how.
Once again: how should I work around needing sudo access to install?
I did end up trying a local install with caddy doing a reverse proxy but then my browser said localhost: connection refused on the main page, so I figured it probably needs that URL set correctly to function (even though this is running on my non-production site, I’m still accessing it remotely)
Again, please take a moment to read the CoC linked in my previous thread.
You’re right that I didn’t tell you how, and that’s because I forgot that the CLI handles the issue you mentioned
by running sudo chown -R ghost:ghost /path/to/install/content because that’s the only folder the system user needs access to (everything else needs to be read-only). I was expecting that saying no to systemd and nginx would be enough to have the CLI not ask for sudo access
You can bypass all sudo requirements by adding the --no-setup-linux-user flag to the installation and saying no to systemd and nginx. (e.g. ghost install --no-setup-linux-user)
Just so you understand, the CLI has a happy path that works for most users. It’s possible to use the CLI outside of the happy path, but there’s a lot less documentation and hand-holding because functionality is a “best-effort” guarantee.
Systemd step doesn’t seem to let me skip it
Can you post a screen shot with what you’re seeing? It’s hard to debug w/o context 
Hmm, seems it complaining about systemd is a non-issue just an incorrect error message - it’s loading fine now 
It however doesn’t prompt me to skip systemd setup but says it’s already setup, but then informs me it’s corrupt
Actually it’s not oof, browser caching
Can you run ghost ls to see if your ghost instance is running? If it’s not, maybe try running through the setup by disable all the things by default (ghost setup --no-setup-linux-user --no-setup-nginx --no-setup-systemd)
Ooh, I thought you were saying systemd setup failed…
You’re going to have to set up systemd independent of Ghost, and use it to start / stop Ghost
… which also means ghost ls will probably be useless for determining what ghost instances are running
Perhaps this could help you setting up systemd for your Ghost instance:
[Unit]
Description=Ghost systemd service for blog: yourblogname.net
Documentation=https://docs.ghost.org
[Service]
Type=simple
WorkingDirectory=/var/www/yourblogdirectory
User=1003
Environment="NODE_ENV=production"
ExecStart=/usr/bin/nodejs /usr/bin/ghost run
Restart=always
[Install]
WantedBy=multi-user.target
I’ve got it running just one issue I have left:
Can I make / point to /home? Thing is I have a custom homepage that can’t be easily handled with the home.hbs trick outlined in the docs
Have you seen this tutorial? If you’re having issues, can you share the routes file you’re using?
That’s exactly what I don’t want to do. I don’t have the inclination nor know how to translate my existing rather complicated home page to an hbs file
Renaming home.html to home.hbs should be enough
