* structured config for main config file allows to launch nagios in
debug mode without having to write the whole config file by hand
* build time syntax check
* all options have types, one more example
* I find it misleading that the main nagios config file is linked in
/etc but that if you change the link in /etc/ and restart nagios, it
has no effect. Have nagios use /etc/nagios.cfg
* fix paths in example nagios config files, which allows to reuse it:
services.nagios.objectDefs =
(map (x: "${pkgs.nagios}/etc/objects/${x}.cfg")
[ "templates" "timeperiods" "commands" ]) ++ [ ./main.cfg ]
* for the above reason, add mailutils to default plugins
Co-Authored-By: Aaron Andersen <aaron@fosslib.net>
Tests currently fail like this:
```
/nix/store/yslk7x7iw3hka6d33kmnba9sxaia4492-python3.7-mautrix-0.4.0/lib/python3.7/site-packages/mautrix/util/manhole.py:9: in <module>
from socket import SOL_SOCKET, SO_PEERCRED
E ImportError: cannot import name 'SO_PEERCRED' from 'socket' (/nix/store/81qani7sdir46gjwf3a3jr2cv1aggkz1-python3-3.7.5/lib/python3.7/socket.py)
!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!
=============================== 1 error in 1.73s ===============================
```
Those values don't seem to be available on the MacOS-version of that
module. As there's no workaround implemented in the source, I assume
that upstream doesn't intend to support darwin-alike platforms atm.
Idea shamelessly stolen from 4e60b0efae.
I realized that I don't really know anymore where I'm listed as maintainer and what
I'm actually (co)-maintaining which means that I can't proactively take
care of packages I officially maintain.
As I don't have the time, energy and motivation to take care of stuff I
was interested in 1 or 2 years ago (or packaged for someone else in the
past), I decided that I make this explicit by removing myself from several
packages and adding myself in some other stuff I'm now interested in.
I've seen it several times now that people remove themselves from a
package without removing the package if it's unmaintained after that
which is why I figured that it's fine in my case as the affected pkgs
are rather low-prio and were pretty easy to maintain.
