| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
For sa-update we care about two successful codes:
* 1 -> no updates available: exit successfully
* 0 -> updates have been installed: run sa-compile and pass
through its return code
|
| | |
|
| |
|
|
|
|
| |
sa-compile speeds up processing the rules by compiling them from Perl to
C. This needs to be run after every update and is saved in the local
state directory by Perl and SpamAssassin version.
|
| |
|
|
|
|
|
|
|
|
|
| |
Let systemd create SpamAssassin's state directory and populate it using the
regular updater service. Depend on the updater service on boot but do not
propagate failure to the main service.
spamd's commands to start and reload the service are still executed as
root but user/group are set to properly chown the state directory to the
target user. spamd drops privileges itself for its runner children but
preserves root on the main daemon (to listen and re-exec).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sa-update currently runs as part of the pre-start script of spamd. The
network is not guaranteed to be online at that point and even if we
were to depend on that, it makes the bootup brittle, as there is a
reliance on SpamAssassin's update server as a startup dependency on
boot.
Refactor the setup to move the pre-start script into its own unit.
This allows to perform the setup task only once. Continuous updates
are already done by sa-update.service triggered by sa-update.timer.
Only run sa-update in case /var/lib/spamassassin is empty.
While we are on it, let sa-update.service depend on the network being
online.
|
| | |
|
| |
|
|
| |
Add missing type information to manually specified enable options or replace them by mkEnableOption where appropriate.
|
| |
|
|
|
|
| |
Using a custom path in the Nix store meant that users of the module
couldn't add their own config files, which is a desirable feature. I
don't think avoiding /etc buys us anything.
|
| | |
|
| |
|
|
|
|
|
| |
Supporting a path here is important because it allows e.g. fetching a
configuration from a URL. To do this and provide the configuration as
a string, IFD would be necessary. It's just written into a path
anyway.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
spamassassin and abstracted service to not use /etc/spamassassin, also running sa-update as spamd user periodically (#26470)
thanks @grahamc for IRC comments
|
| | |
|
| |
|
|
|
|
|
|
| |
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
|
| |
|