Any system uid will do, so we let the system allocate
one for us. The 'mailman' group is gone entirely since
we don't need it. Users who wish to run the 'mailman'
administration utility can do so via 'sudo':
$ sudo -u mailman mailman info
Also, simplify the syntax of our user.users entry to
rely on an attribute set rather than a list.
The `keys.target` is used to indicate whether all NixOps keys were
successfully uploaded on an unattended reboot. However this can cause
startup issues e.g. with NixOS containers (see #67265) and can block
boots even though this might not be needed (e.g. with a dovecot2
instance running that doesn't need any of the NixOps keys).
As described in the NixOps manual[1], dependencies to keys should be
defined like this now:
``` nix
{
systemd.services.myservice = {
after = [ "secret-key.service" ];
wants = [ "secret-key.service" ];
};
}
```
However I'd leave the issue open until it's discussed whether or not to
keep `keys.target` in `nixpkgs`.
[1] https://nixos.org/nixops/manual/#idm140737322342384
The new option services.postfix.localRecipients allows
configuring the postfix option 'local_recipient_maps'. When
set to a list of user names (or patterns), that map
effectively replaces the lookup in the system's user
database that's used by default to determine which local
users are valid.
This option is useful to explicitly set local users that are
allowed to receive e-mail from the outside world. For local
injection i.e. via the 'sendmail' command this option has no
effect.
When using a different database, the evaluation fails as
`config.services.postgresql.package` is only set if `services.postgresql` is enabled.
Also, the systemd service shouldn't have a relation to postgres if a
remote database is used.
With this option it's possible to specify a custom expression for
`roundcube`, i.e. a roundcube environment with third-party plugins as
shown in the testcase.
When reworking the rspamd workers I disallowed `proxy` as a type and
instead used `rspamd_proxy` which is the correct name for that worker
type. That change breaks peoples existing config and so I have made this
commit which allows `proxy` as a worker type again but makes it behave
as `rspamd_proxy` and prints a warning if you use it.
The `rmilter` module has options for configuring `postfix` to use it but
since that module is deprecated because rspamd now has a builtin worker
that supports the milter protocol this commit adds similar `postfix`
integration options directly to the `rspamd` module.
The lines stored in `extraConfig` and `worker.<name?>.extraConfig`
should take precedent over values from included files but in order to do
this in rspamd UCL they need to be stored in a file that then gets
included with a high priority. This commit uses the overrides option to
store the value of the two `extraConfig` options in `extra-config.inc`
and `worker-<name?>.inc` respectively.
When the workers option for rspamd was originally implemented it was
based on a flawed understanding of how workers are configured in rspamd.
This meant that while rspamd supports configuring multiple workers of
the same type, so that different controller workers could have different
passwords, the NixOS module did not support this because it would write
an invalid configuration file if you tried.
Specifically a configuration like the one below:
```
workers.controller = {};
workers.controller2 = {
type = "controller";
};
```
Would result in a rspamd configuration of:
```
worker {
type = "controller";
count = 1;
.include "$CONFDIR/worker-controller.inc"
}
worker "controller2" {
type = "controller";
count = 1;
}
```
While to get multiple controller workers it should instead be:
```
worker "controller" {
type = "controller";
count = 1;
.include "$CONFDIR/worker-controller.inc"
}
worker "controller" {
type = "controller";
count = 1;
}
```
When implementing #49620 I included an enable option for both the
locals and overrides options but the code writing the files didn't
actually look at enable and so would write the file regardless of its
value. I also set the type to loaOf which should have been attrsOf
since the code was not written to handle the options being lists.
This fixes both of those issues.
By default rspamd will look for multiple files in /etc/rspamd/local.d
and /etc/rspamd/override.d to be included in subsections of the merged
final config for rspamd. Most of the config snippets in the official
rspamd documentation are made to these files and so it makes sense for
NixOS to support them and this is what this commit does.
As part of rspamd 1.8.1 support was added for having custom Lua
rules stored in $LOCAL_CONFDIR/rspamd.local.lua which means that it is
now possible for NixOS to support such rules and so this commit also
adds support for this to the rspamd module.
Several service definitions used `mkEnableOption` with text starting
with "Whether to", which produced funny option descriptions like
"Whether to enable Whether to run the rspamd daemon..".
This commit corrects this, and adds short descriptions of services
to affected service definitions.
The socket activation I added to the rspamd module doesn't actually work
and can't be made to work without changes to rspamd.
See: #47421
See: rspamd/rspamd#2035
/run/rmilter is set by systemd, and have root:root ownership, which
prevent pid file to write.
This fix suggested to be promoted to 18.09 branch.
(Although rmilter itself is deprecated, and I plan to remove it, after
18.09 would be released)
This allows the definition of a custom derivation of Exim,
which can be used to enable custom features such as LDAP and PAM support.
The default behaviour remains unchanged (defaulting to pkgs.exim).
The pull request that added dhparams (#39507) was made at the time where
the dhparams module overhaul (#39526) wasn't done yet, so it's still
using the old mechanics of the module.
As stated in the release notes:
Module implementers should not set a specific bit size in order to let
users configure it by themselves if they want to have a different bit
size than the default (2048).
An example usage of this would be:
{ config, ... }:
{
security.dhparams.params.myservice = {};
environment.etc."myservice.conf".text = ''
dhparams = ${config.security.dhparams.params.myservice.path}
'';
}
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @qknight, @abbradar, @hrdinka, @leenaars
The dovecot bump to 2.3.1 caused the dovecot service to fail to start
because it would try to chgrp sockets to dovecot whereas our default
dovecot group is called dovecot2.
`services.postfix.config` is now correctly merged with the default attrset
specified in the module. Some options that are lists in postfix also
have to be lists in nix to be merged correctly. Other default options are
now set with `mkDefault` so they can be overridden via the module system.
The current `remotes` option is a string option containing nullmailer remote
definitions. However, those definitions may contain secret credentials and
should therefore not be put world-readable in the nix store.
I added a `remotesFile` option, which allows to specify a path to the remotes
definition file instead. This way, the definitions can be kept outside of the
nix store with more secure file permissions.
Spamassassin expects its system-wide configuration at /etc/spamassassin, and
some user tools (like sa-learn) need to read those configuration files.
Therefore, we provide a symlink from /etc/spamassassin to the appropriate Nix
store path to make sure those tools work without the user having to pass an
elaborate --siteconfig path that, potentially, changes every time the system
updates.
Fixes https://github.com/NixOS/nixpkgs/issues/29414.
This option got introduced in 7904499542
and it didn't check whether mailUser and mailGroup are null, which they
are by default.
Now we're only creating the user if createMailUser is set in conjunction
with mailUser and the group if mailGroup is set as well.
I've added a NixOS VM test so that we can verify whether dovecot works
without any additional options set, so it serves as a regression test
for issue #29466 and other issues that might come up with future changes
to the Dovecot service.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #29466
Cc: @qknight, @abbradar, @ixmatus, @siddharthist
I realize that advanced users like to configure services with Nix
attrsets, but I don't think we should remove the option to use the
(configuration) language provided by upstream.
