This reverts commit a8b8f8f8c7.
It introduced a failure in the syncthing service, where it hangs at the
curl step, repeatedly printing this:
l3ijkvb20h5nnffg5q25i4nmcsbf7glx-merge-syncthing-config[1458]: curl: (22) The requested URL returned error: 404
l3ijkvb20h5nnffg5q25i4nmcsbf7glx-merge-syncthing-config[1458]: curl: (22) The requested URL returned error: 404
l3ijkvb20h5nnffg5q25i4nmcsbf7glx-merge-syncthing-config[1458]: curl: (22) The requested URL returned error: 404
[...]
This is unfortunately not detected by `nix-build -A syncthing.tests`.
Ref https://github.com/NixOS/nixpkgs/pull/390742
Add the options:
- lighthouse.serve_dns
- lighthouse.dns.host
- lighthouse.dns.port
Improve systemd capabilities handling:
- do not give CAP_NET_ADMIN when tunnel interface is disabled
- give CAP_NET_BIND_SERVICE when DNS is enabled
Add self as maintainer: I'm using Nebula on NixOS in prod.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
This is needed since clatd will use networkctl to attempt to obtain the
PLAT prefix, and networkctl uses UNIX domain sockets to communicate with
the systemd-networkd daemon over DBus.
Previously, this option was supposed to be a file of the form
`CLOUDFLARE_API_TOKEN=...`, which has a few problems:
- That's not an api token. It's an env file fit for passing to systemd's
`EnvironmentFile` option. The user could typo the variable name, or
intentionally/unintentionally include unrelated environment variables.
- It's not how secret files usually work in NixOS. Secret files are
usually just the secret, and don't leak details about how the secret
is passed to the service.
- This increases friction for people switching between cloudflare dyndns
services, such as `services.cloudflare-dyndns` and
`services.cfdyndns`, which both have a `apiToken` option, but (before
this change) with different semantics.
In afeb76d628, sshd.service and
sshd@.service were switched to Type=notify. This apparently works for
sshd.service, but not for sshd@.service. Given that the reason for
this working with sshd.service isn't exactly clear, let's revert it
for both of them for now, and revisit Type=notify later.
While it is probably a mistake in configuration to have declarative
routes configured but no certificate file, it is not always necessary to
have a working set up, so the assertion was removed.
The documentation for the certificateFile setting was reworked to
describe this.
Previously some modules used `config.environment.etc."ssl/certs/ca-certificates.crt".source`, some used `"/etc/ssl/certs/ca-certificates.crt"`, and some used `"${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"`. These were all bad in one way or another:
- `config.environment.etc."ssl/certs/ca-certificates.crt".source` relies on `source` being set; if `text` is set instead this breaks, introducing a weird undocumented requirement
- `"/etc/ssl/certs/ca-certificates.crt"` is probably okay but very un-nix. It's a magic string, and the path doesn't change when the file changes (and so you can't trigger service reloads, for example, when the contents change in a new system activation)
- `"${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"` silently doesn't include the options from `security.pki`
Co-authored-by: Shelvacu <git@shelvacu.com>
Make the cloudflared tunnel service use systemd credentials and dynamic
users, removing the services.cloudflared.user and .group option.
Also add an option to provide the cert.pem file, without which tunnels
defined declaratively would not work.
Additionally, add an assertion checking that the certificate file is
provided if there are declarative routes defined.
`mlkem768x25519-sha256` and the vendor-neutral `sntrup761x25519-sha512`
name are new in OpenSSH 9.9 <https://www.openssh.com/txt/release-9.9>
Co-authored-by: Mynacol <Mynacol@users.noreply.github.com>
This is done in view of the Release of the new v3 of Bird.
Switch to the bird3 package for the `services.bird.package` option.
Switch the `bird` package alias to bird3.
...and `escapeShellArgs` for spool area program command lines.
The new function `mkSpoolCmd` adds the `-q` option
by default as it is needed by all such programs.
This adds a simple hardened systemd-based module for g3proxy, a generic
purpose forward proxy.
Change-Id: I8c6e5d2cc8a9faa2aea8c5df3af56756ffed542d
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Co-authored-by: Elias Coppens <elias.coppens@ens.fr>
When I initially tested this, the upstream seemed a good idea and worked
as expected but it no longer does and disconnects clients every 60
seconds indicated by the following line in tailscaled on the client:
magicsock: [0xc00444a640] derp.Recv(derp-901): derp.Recv: EOF
By connecting directly things work more reliable and there are no
connection resets every 60 seconds anymore.
It enables passing a sops-nix secret as a `settingsFile`
@see https://github.com/Mic92/sops-nix/issues/198.
By default sops-nix secrets are accessible by only root. We can change owner to another user, but the xray service is defined with `dynamicUser=true`, which means, there is no user in the compile time.
Systemd `loadCredential` passes the secret file to the service, which is exactly what we need here.
server_url check [has been loosened upstream][1] and backported to
NixOS[2]. The new, much looser check, is not practical to be implemented
in Nix (you are welcome to give it a try; I've implemented the original
one).
Since the surface area is much smaller now (and the scenario much less
common), I think we can remove this assertion altogether.
[1]: https://github.com/juanfont/headscale/pull/2248
[2]: https://github.com/NixOS/nixpkgs/pull/358255
radicale tries to connect to the systemd unix socket for logging. This
currently fails because it is not allowed to open sockets, then it falls
back to logging to stdout (printing a warning).
Allow radical to open unix sockets to fix this. This gives slightly
better logging experience (e.g. errors are marked red when sent through
the systemd log socket).
Fix the regression between NixOS 24.05 and 24.11 where using dhcpcd
(e.g. networking.useDHCP) and systemd-resolved
(services.resolved.enable) result in no "search" entry getting added to
/etc/resolv.conf, and dhcpcd logging the following error:
$ systemctl status dhcpcd
[...] dhcpcd[2896]: Failed to set DNS configuration: Interactive authentication required.
Fix it by adding a polkit rule that gives the required permissions to
the 'dhcpcd' user to manipulate resolved. The rule was made by using
polkit logging and allowing each action.id until the above error went
away, and /etc/resolv.conf got the correct search entry.