Empty parantheses are not supported in regular expressions on
Darwin/macOS. The old regular expression produces an error during
evaluation. This commit fixes that.
Nix‘s `builtins.match` works with extend POSIX regular expressions. The
specification for these regular expression states[^1] that the result
for a left paranthesis immediately followed by a right paranthesis
outside of a bracket expression is undefined.
[^1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04_03
Since release 1.18.4, the ModemManager daemon no longer automatically
performs the FCC unlock procedure by default. The user must, under their
own responsibility, enable the automatic FCC unlock as shipped by
ModemManager.
Add a new type, inheriting 'types.str' but checking whether the value
doesn't contain any newline characters.
The motivation comes from a problem with the
'users.users.${u}.openssh.authorizedKeys' option.
It is easy to unintentionally insert a newline character at the end of a
string, or even in the middle, for example:
restricted_ssh_keys = command: keys:
let
prefix = ''
command="${command}",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding
'';
in map (key: "${prefix} ${key}") keys;
The 'prefix' string ends with a newline, which ends up in the middle of
a key entry after a few manipulations.
This is problematic because the key file is built by concatenating all
the keys with 'concatStringsSep "\n"', with result in two entries for
the faulty key:
''
command="...",options...
MY_KEY
''
This is hard to debug and might be dangerous. This is now caught at
build time.
network.target is reached earlier, but with much fewer services
available. DNS is likely to be not functional before
network-online.target, so waiting for that seems better for that reason
alone. the existing backends for network-online.target all seem to do
reasonable things (wait until all links are in *some* stable state), so
we shouldn't lose anything from waiting.
Still actively developed and yet stuck on python2. Also marked as
vulnerable and their issue tracker contains yet another security issue
reported in 2021/10 that the upstream hasn't acknowledged yet.
Mind blown.
Closes: #135543, #97274, #97275
It turns out it's actually possible to fall back to WPA2 in case the
authentication fails with WPA3. This was suggested to me in the hostapd
mailing list: add another network block with only WPA2 and lower
priority, for each network with WPA3. For clients with missing/broken
WPA3, wpa_supplicant will:
1. try the network block with higher priority first
2. fail and temporarily disable the network block
3. try the fallback network block and connect
This takes a little more time (still <5s) because wpa_supplicant
retries a couple times before disabling the network block, but it allows
old client to gracefully fall back to WPA2 on mixed WPA2/WPA3 networks.
To avoid downgrade attacks, clients with proper WPA3 should disable
this; in the future we may want to disable this option by default.
This is a useful utility for monitoring network performance over time
using a combination of MTR and Prometheus. Also adding a service definition.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Alternative solution to PR #152443.
This fixes authentication failures to WPA3 networks (issue #151729)
by enabling protected management frames.
Note: old client without 802.11w support will still fail.
When startWhenNeeded is enabled, a brute force attack on sshd will cause
systemd to shut down the socket, locking out all SSH access to the machine.
Setting TriggerLimitIntervalSec to 0 disables this behavior.
This never configured where SNI should log to, as it's up to the user to
provide the full sniproxy config (which can be configured to log to a
file).
This option only produced a ExecStartPre script that created the folder.
Let's use LogsDirectory to create it. In case users want to use another
directory for logs, they can override LogsDirectory or set their own
ExecStartPre script.
The systemd syntax is suprising to me, but I suppose it's worth being
compatible as people might be sharing it with other modules.
Our regexp is lenient on IPv6 address part, so this is actually
backwards compatible (i.e. you can put the scope at either place).
dhcpcd does not run properly with some of the hardened system mallocs
that are currently available. assert when an incompatible configuration
is detected, as a switch into such a config from eg auto-update can take
hosts offline.
link to search.nixos.org instead of pulling package metadata out of pkgs. this
lets us cache docs of a few more modules and provides easier access to package
info from the HTML manual, but makes the manpage slightly less useful since
package description are no longer rendered.
most modules can be evaluated for their documentation in a very
restricted environment that doesn't include all of nixpkgs. this
evaluation can then be cached and reused for subsequent builds, merging
only documentation that has changed into the cached set. since nixos
ships with a large number of modules of which only a few are used in any
given config this can save evaluation a huge percentage of nixos
options available in any given config.
in tests of this caching, despite having to copy most of nixos/, saves
about 80% of the time needed to build the system manual, or about two
second on the machine used for testing. build time for a full system
config shrank from 9.4s to 7.4s, while turning documentation off
entirely shortened the build to 7.1s.
Sometimes it is preferable to configure forwarding only for bind
instead of relying on direct lookups.
This patch makes it possible to configure the forward setting to
either "first" (the default) or "only".
This commit introduces `services.adguardhome.settings` and
`services.adguardhome.mutableSettings`.
The first option allows declarative configuration of
AdGuard Home, while the second one controls whether changes
made in the web interface are kept between service restarts.
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
Fix a typo in the kea-dhcp-ddns-server unit definition, and add a
KEA_LOCKFILE_DIR environment variable without which kea daemons try to
access a lockfile under /var/run/kea path, which is prevented by
systemd's ProtectSystem (or one of the other Protect*) mechanism.
kea-dhcp-ddns-server doesn't react to updates from dhcp4 server at all
without it.
- Added defaultText for all inheritable options.
- Add docs on using new defaults option to configure
DNS validation for all domains.
- Update DNS docs to show using a service to configure
rfc2136 instead of manual steps.
openFirewall is the much more common name for an option with this
effect. since the default was `true` all along, renaming it doesn't hurt
much and only improves consistency with other modules.
some options have default that are best described in prose, such as
defaults that depend on the system stateVersion, defaults that are
derivations specific to the surrounding context, or those where the
expression is much longer and harder to understand than a simple text
snippet.
escape interpolations in descriptions where possible, replace them with
sufficiently descriptive text elsewhere. also expand cfg.* paths in
descriptions.
This reverts commit 6af3d13bec.
Reported by @arcnmx
(https://github.com/NixOS/nixpkgs/pull/148179#issuecomment-987197656):
Does this not completely break the service? It doesn't change the
owner to the same as the ddclient server (which is somewhat difficult
due to it being a DynamicUser), so this now makes the service
completely unusable because the config is only readable by its owner,
root:
ddclient[871397]: WARNING: file /run/ddclient/ddclient.conf: Cannot open file '/run/ddclient/ddclient.conf'. (Permission denied)
Given that the RuntimeDirectory was only readable by the ddclient
service, the warning this PR fixes was spurious and not indicative of
an actual information leak. I'm not sure of what a quick fix would be
due to DynamicUser, but would at least request a revert of this so the
service can work again?
dhdpcd 9 support privilege separation with a dedicated user and seccomp
filtering. this has been enabled for a while in other distributions as
well.
if the dhcpcd module is not used and the _dhcpcd user/group isn't
definied otherwise dhcpcd will fall back to not using privsep.
by @erictapen:
- Removed note about testing and moved it to passthru.tests
- Removed patch, as it is probably the same as
56b2bb17d2ec67e1f93950944211f6cf8c40e0fb, wich landed in upstream.
other changes:
- changed PIDFile in the module, since dhcpcd 9 changed the location
this setting was added in 2016 in commit
bcdd81d9e1
the posibility to preferTempAddress was added to
nixos/network-interface in 2018 in commit
1fec496f38
preferTempAddress was renamed to tempAddress
in 2020 in commit 2485e6399e
therefore this setting is redundant since nm will use the sysctl option
nixos/network-interfaces: add default to sysctl so that the value for it
is set
networkmanager falls back to it
https://man.archlinux.org/man/NetworkManager.conf.5
Use service internal bind mounts instead of global ones.
This also moves the logs to /var/log/unifi on the host
and the run directory to /run/unifi.
Closes#61424
Details on https://github.com/NixOS/nixops/issues/1063#issuecomment-453253666.
`partOf` makes that if `smokeping.service` is stopped, `thttpd.service` will
be stopped as well.
(But not that `thttpd` will be started when `smokeping` is started).
Once `thttpd.service` is stopped that way, `Restart = always` will not apply.
When the smokeping config options are changed, NixOS's `switch-configuration.pl`
will stop `smokeping` (whit shuts down thttpd due to `partOf`), and then restart
smokeping; but this does not start thttpd.
As a result, thttpd will be off after changing the config, which isn't desired.
This commit fixes it by removing the `partOf`, which makes `Restart` work
as expected.
This avoids a common problem:
Until now, port forwarding to multiple hosts running smokeping did not work;
they all show the data of the first smokeping instance.
That ws because the image URLs generated by smokeping are absolute
(`imgurl` setting).
Consequently, if you ran
ssh node-1 -L 8081:localhost:8081
ssh node-2 -L 8081:localhost:8082
ssh node-3 -L 8081:localhost:8083
and try to open http://localhost:8081, http://localhost:8082 and
http://localhost:8083, they all would show the images of node-1!
Using a relative `imgurl` fixes that.
As per smokeping docs on `imgurl`:
> Either an absolute URL to the `imgcache` directory or one relative to the
> directory where you keep the SmokePing cgi.
