Score:0

Server

Best Path for nginx Files

Rich_F

2/27/24, 9:25 PM

I've always struggled with various paths for nginx files and where they should be positioned. As we know, we can change where we can park both the www directories for our web app, as well as the associated log files.

The issue that I've found is that I have bash and Ruby user scripts both for SSH calls as well as crontab scripts that need access to various parts of these nginx files, as well as scheduled network copies of various files, not to mention updates to these files.

I have adhered to the static paths recommended by the package installation of nginx in various distros, however I've often run into permissions issues as the path was not optimal with regards to accessibility. So I would research the various main linux paths and choose something that was designed with all this in mind, while maintaining a good level of security. I've seen various locations, and now that I'm onto this again (crontabs not working, permissions issues on various items, etc.), I thought I'd ask where all this should be located.

My apps are not standard static html applications. I have a Rack application with an app server running, a Gemfile, as well as any incoming uploads, etc.

The two locations that I'm assessing are:

/usr/local linuxfoundation.org
/usr/share linuxfoundation.org

However...this is what I read for the /usr directory:

/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.

Large software packages must not use a direct subdirectory under the /usr hierarchy.

So I'm lost. Can anybody recommend a location for readable/writable files that will give me minimal hassle trying to script and cron?

2 + 2

permissions

ssh

nginx

path

shell-scripting

JoelCrypto

2/28/24, 6:37 AM

Maybe I don’t understand but what about /srv/ ?

Rich_F

2/28/24, 4:17 PM

The docs say __read only__, but then says __Writable data and scripts can be reasonably placed__, whatever that means. Because it's `nginx`, there are at least two users that access these files, so it gets complicated. https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html

Score:1

Server

Danila Vershinin

2/28/24, 9:14 AM

The "by all means" proper location for hosting website files is /srv/www. From there I typically "partition" this to domain related directories.

So all in all /srv/www/example.com has this structure/subdirectories:

public stores any publicly accessible files bound to that domain/website
logs stores any logs files (be that NGINX, PHP-FPM, etc.) bound to that domain
sessions stores user specific sessions e.g. PHP sessions

Whether you use PHP-FPM or any other "script daemon", you want to set the permissions right, by adjusting your daemon settings and chmod/chown the files correctly. There's no magic location that secures you from having to configure permissions model. See NGINX and PHP-FPM. What my permissions should be? - this very well applies to most website setups, irrespective of PHP-FPM:

Add a separate user for each website, for proper isolation, e.g. example
Configure your script daemon to run as that user
Have your webserver (NGINX) user be the group member of your site user: usermod -a -G example nginx. This allows NGINX read to read files that have group permission set to read, and you can secure files you don't want it to read (config files) by simply removing the group permission bit from chmod

At the end of it all, there's never a permissions issue: everything is owned and "run" under the very same user!

+ 4

Rich_F

2/28/24, 4:28 PM

OK, good. You park your `logs` within the `vhost` subdirectory. I thought that was a security risk of some kind, no? Your third point answered my question about multiple users (i.e.: `group` them). Thank you.

Danila Vershinin

2/28/24, 5:36 PM

I think it doesn't matter if you place alongside or not. Once you configured PHP-FPM/script daemon with your site user, and it owns all files, including the generated logs, there is a security issue wherein if the site is hacked, and that user is compromised, logs can be wiped. Such an issue is for the "script daemon" logs, but NGINX logs won't be affected (as they will be written by the nginx user). That's why it is good to log remotely (e.g. papertrail).

Rich_F

2/28/24, 8:35 PM

Ya that's what I meant by logs, the `nginx` request history/`404` logs.

symcbean

2/28/24, 10:51 PM

As OP has now stated they are using Almalinux, the solution proposed here requires implementing an SELinux policy for httpd_t on the new directories.

Score:0

Server

symcbean

2/28/24, 4:07 PM

Voting to close this as the question is really vague. Also you are seeking to blame your tools for the situation when they are not the source of the issue. You are, to some extent, constrained in what you can/should do by the MAC susbsystem and also how the package management system handles configuration files. However since you didn't tell us what distro this was we don't know if that is relevant let alone be in a position to make suggestions.

Where you should be STARTING when trying to address this problem is by creating comprehensive lists of what user accounts need access to what files (before considering where those files are located) and working out an appropriate permissions model.

Certainly, it is HIGHLY unlikely that it would appropriate to store any scripts or content under /usr

+ 5

Rich_F

2/28/24, 4:21 PM

`nginx` has a minimum of two users, `root` and `nginx`. As posted, I also need access for scripting and logs. It's not really vague. Your answer was vague as you didn't read the specifics of the question. There's no blame, just a question. It is `Almalinux`, but the general `linux` filesystem, also posted, has confusing documentation as to what would suffice. Even with the list you mention, it's still not clear. Technical documentation has a reputation of being bad.

symcbean

2/28/24, 8:28 PM

You are still describing what came out of the box instead of the problem you need to solve. A permissions model with only "root" and "nginx" is a bad model.

Rich_F

2/28/24, 8:33 PM

That's all in the question. Those two users are absolutely standard with any deployment with `nginx`, not my doing. On top of that, I also have my needs. Please refer to the answer that directly addressed the question.

symcbean

2/28/24, 8:58 PM

Still: what came out of the box. Not the problem you are trying to solve. Software is a TOOL not a SOLUTION.

Rich_F

2/28/24, 9:02 PM

This SE forum is about servers. The problem I'm trying to solve is what part of the server I should put my files into. It's pretty evident I should be asking in here. Servers are not hardware alone.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Best Path for nginx Files

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.