Post title goes here#

Thu, 31 May 2018 23:54:36 +0000

It's taken more than a little while to get NixWRT back into the brain again, partly due to needing a change and partly due to work/family stuff. Currently in progress: breaking the backuphost.nix monolith into composable modules, such that I (or a user, when in the fulness of time the project acquires any users) can add the various parts separately.

This was prompted by a question on the NixOS Discourse site - and the current status, which is experimental, is that a module is a function which gets some options and a pointer to nixpkgs, then operates on the big configuration attrset and returns an augmented version of it. That's handwaving, so let me show you bits of it: in modules/default.nix we have for example

  syslogd = options: nixpkgs: configuration:
    with nixpkgs;
    lib.attrsets.recursiveUpdate configuration {
      services.syslogd = {
        start = "/bin/syslogd -R ${options.loghost}";
        depends = ["eth0.2"];
      };
    };

and then in backuphost.nix we have

let modules = (import ./nixwrt/modules/default.nix);
    # ...
    wantedModules = with modules; [
      (rsyncd { password = rsyncPassword; })
      sshd
      (syslogd { loghost = "192.168.0.2"; })
      (ntpd { host = "pool.ntp.org"; })
      (dhcpClient { interface = "eth0.2"; inherit busybox; })
    ];
    configuration = lib.foldl (c: m: m nixpkgs c) baseConfiguration wantedModules;

This differs from the NixOS module system because we pass per-module config to the module itself instead of having it root around in one big configuration attrset. (In theory this means we could have two modules with the same name but differently customised, which might be useful). But it's also dependent on the order that the module functions are applied in, which makes me feel it would be nice to do some kind of fixpoint thing the way that overlays do. Or at least to find some nice way to have modules add their configuration to busybox and for them to be able to refer to busybox and for it to be the same busybox derivation used by all modules. The same consideration may very well apply to the kernel.

Anyway, it may be that I need to spend a bit more time on this before I understand why NixOS modules do it differently and I should switch to their approach, or it may be that my requirements are not those of NixOS.

In other news I have bought a proper USB TTL serial cable, so next time I crack open a new piece of router hardware I can plug it straight into a USB port on my desktop system instead of needing a Raspberry Pi as an sshable serial console. The next target is a TrendNET 712BR and I may have to think a bit about how to develop on it because unlike the MT300A or even the Yun it doesn't have an awful lot of spare RAM. Will have to think of something after I've found out how lobotomised its u-boot is or isn't.