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.
The expression should check if the actually used nginx package
needes write+execute rights, not the default pkgs.nginx (which
has no modules unless overridden in an overlay).
Having MemoryDenyWriteExecute always true causes e.g. the Lua
module to fail (because JIT compilation).
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
nginx -t not only verifies configuration, but also creates (and chowns)
files. When the `nginx-config-reload` service is used, this can cause
directories to be chowned to `root`, causing nginx to fail.
This moves the nginx -t command into a second ExecReload command, which
runs as nginx's user. While fixing above issue, this will also cause the
configuration to be verified when running `systemctl reload nginx`, not
only when restarting the dummy `nginx-config-reload` unit. The latter is
mostly a workaround for missing features in our activation script
anyways.
After the recent rewrite, enabled extensions are passed to php programs
through an extra ini file by a wrapper. Since httpd uses shared module
instead of program, the wrapper did not affect it and no extensions
other than built-ins were loaded.
To fix this, we are passing the extension config another way – by adding it
to the service's generated config.
For now we are hardcoding the path to the ini file. It would be nice to add
the path to the passthru and use that once the PHP expression settles down.
This commit:
1. Updates the path of the traefik package, so that the out output is
used.
2. Adapts the configuration settings and options to Traefik v2.
3. Formats the NixOS traefik service using nixfmt.
After upgrading to NixOS 20.03, I've got the following warning:
nginx: [warn] could not build optimal types_hash, you should increase either types_hash_max_size: 2048 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
The documentation states that "if nginx emits the message requesting
to increase either hash max size or hash bucket size then the first
parameter should first be increased" (aka types_hash_max_size).
In 19.03, the size of mime.types was around 100 entries. In 20.03, we
are around 900 entries. This is due to ff0148d868 which makes nginx
use mailcap mime.types.
In ff0148d868, nginx configuration was modified to use mime.types
from mailcap package as it is more complete. However, there are two
places where mime.types is included in configuration. When the user
was setting `cfg.httpConfig`, the mime.types from nginx was still
used. This commit fix that by moving the common snippet in a variable
of its own and ensure it is used at both places.
This replaces some hardcoded values in nginx's VirtualHosts's
configuration with customizable options. Previous values are kept as
default, so nothing should break for existing users.
Co-Authored-By: Florian Klink <flokli@flokli.de>
The commit b0bbacb521 was a bit too fast
It did set executable bit for log files.
Also, it didn't account for other directories in state dir:
```
# ls -la /var/spool/nginx/
total 32
drwxr-x--- 8 nginx nginx 4096 Dec 26 12:00 .
drwxr-xr-x 4 root root 4096 Oct 10 20:24 ..
drwx------ 2 root root 4096 Oct 10 20:24 client_body_temp
drwx------ 2 root root 4096 Oct 10 20:24 fastcgi_temp
drwxr-x--- 2 nginx nginx 4096 Dec 26 12:00 logs
drwx------ 2 root root 4096 Oct 10 20:24 proxy_temp
drwx------ 2 root root 4096 Oct 10 20:24 scgi_temp
drwx------ 2 root root 4096 Oct 10 20:24 uwsgi_temp
```
With proposed change, only ownership is changed for state files, and mode is left as is
except that statedir/logs is now group accessible.
This change brings pre-existing installations (where the logfiles
are owned by root) in line with the new permssions (where logfiles
are owned by the nginx user)
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
