I spent 15 years in webhosting and I've literally never seen /srv used. MAYBE for sftp and I'm misremembering but I rarely had to deal with that. It's always /var/www/$url.
I use /srv for a personal webserver just because I need the webserver data to be on a separate partition for disk space reasons, and it's convenient to have systemd-gpt-auto-generator automatically mount a partition to /srv without any fstab / crypttab / mount unit configuration. ("Server data partition" in https://uapi-group.org/specifications/specs/discoverable_par... )
One reason to place static files and cgi-bin executables in /var/www instead of /home/user homedir is: /var/www it's already labeled httpd_sys_content_t or httpd_sys_script_exec_t or instead of user_home_t (so that you don't need to `setsebool httpd_enable_homedirs on` for all users and `chcon httpd_user_content_t` if it's not necessary).
> In reality, larger software projects like nginx and apache have their own opinions and usually serve out of different places.
It might make sense if the software is serving a domain from something installed with a package. Nginx is often installed with a package and long-lived data goes into /var. So it makes sense to serve /var/www for their examples. Then people just build on those examples, sadly being unaware of or unwilling to change to values that were preinstalled for demonstrations.
But for multi-homing a server (or even a single site on that server), I still end up putting stuff under /srv/<domain>/<site>, so example might be /srv/systemd.software/www [0]. Then `/srv/<domain>` might have its own fstab entry -- for example, it might be a bind-mount to somewhere else, or it might be its own disk/encryption, or it might be a network mount.
Any admin can do what they want on their own servers. I just figure it's best to follow documented standards.
It's a nice thought, but most distros poop all over FHS anyway.
When was the last time you hopped between distros Ubuntu->OpenSUSE->Fedora and had packages be in the same spot? Because I distro hop a LOT and they almost NEVER are.
Even if it's just /bin, /sbin, /usr/sbin, /usr/local/bin, where is the consistency, not to mention controlling access. Remember when Debian took the sbins out of the path and everybody claimed Debian sucked?
When was the last time you saw /usr mounted as read-only? Because it's supposed to be.
With tech like snaps and flatpaks, containers, NixOS, etc, to call FHS anything more than a suggestion in 2023 is extreme wishful thinking.
I've always loved that to do basic auth nginx has you make an apache2 directory and place your htpasswd in there as a best practice/recommended setup. And use apache-utils.. but I guess why reinvent the wheel.
Its overly engineered for sure, but i designed an HTAuth setup that doesnt use files, for openresty. Instead it uses lua and a database (mysql in my case) to manage users and passwords.
Overengineered, but i dont have to muck with auth files, and can keep it up to date from other sources
This is probably more ancient documentation for switchers from Apache.
The main reason for this is to make sure your htaccess file is outside of the document root. This is horrible behavior Apache had (still has?), and is a security issue.
The Apache httpd documentation has been telling people not to use .htaccess files for over twenty years.
> However, in general, use of .htaccess files should be avoided when possible. Any configuration that you would consider putting in a .htaccess file, can just as effectively be made in a <Directory> section in your main server configuration file.