We already had python3Packages.mailman, but that's only really usable
as a library. The only other option was to create a whole Python
environment, which was undesirable to install as a system-wide
package.
It's likely that a user might want to set multiple values for
relay_domains, transport_maps, and local_recipient_maps, and the order
is significant. This means that there's no good way to set these
across multiple NixOS modules, and they should probably all be set
together in the user's Postfix configuration.
So, rather than setting these in the Mailman module, just make the
Mailman module check that the values it needs to occur somewhere, and
advise the user on what to set if not.
This replaces all Mailman secrets with ones that are generated the
first time the service is run. This replaces the hyperkittyApiKey
option, which would lead to a secret in the world-readable store.
Even worse were the secrets hard-coded into mailman-web, which are not
just world-readable, but identical for all users!
services.mailman.hyperkittyApiKey has been removed, and so can no
longer be used to determine whether to enable Hyperkitty. In its
place, there is a new option, services.mailman.hyperkitty.enable. For
consistency, services.mailman.hyperkittyBaseUrl has been renamed to
services.mailman.hyperkitty.baseUrl.
When mailman-web restarts, it removes the generated "static" directory. This
breaks a currently running httpd process, which needs a re-start, too, to
obtain a new handle for the newly generated path.
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.
