Conflicts:
- pkgs/development/python-modules/pyqt/6.x.nix:
NIX_CFLAGS_COMPILE changed
cb6f270be2 version bump removes flag no longer necessary
b7a8d59e3a adds flag to fix builds on Darwin, not sure if needed after the bump
This re-introduces the old stable ZFS version we had in the past following
the many predicted issues of ZFS 2.2.x series, that is much more stable
than any further ZFS version at the moment.
I am also removing myself from maintenance of any further ZFS versions as I am
planning to quit ZFS maintenance at some point.
In the meantime, for users like me who depend on ZFS for critical operations, here is a ZFS version
that is known to work for LTS kernels.
- Use lazyAttrs (for config references) settings for main server.properties.
- Drop dangerous default for "log.dirs"
- Drop apache-kafka homedir; unused and confusing
- Support formatting kraft logdirs
Depends on EOL software and no maintenance has been attempted to change this after a ping
(https://github.com/NixOS/nixpkgs/issues/259178)
Feel free to adopt and re-introduce if you care about this software.
This will probably seriously hamper ELK usability in nixpkgs, but as it
receives no maintenance…
Invidious uses a strange setup where the database name is different from the system username
for non-explicit reasons.
Because of that, it makes it hard to migrate it to use `ensureDBOwnership`, we leave it to Invidious' maintainers
to pick up the pieces.
pgbouncer test is special in the sense where it actually tries
to connect via SCRAM SHA, let's avoid `ensureDBOwnership` here
otherwise for some reason pgbouncer will try to look in pg_shadow
for the authuser…
Two issues:
1. We need a subjectAltName on the TLS cert. Stolen from the akkoma
test. <3 illdefined
2. There's a bug in the current toot release wrt. date parsing. It's
been fixed upstream but it's not been released yet. Using the
current toot master for this VM test to work around this.
Note: I warned upstream we'd need a new toot release.
Fixes https://github.com/NixOS/nixpkgs/issues/264951
This changes
* the plausible HTTP web server
to be listening on localhost only, explicitly.
This makes Plausible have an explicit safe default configuration,
like all other networked services in NixOS.
For background discussion, see: https://github.com/NixOS/nixpkgs/issues/130244
As per my upstream Plausible contribution
(https://github.com/plausible/analytics/pull/1190)
Plausible >= 1.5 also defaults to listening to localhost only;
nevertheless, this default should be stated explicitly in nixpkgs
for easier review and independence from upstream changes, and
a NixOS user must be able to configure the
`listenAddress`, as there are valid use cases for that.
Also, disable
* the Erlang Beam VM inter-node RPC port
* the Erlang EPMD port
because Plausible does not use them (see added comment).
This is done by setting `RELEASE_DISTRIBUTION=none`.
Thus, this commit also removes the NixOS setting `releaseCookiePath`,
because it now has no effect.
Closes#216989
First of all, a bit of context: in PostgreSQL, newly created users don't
have the CREATE privilege on the public schema of a database even with
`ALL PRIVILEGES` granted via `ensurePermissions` which is how most of
the DB users are currently set up "declaratively"[1]. This means e.g. a
freshly deployed Nextcloud service will break early because Nextcloud
itself cannot CREATE any tables in the public schema anymore.
The other issue here is that `ensurePermissions` is a mere hack. It's
effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how
a value is substituted in a query. You'd have to parse a subset of SQL
to actually know which object are permissions granted to for a user).
After analyzing the existing modules I realized that in every case with
a single exception[2] the UNIX system user is equal to the db user is
equal to the db name and I don't see a compelling reason why people
would change that in 99% of the cases. In fact, some modules would even
break if you'd change that because the declarations of the system user &
the db user are mixed up[3].
So I decided to go with something new which restricts the ways to use
`ensure*` options rather than expanding those[4]. Effectively this means
that
* The DB user _must_ be equal to the DB name.
* Permissions are granted via `ensureDBOwnerhip` for an attribute-set in
`ensureUsers`. That way, the user is actually the owner and can
perform `CREATE`.
* For such a postgres user, a database must be declared in
`ensureDatabases`.
For anything else, a custom state management should be implemented. This
can either be `initialScript`, doing it manual, outside of the module or
by implementing proper state management for postgresql[5], but the
current state of `ensure*` isn't even declarative, but a convergent tool
which is what Nix actually claims to _not_ do.
Regarding existing setups: there are effectively two options:
* Leave everything as-is (assuming that system user == db user == db
name): then the DB user will automatically become the DB owner and
everything else stays the same.
* Drop the `createDatabase = true;` declarations: nothing will change
because a removal of `ensure*` statements is ignored, so it doesn't
matter at all whether this option is kept after the first deploy (and
later on you'd usually restore from backups anyways).
The DB user isn't the owner of the DB then, but for an existing setup
this is irrelevant because CREATE on the public schema isn't revoked
from existing users (only not granted for new users).
[1] not really declarative though because removals of these statements
are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467
[2] `services.invidious`: I removed the `ensure*` part temporarily
because it IMHO falls into the category "manage the state on your
own" (see the commit message). See also
https://github.com/NixOS/nixpkgs/pull/265857
[3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";`
[4] As opposed to other changes that are considered a potential fix, but
also add more things like collation for DBs or passwords that are
_never_ touched again when changing those.
[5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
I changed my nickname from Ninjatrappeur to Picnoir. My github id is
stable, it shouldn't break too much stuff.
I took advantage of this handle change to remove myself from the
hostapd maintainers: I don't use NixOS as a router anymore.
I no longer contribute to this test nor do I plan to do so in the
future.
My contributions moved to nixosTests.forgejo, after we (nixpkgs) decided
to split the gitea and forgejo nixpkgs modules.
[Motivation](NixOS#257817 (comment))
`extraLayouts` was missed in #259891, so moving it to the other xkb
options with this PR.
Signed-off-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
Related to #262907 (Django3 removal from nixpkgs).
This package already required an unreasonable amount of maintenance
regularly for a such small leaf-package. It has a few highly outdated
dependencies (e.g. flask 1, jinja2 2.11, sqlalchemy 1.3).
After at least each Python package-set update one had to fix up a lot of
dependencies to fix the package itself, so it was only useful on stable
branches. And having so much outdated software in a security-sensitive
piece of software seems questionable.
Finally, globin and I won't be available for maintaining this now that
Mayflower is migrating to another solution (and we'll do that as well)
and I'd expect this to bitrot extremely quick if we both bail out.
I don't really understand why this is only for a single version, so I
figured I'd just add this to the test matrix to also cover this
test-case for each major. Now, there's also one thing less to take care of
when removing old postgresql versions.
On current nixpkgs, no modifications to the server settings were
necessary to pass the audit. However, some of the client algorithms were
considered insecure. The client configuration lists all algorithms which
were listed as acceptable by `ssh-audit`.
This can be used as an example of a configuration currently considered
acceptable by `ssh-audit`, and verifies that such a configuration
results in a compatible client/server configuration.
Beware that this test will continue passing when future versions of
`ssh-audit` add support for new algorithms. In other words, the example
configuration represents a subset of what the current version of
`ssh-audit` would consider acceptable.
This flag allows the user to optionally exclude
switch-to-confguration.pl from toplevel.
This is interesting for appliance images where you don't want to re-build
the system. This flag is called `rebuildable` because the standard
interface to do this is `nixos-rebuild` which will not work anymore with
this change.
Kea may clean the runtime directory when starting (or maybe systemd does
it). I ran into this issue when restarting Kea after changing its
configuration, so I think the fact it normally doesn't clean it is a
race condition (it's cleaned on service start, and normally all Kea
services start at roughly the same time).
nixosTests.forgejo: test backup/dump service; nixos/forgejo: pass {env}`GIT_PROTOCOL` via ssh to forgejo; nixosTests.forgejo: test git wire protocol version
Otherwise the tests will fail with `networking.useNetworkd = true;`
because `systemd-resolved` ignores invalid hostnames in `/etc/hosts`
(which is where all hosts from the `nodes`-attribute set end up) and
subsequently e.g. `ssh server_lazy` will fail because the name cannot be
resolved.
In d6e84a4574 the test-framework was
changed to replace all dashes with underscores of hostnames in the
python code to have readable hostnames that are valid. I.e.
nodes.foo-bar = {}
represents a host with a valid hostname and it can be referenced in the
`testScript` with `foo_bar`.
Applying this here fixes the test for both scripted networking and
networkd.
This should allow us to catch issues regarding that in the future.
nixos/gitea had an issue with the dump service recently, which didn't
affect us, fortunately.
But to be fair, it only affected non-default-y setups.
Not something we are able to catch in the current, rather simple, config
of our test.
Still, I see a lot of value adding this new subtest to our test suite.
Anyhow, this patch also exposes the resulting tarball as test (build)
output, which is a nice addition IMHO, as it allows some sort of
external sanity-check, if needed, without running the test interactive.
The knot_server_zone_count metric does not exist anymore, and the next
best thing to watch for is the zone serial, that we define ourselves.
The serial is a number and displayed in the scientific notation, i.e.
>>> machine.succeed('curl localhost:9433/metrics|grep 019 >&2')
[...]
knot # knot_zone_serial{zone="test."} 2.019031301e+09
nginx lua needs resty
the enableSandbox option of nginx was removed in 535896671b
the test fails with
```
vm-test-run-nginx-sandbox> machine # [ 47.753580] nginx[1142]: nginx: [alert] detected a LuaJIT version which is not OpenResty's; many optimizations will be disabled and performance will be compromised (see https://github.com/openresty/luajit2 for OpenResty's LuaJIT or, even better, consider using the OpenResty releases from https://openresty.org/en/download.html)
vm-test-run-nginx-sandbox> machine # [ 47.756064] nginx[1142]: nginx: [alert] failed to load the 'resty.core' module (https://github.com/openresty/lua-resty-core); ensure you are using an OpenResty release from https://openresty.org/en/download.html (reason: module 'resty.core' not found:
vm-test-run-nginx-sandbox> machine # [ 57.911766] systemd[1]: Failed to start Nginx Web Server.
```
bind_interface is the mosquitto way of trying to bind to all addresses
on an interface, but it is unreliable (trying to bind to link-local v6
addresses *sometimes* but not always) and just prone to failure in
general for reasons we have yet to discover.
since this kind of automatic behavior isn't particularly necessary in a
declarative system we may as well skip it.
