The nixos/caddy module is somewhat old by now
and has undergone quite some refactors.
This specific module option (originally named
`ca`) used to make a bit more sense when
Caddy did not have multiple ACME CAs as
fallback (LE & ZeroSSL) by configured by
default yet (ZeroSSL came with v2.3.0).
I also rephrased the description slightly,
to mention Caddy's automatic issuer fallback
and a note which this option maps to in the
Caddyfile, to provide a bit more context and
a more up-to-date recommendation.
Specifically that "fine-grained configuration"
section comes from a time when this module did
some custom tls/issuer config json merging
with the templated Caddyfile using `jq`.
The "The URL to the ACME CA's directory"
section is a word-for-word copy from the
official Caddy docs, which also include a link
to LE's docs to the referenced staging
endpoint. So I added that as well.
Since ddclient@24ba945 (v3.10.0), the type and meaning of the "ipv6"
option has changed. This resulted in the following warning when
starting the service:
WARNING: file /run/ddclient/ddclient.conf, line 13:
Invalid Value for keyword 'ipv6' = 'no'
This therefore removes the matching boolean option.
More advanced configurations can use the "extraConfig" option instead.
As with many things, we have scenarios where we don't want to boot on a
disk / bootloader and also we don't want to boot directly.
Sometimes, we want to boot through an OptionROM of our NIC, e.g. netboot
scenarios or let the firmware decide something, e.g. UEFI PXE (or even
UEFI OptionROM!).
This is composed of:
- `directBoot.enable`: whether to direct boot or not
- `directBoot.initrd`: enable overriding the
`config.system.build.initialRamdisk` defaults, useful for
netbootRamdisk for example.
This makes it possible.
This essentially backports
https://github.com/systemd/systemd/pull/27791. `systemd-networkd.service`
is sent the `SIGTERM` signal, but it is not required to be stopped
before `initrd-switch-root.target` is reached, despite the use of
`systemctl isolate initrd-switch-root.target`. This is because when
there is no ordering at all between two units, and a transaction stops
one and starts the other, the two operations can happen
simultaneously. This means the service could still be running when
`switch-root` actually occurs. Then, stage 2 systemd will see the
service still running and decide it doesn't need to add a start
operation for it to its initial transaction. Finally, the service
exits, but only after it's already too late. If, however, there is any
ordering at all between a stopping unit and a starting unit, then the
stop operation will be done first. This way, we ensure that the
service is properly exited before doing `switch-root`.
This is something to keep in mind going forward. There may be other
services that need this treatment. These `before` and `conflicts`
definitions are the correct way to ensure a unit is actually stopped
before you reach initrd-switch-root
GL was already participially disabled because X11 is disabled and lead to
the following error when building gst-plguins-good:
```
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency gstreamer-gl-prototypes-1.0 found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency gstreamer-gl-prototypes-1.0
meson.build:328:2: ERROR: Neither a subproject directory nor a gst-plugins-base.wrap file was found.
```
not using this any more, and really don't have the energy to deal with
neither the fallout of ubnt not officially supporting mongodb newer than
3.6, nor the hacks nixpkgs contains to work around that.
Since 816614bd62, the service is set to use the exim user so that
systemd takes care of the credentials ownership. The executable is
still required to run as root, to then drop privileges. The prefix '+'
that was used however interfers with the use of privilege restrictions
and other sandboxing options. Since we only want to escape the "User"
setting, we can use the '!' prefix instead.
Without the change non-default configs like:
fonts.fontconfig.subpixel.rgba = "rgb"
fail to build the system as:
fontconfig-conf> ln: failed to create symbolic link 'dst/': No such file or directory
Support for gitlab-container-registry has been added in 014816cbe4.
However, when enabling the registry it will throw an error as it can't
find a `package` attribute.
This commit fixes the registry configuration by adding the missing
`registry` part.
fontconfig before version 2.13.1 was apparently implicitly not using
subpixel antialiasing. The fontconfig NixOS module deviated from this,
using subpixel antialiasing with `rgb` layout by default. In fontconfig
2.14.1, subpixel antialiasing was inadvertently enabled as the default:
2b6afa02ab
According to https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/337,
that deviates from GNOME/GTK’s defaults, which resulted in apps taking the
settings directly from fontconfig (e.g. Firefox) from diverging from GNOME
programs.
The change was subsequently reverted in 2.14.2, choosing the greyscale
antialiasing explicitly: 030759b74f
Let’s reflect this default setting in the NixOS module.
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
`sub-pixel` has been enabled by default since 2.14.1: 2b6afa02ab
`antialias` since 2.14.1: 0825a178e8
`lcdfilter` since 2.13.95: e1c7c6d744
`hintstyle` since 2.12.1: 98434b3392
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
Support for external container registries (namely
`pkgs.docker-distribution`) has ended in GitLab 16.0 [1] and is
scheduled for removal in a future release. [2]
This commit adds a new registry package option, defaulting to
`pkgs.docker-distribution` and `pkgs.gitlab-container-registry` for
system state versions >= 23.11.
While it is still possible to use the docker container registry, module
users should switch to gitlab's container registry fork soon. A warning
message will be added in a future commit to advise affected users to
back up their state and then switch to the new container registry
package.
[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/376217
[2]: https://gitlab.com/gitlab-org/gitlab/-/issues/403322
From my understanding, procps was added to the gitlay systemd service
path in #58487 to fix gitaly-ruby's internal memory leak detection.
Now that the last ruby remnants have been removed in gitaly 16.0.0,
this should not be necessary anymore.
The pufferpanel module (#225274) was merged shortly after the tree-wide
rename f63a12f296 (#225748), so the use of
deperecated buildFHSUserEnv in the docs slipped through review 😅
There is apparently a bug in the parser of iproute2 where the command
`ip link show <devname>` will not show the device but list all
interfaces (equivalent to `ip link show`) if devname is equal to one of
the flags of `ip-address(8)`. For example, `home`, or `optimistic`.
This bug causes a false positive in the clean up command of the
<devname>-netdev.service, the service fails and the interface is never
configured.
To avoid the bug we can simply use `ip link show dev <devname>`.
PROXY protocol is a convenient way to carry information about the
originating address/port of a TCP connection across multiple layers of
proxies/NAT, etc.
Currently, it is possible to make use of it in NGINX's NixOS module, but
is painful when we want to enable it "globally".
Technically, this is achieved by reworking the defaultListen options and
the objective is to have a coherent way to specify default listeners in
the current API design.
See `mkDefaultListenVhost` and `defaultListen` for the details.
It adds a safeguard against running a NGINX with no HTTP listeners (e.g.
only PROXY listeners) while asking for ACME certificates over HTTP-01.
An interesting usecase of PROXY protocol is to enable seamless IPv4 to
IPv6 proxy with origin IPv4 address for IPv6-only NGINX servers, it is
demonstrated how to achieve this in the tests, using sniproxy.
Finally, the tests covers:
- NGINX `defaultListen` mechanisms are not broken by these changes;
- NGINX PROXY protocol listeners are working in a final usecase
(sniproxy);
- uses snakeoil TLS certs from ACME setup with wildcard certificates;
In the future, it is desirable to spoof-attack NGINX in this scenario to
ascertain that `set_real_ip_from` and all the layers are working as
intended and preventing any user from setting their origin IP address to
any arbitrary, opening up the NixOS module to bad™ vulnerabilities.
For now, it is quite hard to achieve while being minimalistic about the
tests dependencies.
It appears that newer mautrix-facebook versions default to the appservice name `facebook`. This was breaking our registration and causing mautrix-facebook to fail to start. This changes the name back and makes the registration generated match whatever the setting in the app is.
Adds a new option to the virtualisation modules that enables specifying explicitly named network interfaces in QEMU VMs.
The existing `virtualisation.vlans` option is still supported for cases where the name of the network interface is irrelevant.
