The services/networking directory is already quite polluted and the
first point where I was looking for the offlineimap module was in
services/mail and didn't find it there.
Offlineimap already has IMAP in its name and clearly belongs to the
"mail" category so let's move it there.
Tested by evaluating a configuration with services.offlineimap enabled.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @DamienCassou
Coercing the derivation to string causes the package to be built during
evaluation rather than during actual realization which is completely
unnecessary because we don't need additional Nix expression information
for the package (nor do we need it for the service).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @DamienCassou
Cc: @Profpatsch (stumbled on this because of him)
While entering the chroot should provide the same amount of isolation,
the preStart script will run with full root privileges and so would
benefit from some isolation as well (in particular due to
unbound-anchor, which can perform network I/O).
1. The preStart script ensures consistent ownership, even if the unbound
user's uid has changed
2. The unbound daemon does not generate data that needs to be private to
it, so it would not matter that a different service would end up
owning its data (as long as unbound remains enabled, it should reclaim
ownership soon enough anyway).
Thus, there's no clear benefit to allocate a dedicated uid for the
unbound service. This releases uid/gid 48.
Also, because the preStart script creates the data directory, there's no
need to specify a homedir or ask for its creation.
/dev/random is an exhaustible resource. Presumably, unbound will not be
used to generate long-term encryption keys and so allowing it to use
/dev/random only increases the risk of entropy exhaustion for no
benefit.
See #18319 for details. Starting network-online.target manually does not
work as it hangs indefinitely.
Additionally, don't treat avahi and dhcpcd special and sync their systemd units
with the respective upstream suggestion.
Systemd upstream provides targets for networking. This also includes a target network-online.target.
In this PR I remove / replace most occurrences since some of them were even wrong and could delay startup.
Radicale can run as a foreground service and will then emits logging and
errors on the standard output. This helps the logging end up in the
systemd journal.
Follow-up to the following commits:
abdc5961c3: Fix starting the firewall
e090701e2d: Order before sysinit
Solely use sysinit.target here instead of multi-user.target because we
want to make sure that the iptables rules are applied *before* any
socket units are started.
The reason I've dropped the wantedBy on multi-user.target is that
sysinit.target is already a part of the dependency chain of
multi-user.target.
To make sure that this holds true, I've added a small test case to
ensure that during switch of the configuration the firewall.service is
considered as well.
Tested using the firewall NixOS test.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
Probably as a result of 992c514a20, it
was not being started anymore.
My understanding of systemd.special(7) (section "Special passive
system units") is that the firewall should want network-pre.target,
rather than the other way around (not very intuitive...). This in
itself does not cause the firewall to be wanted, which is why the
wanted-by relationship with multi-user.target is necessary.
http://hydra.nixos.org/build/39965589
