Package Mox as a service

[themadbit]

Closes #576 #577 #578

• Exposed Mox as a service to resolve issue(s).
• Initial tests are running, and a local rebuild of NixOS with the module included runs just fine.
  i.e:

However, it fails to start/survive reboot with:

[themadbit@nixos:~]$ systemctl status mox
○ mox.service
     Loaded: loaded (/etc/systemd/system/mox.service; enabled; preset: ignored)
     Active: inactive (dead)

Mar 27 14:40:30 nixos systemd[1]: Dependency failed for mox.service.
Mar 27 14:40:30 nixos systemd[1]: mox.service: Job mox.service/start failed with result 'dependency'.

So, I'll leave this as a draft PR as I investigate further. Putting it out here in case you've had a similar headache and know the painkiller 😅

[eljamm]

Turns out that it was just a matter of modifying the service order since the dns configuration is not over by the time the mox-setup service tries to start. With the following patch, the setup completes, the server runs and the NixOS Test succeeds:

fix-mox-service-order.patch

---
 projects/Mox/module.nix | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/projects/Mox/module.nix b/projects/Mox/module.nix
index 43bb8d7..91d38d7 100644
--- a/projects/Mox/module.nix
+++ b/projects/Mox/module.nix
@@ -48,23 +48,26 @@
     systemd.services.mox-setup = {
       description = "Setup Mox Mail Server";
       wantedBy = [ "multi-user.target" ];
+      requires = [ "network-online.target" ];
+      after = [ "network-online.target" ];
       before = [ "mox.service" ];
       serviceConfig = {
         Type = "oneshot";
         RemainAfterExit = true;
+        User = "mox";
+        Group = "mox";
       };
       script = ''
         mkdir -p /var/lib/mox
         cd /var/lib/mox
         ${pkgs.mox}/bin/mox quickstart -hostname ${config.services.mox.hostname} ${config.services.mox.user}
-        chown -R mox:mox /var/lib/mox
       '';
     };

     systemd.services.mox = {
       wantedBy = [ "multi-user.target" ];
-      after = [ "network.target" "mox-setup.service" ];
-      requires = [ "mox-setup.service" ]; # This ensures mox-setup must succeed
+      after = [ "mox-setup.service" ];
+      requires = [ "mox-setup.service" ];
       serviceConfig = {
         WorkingDirectory = "/var/lib/mox";
         ExecStart = "${pkgs.mox}/bin/mox -config /var/lib/mox/config/mox.conf serve";
--
2.47.2

[themadbit]

lol. Been on it since I left the office hour
I also figured out a way to get it working. But it is a very brute force way (but at least I got to learn lots of networking configs).

I added services.dnsmasq and enabled dnssec and had the mox-setup unit wait for that to be up and running.

[eljamm]

I added services.dnsmasq and enabled dnssec and had the mox-setup unit wait for that to be up and running.

That sounds like it could be useful for a separate example config that uses DNSSEC, for those interested in that

[themadbit]

That sounds like it could be useful for a separate example config that uses DNSSEC, for those interested in that

Yess. I've stashed changes using dnsmasq to have a running service first, and then I can build upon it slowly. Ultimately a user should be able to specify all their desired config(s) which means supporting sconf. Nonetheless, the current implementation, if successfully built, a user with a working and configured domain can have Mox running and set up working emails.

[eljamm]

I think the test fails in CI because it's not running with .driver or .driverInteractive as those give the VM an internet connection (which is required here for dns, I guess). To reproduce this, one can run:

nix build .#checks.x86_64-linux.projects/Mox/nixos/tests/basic

which will fail.

[themadbit]

After many days of debugging, I got it working @eljamm
Instead of using static files, I worked through to get the quickstart command tested, as it allows better reproducibility than the alternative. I'll now clean up the commits (maybe stash some) and consider packaging it as a program.

I've refreshed my knowledge on DNSs quite much in this process. It was as good as it was heartbreaking 😅

Kindly give it a review. Thanks for the time you've dedicated to my issues.

[eljamm]

Well done @themadbit! This is shaping up really nicely.

[themadbit]

@fricklerhandwerk, we might want to rerun the checks, as the error with ubuntu:devel is self-resolving. I had the same problem updating my ubuntu machine and it worked fine after sometime. I assume some of their archives keep going down

[eljamm]

@fricklerhandwerk, we might want to rerun the checks, as the error with ubuntu:devel is self-resolving. I had the same problem updating my ubuntu machine and it worked fine after sometime. I assume some of their archives keep going down

The issue with the ubuntu test was resolved in #1054 and I'm in the process of fixing CI, now.

[themadbit]

The issue with the ubuntu test was resolved in #1054 and I'm in the process of fixing CI, now.

ooh, okay

[eljamm]

CI failures are unrelated to these changes (see #1040)

[eljamm]

Looks good, well done @themadbit!