This is not a breaking change. Existing setups continue to work as-is.
Users of `cfg.mailerPasswordFile` will get an option rename/deprecation
warning, but that's it (assuming there is no regression).
This adds `cfg.secrets`, which is a wrapper over systemd's
`LoadCredential=` leveraging Forgejo's `environment-to-ini`.
`environment-to-ini` is intended for configuring Forgejo in OCI
containers.
It requires some fairly annoying escaping of the section names to fit
into the allowed environment variable charset.
E.g. `"log.console".COLORIZE = false` becomes
`FORGEJO__LOG_0x2E_CONSOLE__COLORIZE=false`.
- `.` needs to be replaced with `_0X2E_` and
- `-` needs to be replaced with `_0X2D_`
Those are simply the hex representation of each char from an ASCII
table:
. = ASCII 46 = 46 (decimal) = 2E (hex) = 0x2E = _OX2E_
To make interacting with `environment-to-ini` less annoying, we template
and escape the sections/keys in nix:
`cfg.secrets` takes the same free-form sections/keys as `cfg.settings`.
Meaning there is now a generalized abstraction for all keys, not just
those that have been manually implemented in the past.
It goes as far as theoretically allowing one to have `DEFAULT.APP_NAME`
read from a secret file.
I don't know why one would want to do that, but it has been made
possible by this :^)
More reasonable examples are listed in the `cfg.secrets` option example.
We also continue to bootstrap a handful of secrets like
`security.SECRET_KEY`. This is done is a sort of sidecar bootstrap unit
fittingly called `forgejo-secrets.service`.
Overriding those is, just like before, not really intended and requires
the use of `lib.mkForce` and might lead to breakage. But it is, in a
way, more possible than before.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
The main idea behind that was to be able to do more sophisticated
merging for stuff that goes into `postgresql.conf`:
`shared_preload_libraries` is a comma-separated list in a `types.str`
and thus not mergeable. With this change, the option accepts both a
comma-separated string xor a list of strings.
This can be implemented rather quick using `coercedTo` +
freeform modules. The interface still behaves equally, but it allows to
merge declarations for this option together.
One side-effect was that I had to change the `attrsOf (oneOf ...)` part into
a submodule to allow declaring options for certain things. While at it,
I decided to move `log_line_prefix` and `port` into this structure as
well.
* nixos/forgejo: changelog and migration instructions
* nixos/forgejo/docs: clarify sentence
Co-authored-by: Trolli Schmittlauch <schmittlauch@users.noreply.github.com>
* nixos/forgejo/docs: document migration via gitea impersonation
* nixos/forgejo/docs: note about url change on migration
* nixos/forgejo/docs: note about migration (non-)requirement
* nixos/forgejo/docs: header ids
* nixos/forgejo/docs: clarify release notes entry
Co-authored-by: Emily <git@emilylange.de>
* nixos/forgejo/docs: improve manual entry
Co-authored-by: Emily <git@emilylange.de>
* nixos/forgejo/docs: move changelog line to the middle of the section
as noted <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
---------
Co-authored-by: Trolli Schmittlauch <schmittlauch@users.noreply.github.com>
Co-authored-by: Emily <git@emilylange.de>
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
when using the host's openssh service (not the builtin golang one).
This enables the use of the much faster and more efficient wire protocol
version 2.
See https://git-scm.com/docs/protocol-v2
From `postgresql_15`'s release notes:
> PostgreSQL 15 also revokes the CREATE permission from all users except
a database owner from the public (or default) schema.
https://www.postgresql.org/about/news/postgresql-15-released-2526/
This directly affects `services.postgresql.ensureUsers` in NixOS,
leading to
> permission denied for schema public
`postgresql_15` is now the default for stateVersion `23.11`/`unstable`.
So until this is resolved globally, we work around this issue.
Following a decicion from both the gitea and forgejo maintainers in
nixpkgs.
This means, that forgejo will no longer co-use the nixos/gitea module
via `services.gitea.package = pkgs.forgejo`.
