We don't need both wget and curl, so let's use only curl (which is
part of a minimal NixOS closure, unlike wget).
Logging to the console is helpful for debugging.
Instances without SSH keys configured will receive a 404 from the
metadata server when attempting to fetch an SSH key. This is not an
actual problem though, and shouldn't result in the service failing.
If the metadata server cannot be reached, the script will fail at an
earlier stage when attempting to get authentication data.
This also removes automatic enablement/mounting of instance store swap
devices and ext3 filesystems. This behaviour is strongly opinionated
and shouldn't be enabled by default.
The unionfs behaviour never took effect anyway, because the AMI
manifest path only exists for instance store-backed AMIs, which have
not been supported by nixpkgs since
84742e2293 (2019).
The tests TLS setup was bogus: the xmpp-send-message script was trying
to connect to the server through a bogus domain name. Injecting the
right one.
I'm a bit confused about that one. I know for sure this NixOS test
succeeded last time I checked it, but the TLS conf is bogus for sure.
I assume the slixmpp SNI validation was a bit too loose and was
tightened at some point.
The xmpp-sendmessage the slixmpp-powered python script tend to timeout
and block the nixos channels.
Adding a signal-based timeout making sure that whatever happens, the
script won't run for more than 2 minutes. That should be pleinty
enough time to finish regardless of the runner specs. As a data point,
it runs in about 10 secs on my desktop machine.
The change that allows setting the secrets by an environment file had
the undocumented side effect of allowing to set any key by the environment
file (Related PR: https://github.com/tulir/mautrix-telegram/pull/332).
This is required to e.g. set `bridge.login_shared_secret`, which was not
documented before.
GitHub: closes#103347
Closes#198646
* The options `password`/`basicAuthPassword` were removed for
datasources in Grafana 9. The only option to declare them now is to use
`secureJsonData`.
* Fix description for contactPoints provisioning: when using file/env
providers, nothing will be leaked into the store.
* Fix regex in file-provider usage check: it's also possible to either
use `$__env{FOO}` or `$FOO` to fetch secrets from the environment.
* Fix warning for datasources: `password`/`basicAuthPassword` was
removed, also check for each setting in `secureJsonData` if
env/file-provider was used (then no warning is needed!).
The hack with `either` had the side-effect that the sub-options of the
submodule didn't appear in the manual. I decided to remove this because
the "migration" isn't that hard, you just need to fix some module
declarations.
However, `mkRenamedOptionModule` wouldn't work here because it'd create
a "virtual" option for the deprecated path (i.e.
`services.grafana.provision.{datasources,dashboards}`), but that's the
already a new option, i.e. the submodule for the new stuff.
To make sure that you still get errors, I implemented a small hack using
`coercedTo` which throws an error if a list is specified (as it would be
done on 22.05) which explains what to do instead to make the migration
easier.
Also, I linkified the options in the manual now to make it easier to
navigate between those.
GTK 4 applications use accessibility bus directly
and will try to connect to it every time a widget is created:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4831
This will make GTK 4 apps (e.g. newly ported Nautilus) grind
to a halt on systems that do not have AT-SPI service installed.
Let’s explicitly disable accessibility support with an environment
variable when the AT-SPI service is not enabled to avoid that.
Just like we do for ATK-based applications with `NO_AT_BRIDGE`.
Fixes: https://github.com/NixOS/nixpkgs/issues/197188
To allow for a reasonably fast deprecation of weak password hashing
schemes we provide an activation script that checks existing hashes in
/etc/shadow and issues a warning for user accounts that still rely on
deprecated hashes.
Co-Authored-By: oxalica <oxalicc@pm.me>
- Do not use `daemon`, it has been synonymous to `out` since 783c40eb68
- Do not use explicit `out` output, it has been default since a17216af4c (originally introduced in 2132c86c45)
Enabling Wayland support by default prevents use of XWayland on Wayland
systems, while correctly falling back to X11 when Wayland is
unavailable in the current session.
With the current packaging many people unnecessarily rely on the
`firefox` attribute, which is suggested by nixos-generate-config, which
in turn makes their Firefox use XWayland, when it shouldn't, which
causes bugs with GNOME on Wayland:
https://discourse.nixos.org/t/firefox-all-black-when-first-launched-after-login/21143
Using the Wayland-enabled Firefox was tested on pure X11 systems by
contributors on the #nix-mozilla:nixos.org room and we are confident
this change will not cause severe regressions.
Even better, people can now toggle `MOZ_ENABLE_WAYLAND=<0|1>` in their
environment to override this decision, should they feel the need to do
so.
This commit fixes broken non-declarative configs by
making the assertions more relaxed.
It also allows to remove the forced configuration merge by making
`settings` `null`able (now the default).
Both cases (trivial non-declarative config and `null`able config) are
verified with additional tests.
Fixes#198665
The `sparseCheckout` argument allows the user to specify directories or
patterns of files, which Git uses to filter files it should check-out.
Git expects a multi-line string on stdin ("newline-delimited list", see
`git-sparse-checkout(1)`), but within nixpkgs it is more consistent to
use a list of strings instead. The list elements are joined to a
multi-line string only before passing it to the builder script.
A deprecation warning is emitted if a (multi-line) string is passed to
`sparseCheckout`, but for the time being it is still accepted.
Version 251.6 of systemd introduced a small change[1] that now checks
whether the fsck command is available in *addition* to the filesystem
specific fsck.$fsname executable.
When bumping systemd to version 251.7 on our side[2], we introduced that
change. This subsequently caused our "fsck" test to fail and it looks
like this was an oversight during the pull request[3] introducing the
bump.
Since the fsck wrapper binary is in util-linux, I decided to address
this by adding util-linux to fsPackages because util-linux is already
part of the closure of any NixOS system so the impact should be pretty
low.
[1]: 73db7d9932
[2]: 844a08cc06
[3]: https://github.com/NixOS/nixpkgs/pull/199618
Signed-off-by: aszlig <aszlig@nix.build>
The nixos-generate-config command mentioned in the manual fails with error:
nixos-generate-config: no need to specify `/` with `--root`, it is the default
This was introduced in 611b8c4472
(#161034). Now, the command should be called without any arguments.
Relative paths are interpreted relative to the working directory, which
is currently unset and thus defaults to `/`. However we want to change
the working directory in a future release such that relative paths are
interpreted relative to `/var/lib/syncthing`.
Currently, we build `man-cache` with `runCommandLocal`, which causes it
to get re-built locally instead of fetched from cache. While the
resulting derivation might be small, it does take a fair bit of time to
build for all my systems, and would be _far_ quicker to fetch.
With this change, we use `runCommand` instead of `runCommandLocal`,
allowing it to get fetched from cache instead of rebuilt for all hosts.
fscrypt can automatically unlock directories with the user's login
password. To do this it ships a PAM module which reads the user's
password and loads the respective keys into the user's kernel keyring.
Significant inspiration was taken from the ecryptfs implementation.
Upon testing the change itself I realized that it doesn't build properly
because
* the `pname` of a php extension is `php-<name>`, not `<name>`.
* calling the extension `openssl-legacy` resulted in PHP trying to compile
`ext/openssl-legacy` which broke since it doesn't exist:
source root is php-8.1.12
setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c
patching sources
cdToExtensionRootPhase
/nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory
I didn't encounter that one before because I was mostly interested in
having a sane behavior for everyone not using this "feature" and the
documentation around this. My findings about the behavior with turning
openssl1.1 on/off are still valid because I tested this on `master` with
manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`.
To work around the issue I had to slightly modify the extension
build-system for PHP:
* The attribute `extensionName` is now relevant to determine the output
paths (e.g. `lib/openssl.so`). This is not a behavioral change for
existing extensions because then `extensionName==name`.
However when specifying `extName` in `php-packages.nix` this value is
overridden and it is made sure that the extension called `extName` NOT
`name` (i.e. `openssl` vs `openssl-legacy`) is built and installed.
The `name` still has to be kept to keep the legacy openssl available
as `php.extensions.openssl-legacy`.
Additionally I implemented a small VM test to check the behavior with
server-side encryption:
* For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix`
it's checked that OpenSSL 3 is used). With that the "default"
behavior of the module is checked.
* It is ensured that the PHP interpreter for Nextcloud's php-fpm
actually loads the correct openssl extension.
* It is tested that (encrypted) files remain usable when (temporarily)
installing OpenSSL3 (of course then they're not decryptable, but on a
rollback that should still be possible).
Finally, a few more documentation changes:
* I also mentioned the issue in `nextcloud.xml` to make sure the issue
is at least mentioned in the manual section about Nextcloud. Not too
much detail here, but the relevant option `enableBrokenCiphersForSSE`
is referenced.
* I fixed a few minor wording issues to also give the full context
(we're talking about Nextcloud; we're talking about the PHP extension
**only**; please check if you really need this even though it's
enabled by default).
This is because I felt that sometimes it might be hard to understand
what's going on when e.g. an eval-warning appears without telling where
exactly it comes from.
Previously we did socket-activation but this breaks the autostart
feature since upstream expects libvirtd to be started unconditionally on
boot.
Fixes#171623.
Previously, the NixOS test often failed as the copied config file is not
overwriteable. In actual setups, the restart interval is much bigger, such that
systemd-tmpfiles will correct the permissions inbetween.
On some occasions, the GitHub runner service encounters errors which are
deemed retryable but result in the runner's termination. To signal a
retryable error, the runner exits with status code 2:
https://github.com/actions/runner/blob/40ed7f8/src/Runner.Common/Constants.cs#L146
To account for that behavior, this commit sets
`RestartForceExitStatus=2` which results in a service restart regardless
of using an ephemeral runner or not.
* s/NextCloud/Nextcloud/g
* `enableBrokenCiphersForSSE` should be enabled by default for any NixOS
installation from before 22.11 to make sure existing installations
don't run into the issue. Not the other way round.
* Update release notes to reflect on that.
* Improve wording of the warning a bit: explain which option to change
to get rid of it.
* Ensure that basic tests w/o `enableBrokenCiphersForSSE` run with
OpenSSL 3.
This makes it possible to remove mint themes in an easy way, in this
case we will just use the default from slick-greeter module, i.e. the
Adwaita theme.
in some circumstances, the setup service would fail with:
ERROR 1062 (23000) at line 5: Duplicate entry '1' for key 'PRIMARY'
so let's use an upsert instead of insert. This also simplifies the
script.
Besides, also fix that when the setup script changes, the corresponding
script is not restarted as it is usually not active, so we trigger a
restart of the main systemd service.
Without this, you get the following error message in the logs:
udisksd[4082]: Failed to load config files: Failed to get contents of the config dir (/etc/libblockdev/conf.d/)Error opening directory “/etc/libblockdev/conf.d/”: No such file or directory. Using the built-in config
In ee0b8a7eaa we made the user service wait on network-online, but
forgot about the system service. We need them _both_ to wait when the
wifi source is enabled.
