- Upgrade Nagios Core to 4.x
- Expose mainConfigFile and cgiConfigFile in module for finer
configuration control.
- Upgrade Plugins to 2.x
- Remove default objectDefs, which users probably want to customize.
- Systemd-ify Nagios module and simplify directory structure
- Upgrade Nagios package with more modern patch, and ensure the
statedir is set to /var/lib/nagios
Signed-off-by: Austin Seipp <aseipp@pobox.com>
music_directory "${cfg.musicDirectory}"
playlist_directory "${cfg.dataDir}/playlists"
db_file "${cfg.dataDir}/tag_cache"
state_file "${cfg.dataDir}/state"
sticker_file "${cfg.dataDir}/sticker.sql"
all refer to ${cfg.datadir}, which by default is "/var/lib/mpd/".
Parsing for instance ${cfg.datadir}/playlists results in:
/var/lib/mpd//playlists - NOT FOUND.
Currently, the restartTriggers are abusing the systemd unit file in that
the cfg.carbon.config/storageAggregation/... option text is pasted into
the unit file. Even though this sort-of works (the service is restarted
if the config changes) this causes systemd to print error messages about
invalid sections (rightfully so!).
The correct use of restartTriggers is to list storage paths, which is
what this change does. If any of the
cfg.carbon/config/storageAggregation/... options change, configDir will
get a new hash. It is not as "fine grained" as the current version, but
it is not abusing the interface.
Also, remove unneeded 'waitress' in one of the restartTriggers, because
it is already listed as part of the service config.
graphitePort must point to the port that carbon-cache listens on, not
the graphite webUI port.
With this change I finally got data from statsd to graphite.
It's "aggregation" with two 'g's.
Fixes this:
carbon-cache[9363]: [console] /nix/store/drxq4jj92sjk3cjik2l4hnsndbray3i4-graphite-config/storage-aggregation.conf not found, ignoring.
One reason for adding this is to make Chromium able to open files it has
downloaded.
Currently this happens:
/run/current-system/sw/bin/xdg-open: line 364: gnome-open: command not found
(And nothing happens in the GUI when clicking a downloaded file.)
Looking into xdg-open, one can see that it first tries to run gvfs-open
and then falls back to gnome-open. Adding 'gvfs' makes the first command
succeed.
Personal information management application that provides integrated mail,
calendaring and address book functionality
https://wiki.gnome.org/Apps/Evolution
This overhauls the Datadog module a bit to be much more useful. In
particular, it adds support for nginx and postgresql monitoring
integrations to dd-agent. These have to exist in separate files under
/etc/dd-agent, so the module just exposes then as separate options. In
the future, more integrations could be added this way.
In the process of doing this, I also had to rename the dd-agent user to
datadog. Note the UIDs did not change, so this is strictly backwards
compatible. The reason for this is to make it easier to create a
'datadog' postgres user with access to pg_stats, as 'dd-agent' typically
isn't a valid username. This allows the out of the box configurations to
be used.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Previously all card-specific stuff was scattered across xserver.nix
and opengl.nix, which is ugly. Now it can be kept together in a single
card-specific module. This required the addition of a few internal
options:
- services.xserver.drivers: A list of { name, driverName, modules,
libPath } sets.
- hardware.opengl.package: The OpenGL implementation. Note that there
can be only one OpenGL implementation at a time in a system
configuration (i.e. no dynamic detection).
- hardware.opengl.package32: The 32-bit OpenGL implementation.
Fixes#2379.
The new name was a misnomer because the values really are X11 video
drivers (e.g. ‘cirrus’ or ‘nvidia’), not OpenGL implementations. That
it's also used to set an OpenGL implementation for kmscon is just
confusing overloading.
The Tarsnap module is now far more flexible, allowing individual
archives with individual options to be specified at will, allowing
granular backup schedules, etc.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This fixes several problems in the dhcpcd service:
* A segfault during startup, due to a race with udev (dhcpcd would get
an ADD event from udev, causing it to re-add an interface that it
already had, leading to a segfault later on).
* A hang/segfault processing "dhcpcd rebind" (which NixOS calls after
waking up from suspend).
Also, add "lo" to the list of ignored interfaces. It usually ignores
"lo", but apparently not when it gets an ADD event from udev.
