- 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.
