You couldve accomplished this at the webserver level, with way less hassle, and better performance.
One would be complex rewrite rules. Another, is to use LUA with Openresty. And you dont need another node app, and you dont need the terrible performance you get with the node app, and you dont use a language meant for frontend things to do backend things.
Seriously, what is it with every node dev using node for everything???? Yes, i know when all you know is a hammer, everything is a nail, but seriously, come on. There are plenty of better languages to have done this in, all of which are more performant for this type of thing, had you still decided to not use lua/rewrites.
> You couldve accomplished this at the webserver level
That's true, but only if you have access to your web server!
If you're using something like Vercel (or some other hosting service) to run your application, having a little middleware that handles subdomain routing is pretty common.
edit: Sorry if I've read this comment out of context - the linked repo has been taken down.
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.
you can choose any directory you want and while FHS is a recommendation there's no one forcing you to use it.
Note that more often than not I'll often argue for sticking with FHS and it's a good rule of thumb to know the rules first before you go breaking them. However in my opinion /srv isn't a pragmatic choice to make in a demonstration and it's for the sake of clarity I can see why the writer would just say /websites. In your own implementation you can put your content wherever you want.
A relevant sidenote: If you're going to do this, make sure you don't allow the content to also be accessible on the top level domain with a different URL, and that one redirects to the other. Two reasons for this:
- Security: You want the cookies to be limited to the subdomain
- SEO: You get penalized if the same content is available at two URLs, because it is assumed it's a copy
The SEO issue applies in the other direction too. When we first set this up for reddit (you could and still can go to subreddit.reddit.com), we found out that we were getting penalized for having the same content on both URLs. So we set it up to redirect the subdomain to the /r/subreddit URL since that was the canonical URL and the cookies didn't matter.
Possibly I am missing something, but is it different from, say, nginx's `root /var/www/$http_host`? The description sounds as if a whole web server is written for that feature.
ha, 1) nginx is a webserver not a development ecosystem, and 2) You'll probably find if you look that many people using Node are also using nginx, because they are complementary, not exclusionary, and 3) open your eyes and reality a bit
Man there is a lot of negativity here, some people really need to reread the guidelines.
Good on you. As a sysadmin of decades I could absolutely to this in a few lines of nginx or other web servers as others have mentioned, however this looks like a cool and fun project.
Just because doing it one way wins on some specific metrics (like performance) doesn't mean it does for other people (like node developers who want to change some server functionality).
I can't believe people can write with a straight face that a web dev should learn nginx, set up openresty and write a lua script to do this. Get out of your own bubbles people.
I think Node.js is unsuitable for normal routing tasks like this because of single-threaded runtime. This could be achieved really easily with popular web servers like nginx or caddy. If I remember correctly, there was a lot of tutorial about serving static files using nginx in front of express.js/koa.js for better performance and that serving static files doesn't compete with the dynamic part of the website.
Would it make it much easier? If you really need env var support, you can just wrap this, I suppose. But more conveniently, you can also mount (and load from a config map in the context of kubernetes).
Yes, I think that env vars are superior to a file or CLI args. One advantage is that you can pass secrets without persisting in a file or making them visible to other processes through CLI args.
Env vars are visible in /proc/PID/environ, though? That said, the mode on environ seems to be 600 on my system, so only processes with the same UID can see them.
Does that mean you're restarting your nodes after every change? It'll work, but mightn't it be a bit tricky if lots of people start creating tenants?
Edit: actually, based on the use case cited in the readme, this would be fine. I was thinking more of a website like GitHub that lets people sign up and create tenants.
One would be complex rewrite rules. Another, is to use LUA with Openresty. And you dont need another node app, and you dont need the terrible performance you get with the node app, and you dont use a language meant for frontend things to do backend things.
Seriously, what is it with every node dev using node for everything???? Yes, i know when all you know is a hammer, everything is a nail, but seriously, come on. There are plenty of better languages to have done this in, all of which are more performant for this type of thing, had you still decided to not use lua/rewrites.