Account for the fact that, when creating a lua package without the
"withPackages" helper, we dont get an extra "lua" attribute in the
package.
Therefore we need to distinguish between the "withPackages" case and the
direct ( or "empty" ) lua package.
For example with this nixos config:
```nix
{
services.httpd = {
enable = true;
package = pkgs.apacheHttpd.override {
luaSupport = true;
lua5 = pkgs.lua5_3.withPackages (ps: with ps; [ luafilesystem ] );
};
};
}
```
Here we say that we want to have apache to use a lua, packaged with the
`luafilesystem` module so that we can `require` that in scripts to
render http responses. There, the set that gets assigned to `lua5 ` does
not have a `luaversion` attribute, rather it has a `lua` attribute
wherein lies a `luaversion` attribute. If we dont package additional
modules, then we dont have that `lua` attribute in between and rather
directly have to use `luaversion` directly.
The built-in default for unknown MIME-Types is `text/plain` whereas the
upstream default config changes it to `application/octet-stream`. By
changing the default tpye, unknown files will be downloaded by browsers
instead of being displayed.
By default in Nginx, if you want to override a single fastcgi_param,
you have to override all of them. This is less of a big deal if
you're editing the Nginx configuration directly, but when you're
generating the Nginx configuration with Nix it can be very annoying to
bloat your configuration repeating the default values of FastCGI
parameters every time.
This patch adds a fastcgiParams option to Nginx locations. If any
parameters are set through this, all the default values will be
included as well, so only the ones that are changing need to be
supplied. There's no way to use fastcgiParams to actually override
all parameters if that's what you want, but I think that's a niche use
case and it's still possible using extraConfig, which up until now was
the only option
Nginx allows the fastcgi_param directive in http and server scopes as
well as location, but here I only support location. It would be
possible to support the others, but I don't think it's worth it. It
would be a possible future enhancement if somebody has a need for it.
Unfortunately, I had a use-case where `services.nginx.config` was
necessary quite recently. While working on that config I had to look up
the module's code to understand which options can be used and which
don't.
To slightly improve the situation, I changed the documentation like
this:
* Added `types.str` as type since `config` is not mergeable on purpose.
It must be a string as it's rendered verbatim into `nginx.conf` and if
the type is `unspecified`, it can be confused with RFC42-like options.
* Mention which config options that don't generate config in
`nginx.conf` are NOT mutually exclusive.
These were broken since 2016:
f0367da7d1
since StartLimitIntervalSec got moved into [Unit] from [Service].
StartLimitBurst has also been moved accordingly, so let's fix that one
too.
NixOS systems have been producing logs such as:
/nix/store/wf98r55aszi1bkmln1lvdbp7znsfr70i-unit-caddy.service/caddy.service:31:
Unknown key name 'StartLimitIntervalSec' in section 'Service', ignoring.
I have also removed some unnecessary duplication in units disabling
rate limiting since setting either interval or burst to zero disables it
(ad16158c10/src/basic/ratelimit.c (L16))
When using the Modern config from the Mozilla SSL config generator,
the `ssl_ciphers` parameter does not need to be set
as only TLSv1.3 is permitted and all of its ciphers are reasonable.
Removing the `Accept-Encoding` header breaks applications which may
produce already compressed content.
Removing this header is staded in the nginx docs but is ment as an
example, not as an recomendation.
Testing of certs failed randomly when the web server was still
returning old certs even after the reload was "complete". This was
because the reload commands send process signals and do not wait
for the worker processes to restart. This commit adds log watchers
which wait for the worker processes to be restarted.
- Use an acme user and group, allow group override only
- Use hashes to determine when certs actually need to regenerate
- Avoid running lego more than necessary
- Harden permissions
- Support "systemctl clean" for cert regeneration
- Support reuse of keys between some configuration changes
- Permissions fix services solves for previously root owned certs
- Add a note about multiple account creation and emails
- Migrate extraDomains to a list
- Deprecate user option
- Use minica for self-signed certs
- Rewrite all tests
I thought of a few more cases where things may go wrong,
and added tests to cover them. In particular, the web server
reload services were depending on the target - which stays alive,
meaning that the renewal timer wouldn't be triggering a reload
and old certs would stay on the web servers.
I encountered some problems ensuring that the reload took place
without accidently triggering it as part of the test. The sync
commands I added ended up being essential and I'm not sure why,
it seems like either node.succeed ends too early or there's an
oddity of the vm's filesystem I'm not aware of.
- Fix duplicate systemd rules on reload services
Since useACMEHost is not unique to every vhost, if one cert
was reused many times it would create duplicate entries in
${server}-config-reload.service for wants, before and
ConditionPathExists
