I would think so :)

Maybe they're more sceptical, though, as 127.0.0.1 could be considered more failsafe or something. 😆 This requires that localhost resolves properly to ::1 and 127.0.0.1 and such. (It's not too long ago when NixOS itself had no such entries in /etc/hosts as well…) Also this could be bad if MySQL is not listening on IPv6. I'll eventually try what they think, though, the PR would be simple enough. 🙂

Maybe a compile time option, preserving the behavior of 127..1, where --unix-auth or something expects a hosts mapping and changes it to localhost. Although that's a little more complicated :)

Matomo should obviously break if this assumption fails in the future, although I'm not suggesting it is Nix's responsibilty to monitor all its software for backwards incompatible changes. It is easy to forget piwik is running, particularly with a stale blog like mine :)

👍 I phrased this too hard, there's no assumption by matomo source code or by the NixOS package how the database is named, and I don't expect there'll be one from the matomo side ever, meaning you're totaly free to name your database banana if you like. This is merely a reminder by me, to reduce suprises with the user's backup scripts or something. I came up with a weaker wording that hopefully gets this across better!

Ah, you implemented this. Impressive! Is the reason you opted for recursiveUpdate instead of attribute set merging to allow for overrides? Not clear on the difference.

Yes, somehow I really managed to get this done. 😄 If you try to merge with // operator it doesn't work as this would discard my custom defaults as soon as the user defines something custom. After a lot of fiddling around, I discovered recursiveUpdate, which does exactly what I need here, together with the locations definitions and the well-dosed mkForce at https://github.com/NixOS/nixpkgs/pull/34028/files#diff-8c50bc76feff6200b2774e17f7f44c52R199.

I also tried to achieve that via mkDefault etc., but I could not find a way that worked. Which does not mean there isn't, but I don't understand enough of the priority attribute merging system to find it…

This code looks correct. However when setting:

  networking.hostName  = "jarmac"';
  networking.domain = "org";

I received errors from ACME that the machine was trying to register matomo.jarmac. which is clearly incorrect.

Setting networking.hostname to jarmac.org caused an error with the prestart script looking for /var/lib/piwik, but this was resolved with another attempt, and is probably a relic from the first failed ACME attempt.

When I designed this I did only think of networking.hostName = "<hostname>.<domain.org>"; and domain = null; (what most people are probably doing today) or, imho preferrable, networking.hostName = "<hostname>"; and networking.domain = "<domain.org>";. But hostName = "jarmac"; and domain = "org"; is nice, should really work and is what I'd like to recommend from now on for people that only want to put a single computer in their domain.

I could not reproduce the issue, though. 😥 The only explanation I have is that somehow the domain was set to "", which would explain the output. Maybe you can recheck whether that still occurs, and if yes, check what server_name landed in your nginx config (systemctl status nginx -> master process ngnix -c /nix/store…nginx-conf), and what landed in the acme service (should be like systemctl status acme-matomo.jarmac..service, and then the service file). If the issue persists, we're hopefully able to track the wrong output down that way.

Aha! It was an error on my end:

  services.nginx = let
    hostname = config.networking.hostName;
    tld = config.networking.domain;
  in
  {
    enable = true;
    virtualHosts = {
      "${hostname}" = {  # here's the error, no tld splicing in
        forceSSL = true;
        enableACME = true;
        serverAliases = [ "www.${hostname}" ];
        locations."/" = {
          root = "${nginxRootPath}";
        };
      };
    };
  };

Apologies.

Ok I see!

The fqdn = let … in join config.networking.hostName config.networking.domain snippet is actually from my configuration.nix, you might want a copy of that yourself so you can write ${fqdn} everywhere and avoid that error / doing it by hand every time.. On my list of things to upstream next, as config.lib.networking.fqdn helper value or something. 😉 But will be quite a lot of work to find all places in nixpkgs where this should be used but isn't.

Just explicitly noting that I did not need to go through the set up again.

That's as expected, the setup would only come up again if the data was not imported. 🙂

Huh.. this shouldn't have failed on me.

Systemd output:

warning: the following units failed: matomo_setup_update.service

● matomo_setup_update.service
   Loaded: loaded (/nix/store/9f2hkvllc46vjp3x0h92vfnwljsf381g-unit-matomo_setup_update.service/matomo_setup_update.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2018-01-31 22:59:45 EST; 16s ago
  Process: 29211 ExecStartPre=/nix/store/wmg25rziv6zcm0hcr0q4wd1dzjqw7scj-unit-script/bin/matomo_setup_update-pre-start (code=exited, status=1/FAILURE)

Jan 31 22:59:45 jarmac.org systemd[1]: Starting matomo_setup_update.service...
Jan 31 22:59:45 jarmac.org matomo_setup_update-pre-start[29211]: Migrating from /var/lib/piwik to /var/lib/matomo
Jan 31 22:59:45 jarmac.org matomo_setup_update-pre-start[29211]: rmdir: failed to remove '/var/lib/piwik': No such file or directory
Jan 31 22:59:45 jarmac.org systemd[1]: matomo_setup_update.service: Control process exited, code=exited status=1
Jan 31 22:59:45 jarmac.org systemd[1]: Failed to start matomo_setup_update.service.
Jan 31 22:59:45 jarmac.org systemd[1]: matomo_setup_update.service: Unit entered failed state.
Jan 31 22:59:45 jarmac.org systemd[1]: matomo_setup_update.service: Failed with result 'exit-code'.
warning: error(s) occurred while switching to the new configuration

I personally would not worry about this as it went away on retry, and there's no reason to suspect a race condition here.

Tested it again, the rmdir is superfluous I think. Probably it's a leftover / merge error from before I discovered mv -T. Removed it now.