A git command was failing in the test with
error: unable to get random bytes for temporary file: Operation not permitted
error: unable to create temporary file: Operation not permitted
error: .Radicale.lock: failed to insert into database
error: unable to index file '.Radicale.lock'
verbose is a debugging setting one step noisier than debug and should only be turned on when debugging because it leaks quite some credentials and tokens in the journalctl.
we expose it under settings instead of at the listener toplevel because
mosquitto seems to pick the addresses it will listen on
nondeterministically from the set of addresses configured on the
interface being bound to. encouraging its use by putting it into the
toplevel options for a listener seems inadvisable.
Introduced in OpenSSH 9.0 it became the part of the default kexAlgorithm
selection, visibile in sshd_config(5).
It is also enabled by default in the OpenSSH client, as can be seen from
$ ssh -Q KexAlgorithms
Also clarifies that we use the referenced documents as the lower bound,
given that they haven't been updated for 5-7y.
Tailscale uses policy routing to enable certain traffic to bypass
routes that lead into the Tailscale mesh. NixOS's reverse path
filtering setup doesn't understand the policy routing at play,
and so incorrectly interprets some of this traffic as spoofed.
Since this only breaks some features of Tailscale, merely warn
users about it, rather than make it a hard error.
Updates tailscale/tailscale#4432
Signed-off-by: David Anderson <dave@natulte.net>
For some features, tailscaled uses getent(1) to get the shell
of OS users. getent(1) is in the glibc derivation. Without this
derivation in the path, tailscale falls back to /bin/sh for all
users.
Signed-off-by: David Anderson <dave@natulte.net>
In a previous PR [1], the conditional to generate a new host key file
was changed to also include the case when the file exists, but has zero
size. This could occur when the system is uncleanly powered off shortly
after first boot.
However, ssh-keygen prompts the user before overwriting a file. For
example:
$ touch hi
$ ssh-keygen -f hi
Generating public/private rsa key pair.
hi already exists.
Overwrite (y/n)?
So, lets just try to remove the empty file (if it exists) before running
ssh-keygen.
[1] https://github.com/NixOS/nixpkgs/pull/141258
Without this, if the network goes down for a while, systemd will give up after 5 restarts:
Scheduled restart job, restart counter is at 5.
Stopped Nebula VPN service for myvpn.
nebula@myvpn.service: Start request repeated too quickly.
Failed with result 'exit-code'.
Failed to start Nebula VPN service for myvpn.
Most network services need this, but for VPNs it's extra important.
See https://blog.prosody.im/prosody-0.12.0-released for more
informations.
We remove the various lua wrappers introduced by
6799a91843 and
16d0b4a69f. It seems like we don't need
them anymore. I'm not brave enough to dig into the Lua machinery to
see what resolved that. Sorry, you'll have to trust me on that one.
We should probably think about the migration from http_upload to
http_file_share for the NixOS module. It's not trivial, we need to
make sure we don't break the already uploaded URLs.
This commit refactors the way how configuration files are deployed to
the `/etc/asterisk` directory.
The current solution builds a Nix derivation containing all config files
and symlinks it to `/etc/asterisk`. The problem with that approach is
that it is not possible to provide additional configuration that should
not be written to the Nix store, i.e. files containing credentials.
The proposed solution changes the creation of configuration files so
that each configuration file gets symlinked to `/etc/asterisk`
individually so that it becomes possible to provide additional config
files to `/etc/asterisk` as well.
This avoids the scenario where you activate a new config over Tailscale,
and a long delay between the "stop services" and "start services" phases
of the activation script lead to your terminal freezing for tens of
seconds, until tailscaled finally gets started again and the session
recovers.
Per the documentation of stopIfChanged, this is only safe to do if the
service definition is robust to stopping the old process using the new
service definition. As the maintainer of the upstream systemd unit, I
can confirm that Tailscale is robust to this scenario: it has to be
in order to work right on several other distros that just do
unpack-then-restart, rather than the more complex stop-unpack-start
dance.
Signed-off-by: David Anderson <dave@natulte.net>
