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
The mime type definitions included with nginx are very incomplete, so
we use a list of mime types from the mailcap package, which is also
used by most other Linux distributions by default.
Quoting from the splitString docstring:
NOTE: this function is not performant and should never be used.
This replaces trivial uses of splitString for splitting version
strings with the (potentially builtin) splitVersion.
IE6 is long gone and this directive is not useful anymore. We can
spare a few CPU cycles (and maybe skip some bugs) by not trying to
disable gzip for MSIE6.
* nixos/acme: Fix ordering of cert requests
When subsequent certificates would be added, they would
not wake up nginx correctly due to target units only being triggered
once. We now added more fine-grained systemd dependencies to make sure
nginx always is aware of new certificates and doesn't restart too early
resulting in a crash.
Furthermore, the acme module has been refactored. Mostly to get
rid of the deprecated PermissionStartOnly systemd options which were
deprecated. Below is a summary of changes made.
* Use SERVICE_RESULT to determine status
This was added in systemd v232. we don't have to keep track
of the EXITCODE ourselves anymore.
* Add regression test for requesting mutliple domains
* Deprecate 'directory' option
We now use systemd's StateDirectory option to manage
create and permissions of the acme state directory.
* The webroot is created using a systemd.tmpfiles.rules rule
instead of the preStart script.
* Depend on certs directly
By getting rid of the target units, we make sure ordering
is correct in the case that you add new certs after already
having deployed some.
Reason it broke before: acme-certificates.target would
be in active state, and if you then add a new cert, it
would still be active and hence nginx would restart
without even requesting a new cert. Not good! We
make the dependencies more fine-grained now. this should fix that
* Remove activationDelay option
It complicated the code a lot, and is rather arbitrary. What if
your activation script takes more than activationDelay seconds?
Instead, one should use systemd dependencies to make sure some
action happens before setting the certificate live.
e.g. If you want to wait until your cert is published in DNS DANE /
TLSA, you could create a unit that blocks until it appears in DNS:
```
RequiredBy=acme-${cert}.service
After=acme-${cert}.service
ExecStart=publish-wait-for-dns-script
```
The `keys.target` is used to indicate whether all NixOps keys were
successfully uploaded on an unattended reboot. However this can cause
startup issues e.g. with NixOS containers (see #67265) and can block
boots even though this might not be needed (e.g. with a dovecot2
instance running that doesn't need any of the NixOps keys).
As described in the NixOps manual[1], dependencies to keys should be
defined like this now:
``` nix
{
systemd.services.myservice = {
after = [ "secret-key.service" ];
wants = [ "secret-key.service" ];
};
}
```
However I'd leave the issue open until it's discussed whether or not to
keep `keys.target` in `nixpkgs`.
[1] https://nixos.org/nixops/manual/#idm140737322342384
* nginx: expose generated config and allow nginx reloads
Fixes: https://github.com/NixOS/nixpkgs/issues/15906
Another try was done, but not yet merged in https://github.com/NixOS/nixpkgs/pull/24476
This add 2 new features: ability to review generated Nginx config
(and NixOS has sophisticated generation!) and reloading
of nginx on config changes. This preserves nginx restart on package
updates.
I've modified nginx test to use this new feature and check reload/restart
behavior.
* rename to enableReload
* add sleep(1) in ETag test (race condition) and rewrite rebuild-switch using `nesting.clone`
mysql already has its socket path hardcoded to to
/run/mysqld/mysqld.sock.
There's not much value in making the pidDir configurable, which also
points to /run/mysqld by default.
We only seem to use `services.mysql.pidDir` in the wordpress startup
script, to wait for mysql to boot up, but we can also simply wait on the
(hardcoded) socket location too.
A much nicer way to accomplish that would be to properly describe a
dependency on mysqld.service. This however is not easily doable, due to
how the apache-httpd module was designed.
Some ACME clients do not generate full.pem, which is the same as
fullchain.pem + the certificate key (key.pem), which is not necessary
for verifying OCSP staples.
