Since stalwart-mail 0.6.0, queue and report files are located in
the shared `storage.{data,blob}` stores. The `{queue,report}.path`
settings no longer had any effect since then.
I'm also removing the creation of the associated extra directories
in the `preStart` script. This should not cause any issue with old
setups since 0.6.0 was already packaged when 24.05 was released.
This sets RocksDB as the default storage backend for `stateVersion` >=
24.11. For previous `stateVersion`s, the structured data and blobs
remain on SQLite and the filesystem respectively.
This is closer to the suggested upstream configuration for fully local
storage.
This configures a default account directory for the Stalwart service.
It uses the default common database which was already configured.
Without this directory, admins could not manage users and groups using
the `stalwart-cli` tools.
This service stores a large number of files for its blob store and some
of its databases. This is not compatible with `DynamicUser`, which
`chown`s everything in the state directory every time the service is
started. Therefore, we now use a static system user and group instead.
See https://github.com/NixOS/nixpkgs/pull/313634#discussion_r1609960417
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.
Plugin configuration is pesky in dovecot2, let's warn about potential conflicts
in the module system by using a fancy regex.
This is only band-aid, this should be removed ASAP.
We clean up also a 21.05-era warning.
https://github.com/NixOS/nixpkgs/pull/275031 introduced structured configuration
for the dovecot2 sieve plugin, by doing so, it broke SNM configuration doing Sieve configurations.
This attempts to fix up the public API to make it possible for SNM to pick up the pieces.
For some reason, I don't know why I missed those, but
I didn't look at my logs for a while.
It would be nice if we could catch those statically kinda (?) in CI.
In my experience, just after boot, the default timeout of 60 seconds
often isn't quite enough for Mailman. It's better for the user to
have the request take a little longer than it is to 504.
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
It's time again, I guess :>
Main motivation is to stop being pinged about software that I maintained
for work now that I'm about to switch jobs. There's no point in pinging
me to review/test updates or to debug issues in e.g. the Atlassian stack
or on mailman since I use neither personally.
But there's also a bunch of other stuff that I stopped using personally. While
at it I realized that I'm still maintainer of a few tests & modules related to
packages I stopped maintaining in the past already.
Our postfix-setup service ensures that the directory is only writable by root.
postalias by default drops permissions to the user of the source file. In the
case of NixOS that file is in the nix store and thus always owned by root and
everything works.
The problem is that when using a nixos-container with user namespaces (`-U`)
then the nix store is owned by nobody/nogroup, and postfix-setup.service will be
unable to create or modify `aliases.db`.
Since the file would otherwise be owned by root, we should tell postfix to not
assume the user and permissions of the `aliases` file by setting -o and -p
From postalias(1)
> -o Do not release root privileges when processing a non-root input file. By
> default, postalias(1) drops root privileges and runs as the source file owner
> instead.
> -p Do not inherit the file access permissions from the input file when
> creating a new file. Instead, create a new file with default access
> permissions (mode 0644).
This fixes using coderepos in /home, by allowing the coderepo paths to
be bind mounted into an otherwise empty /home tmpfs. Since this was
the usecase for making ProtectHome= overrideable, we don't need the
mkDefault any more.
The output from `systemd-analyze security davmail`:
Before: `Overall exposure level for davmail.service: 8.2 EXPOSED 🙁`
After: `Overall exposure level for davmail.service: 1.3 OK 🙂`
Since 816614bd62, the service is set to use the exim user so that
systemd takes care of the credentials ownership. The executable is
still required to run as root, to then drop privileges. The prefix '+'
that was used however interfers with the use of privilege restrictions
and other sandboxing options. Since we only want to escape the "User"
setting, we can use the '!' prefix instead.
When using Roundcube with a non local PostgreSQL database wait for
network start before running roundcube-setup.service
Otherwise the database is not reachable and the service fails.
Extract PostgreSQL database password for Roundcube from .pgpass file.
The password file is used in two locations:
1. in the Roundcube config.php
2. in the systemd setup service that initializes the roundcube
database
These two services need the password in different formats.
Keep the password file in PostgreSQL standard format and extract the
password for the Roundcube config (see #215986).
