Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
subdomain-mapper-operator
This operator patches an ingress to automatically create subdomains for services based on annotations.
during which I deleted a lot of outdated github repos.
I thinks I accidently deleted this repo.
Now it is back: https://github.com/xieyuheng/x-server
Same for Caddy which is even easier than nginx https://caddyserver.com/
> 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//, so example might be /srv/systemd.software/www [0]. Then `/srv/` 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.
[0]: https://github.com/inetknght/systemd.software/blob/0bf207d6f...
I made something similar for kubernetes a while ago https://github.com/DeluxeOwl/subdomain-mapper-operator