now nix-doc-munge will not introduce whitespace changes when it replaces
manpage references with the MD equivalent.
no change to the manpage, changes to the HTML manual are whitespace only.
make (almost) all links appear on only a single line, with no
unnecessary whitespace, using double quotes for attributes. this lets us
automatically convert them to markdown easily.
the few remaining links are extremely long link in a gnome module, we'll
come back to those at a later date.
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
For reference:
- ./nixos/modules/services/monitoring/grafana.nix
- 80192f1fe3/debian/service
- 5894b9b77a/trunk/prometheus.service
I have omitted the Limit* as they do not appear to be commonly used in
NixOS, and, per `man systemd.exec`, are less preferred vs. cgroup
limits.
The old way of writing the file omited qoutes within strings which are needed by some configurations like federations.
The quotes got lost when `echo`ing the content via `echo '${builtins.toJSON x}'`.
The pkgs.formats.json does handle that race condition properly, so this commit switches the writing to that helper.
Fixes race conditions like this:
> systemd[1]: Started prometheus-kea-exporter.service.
> kea-exporter[927]: Listening on http://0.0.0.0:9547
> kea-exporter[927]: Socket at /run/kea/dhcp4.sock does not exist. Is Kea running?
> systemd[1]: prometheus-kea-exporter.service: Main process exited, code=exited, status=1/FAILURE
When no devices are given the exporter tries to autodiscover available
disks. The previous DevicePolicy was however preventing the exporter
from accessing any device at all, since only explicitly mentioned ones
were allowed.
This commit adds an allow rule for several device classes that I could
find on my machines, that gets set when no devices are explicitly
configured.
There is an existing problem with nvme devices, that expose a character
device at `/dev/nvme0`, and a (namespaced) block device at
`/dev/nvme0n1`. The character device does not come with permissions that
we could give to the exporter without further impacting the hardening.
crw------- 1 root root 247, 0 27. Jan 03:10 /dev/nvme0
brw-rw---- 1 root disk 259, 0 27. Jan 03:10 /dev/nvme0n1
The autodiscovery only finds the character device, which the exporter
unfortunately does not have access to.
However a simple udev rule can be used to resolve this:
services.udev.extraRules = ''
SUBSYSTEM=="nvme", KERNEL=="nvme[0-9]*", GROUP="disk"
'';
Unfortunately I'm not fully aware of the security implications this
change carries and we should question upstream (systemd) why they did
not include such a rule.
The disk group has no members on any of my machines.
❯ getent group disk
disk❌6:
Otherwise, `postfix_up{path="/var/lib/postfix/queue/public/showq"}` will
always be `0` indicating an postfix outage because this is a unix domain
socket that cannot be connected to:
2021/12/03 14:50:46 Failed to scrape showq socket: dial unix /var/lib/postfix/queue/public/showq: socket: address family not supported by protocol
The option `services.prometheus.environmentFile` has been removed since it was causing [issues](https://github.com/NixOS/nixpkgs/issues/126083) and Prometheus now has native support for secret files.
The new option `services.prometheus.enableReload` has been introduced
which, when enabled, causes the prometheus systemd service to reload
when its config file changes.
More specifically the following property holds: switching to a
configuration (`switch-to-configuration`) that changes the prometheus
configuration only finishes successully when prometheus has finished
loading the new configuration.
`enableReload` is `false` by default in which case the old semantics
of restarting the prometheus systemd service are in effect.
9fea6d4c85 broke rtl_433-exporter by
introducing several hardening options which do not play well with
rtl_433 requiring writing to USB. More precisely, rtl_433 requires
(a) AF_NETLINK to configure the radio; (b) access to the USB device,
but PrivateDevices=true hides them; (c) rw access to the USB device,
but DeviceAllow= block-lists everything.
This commit was tested on real hardware with a standard NixOS setup.
The timex collector (enabled by default) needs the
adjtimex syscall, which was disabled by
9fea6d4c85.
So allow it unless the timex collector is disabled.
The systemd collector needs AF_UNIX to talk to
/var/run/dbus/system_bus_socket, which was broken
with 9fea6d4c85.
This commit allows AF_UNIX when needed.
In 0.3.0 of the json-exporter[1] it was switched to a different jsonpath
library which made some changes - especially for spaces in keys -
necessary. Also I decided to remove the pretty-printed JSON as this
would interfere with the bash quoting too much. If one needs
pretty-printed output, they can still pipe the output to `jq`.
[1] https://github.com/prometheus-community/json_exporter/releases/tag/v0.3.0
If `openFirewall = true`, but no `firewallFilter` is set, the evaluation
fails with the following error:
The option `services.prometheus.exporters.node.firewallFilter` is defined both null and
not null, in `/home/ma27/Projects/nixpkgs/nixos/modules/services/monitoring/prometheus/exporters.nix'
and `/home/ma27/Projects/nixpkgs/nixos/modules/services/monitoring/prometheus/exporters.nix'.
Originally introduced by me in #115185. The problem is that
`mkOptionDefault` has - as its name suggests - the same priority as the
default-value of the option `firewallFilter` and thus it conflicts if
this declaration and the actual default value are set which is the case
if `firewallFilter` isn't specified somewhere else.
Use new command-line flags of release 0.3.0 and always answer with the
expected XML in the VM test instead of using a test-specific fixed path.
Co-authored-by: ajs124 <git@ajs124.de>
* Content of `programlisting` shouldn't be indented, otherwise it's
weirdly indented in the output.
* Use `<xref linkend=.../>` in the release notes: then users can
directly go to the option documentation when reading release notes.
* Don't use docbook tags in `mkRemovedOptionModule`: it's only used
during evaluation where docbook isn't rendered.
For the same reason Alertmanager supports environmentFile to pass
secrets along, it is useful to support the same for Prometheus'
configuration to store bearer tokens outside the Nix store.
The format of the listenAddress option was recently changed to separate
the address and the port parts. There is now a legacy check that
tells users to update to the new format. This legacy check produces
a false positive on IPv6 addresses, since they contain colons.
Fix the regex to make it not match colons within IPv6 addresses.
systemd.exec(5) on DynamicUser:
> If a statically allocated user or group of the configured name
> already exists, it is used and no dynamic user/group is allocated.
Using DynamicUser while still setting a group name can be
useful for granting access to resources that can otherwise only be
accessed with entirely static IDs.
The postfix exporter needs to access postfix's `queue/public/` directory
to read the `showq` socket inside. Instead of making the public
directory world accessible, this sets the postfix exporter's group to
`postdrop` by default, when the postfix service is enabled.
Accessing the configured port of a service is quite useful, for example
when configuring virtual hosts for a service. The prometheus module did
not expose the configured por separately, making it unnecessarily
cumbersome to consume.
This is a breaking change only if you were setting `listenAddress` to
a non-standard value. If you were, you should now set `listenAddress`
and `port` separately.
If the host network stack is slow to start, the alertmanager fails to
start with this error message:
caller=main.go:256 msg="unable to initialize gossip mesh" err="create memberlist: Failed to get final advertise address: No private IP address found, and explicit IP not provided"
This bug can be reproduced by shutting down the network stack and
restarting the alertmanager.
Note I don't know why I didn't hit this issue with previous
alertmanager releases.
- Fix misspelled option. mkRenamedOptionModule is not used because the
option hasn't really worked before.
- Add missing cfg.telemetryPath arg to ExecStart.
- Fix mkdir invocation in test.
The allowed values have changed in bd3319d28c.
0.15:
--log.level="info" Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal]
--log.format="logger:stderr"
Set the log target and format. Example: "logger:syslog?appname=bob&local=7" or "logger:stdout?json=true"
0.17:
--log.level=info Only log messages with the given severity or above. One of: [debug, info, warn, error]
--log.format=logfmt Output format of log messages. One of: [logfmt, json]
* prometheus-nginx-exporter: 0.5.0 -> 0.6.0
* nixos/prometheus-nginx-exporter: update for 0.6.0
Added new option constLabels and updated virtualHost name in the
exporter's test.
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
This fixes an issue with a recent addition of a config file
check in c28ded36ef.
Previously it was possible to supply a path as a string
to `configFile`. Now it will fail checking the config file
during evaluation of the module due to sandboxing.
A toggle to disable the check, more informative log messages
and handling for various configFile values are added.
This option was added by mistake since `listenAddress` exists by default
for each prometheus-exporter. Using
`services.prometheus.exporters.wireguard.addr` will now cause a warning,
but doesn't break eval.
We don't want to ignore config that can mess up machines. In general
this should always fail evaluation, as you think you are changing
behaviour and don't, which can easily create run-time errors we can
catch early.
https://github.com/MindFlavor/prometheus_wireguard_exporter/releases/tag/3.1.1
This release adds a flag `-l` which takes an address where the exporter
is available. The default is `0.0.0.0` (previously, `0.0.0.0` was used
by default).
Please note that there are no dependency changes in Cargo and therefore
the cargo hash didn't change.
Prometheus2 does no longer support the command-line flag to specify
an alertmanager. Instead it now supports both service discovery and
configuration of alertmanagers in the alerting config section.
Simply mapping the previous option to an entry in the new alertmanagers
section is not enough to allow for complete configurations of an
alertmanager.
Therefore the option alertmanagerURL is no longer used and instead
a full alertmanager configuration is expected.
Since version 3.0 all allowed IPs and subnets are exposed by the
exporter. With `-s` set on the CLI, instead of a comma-separated list,
each allowed IP and subnet will be in a single field with the schema
`allowed_ip_<index>`.
This is a simple exporter which exports the information
provided by `wg show all dump` to prometheus.
Co-authored-by: Franz Pletz <fpletz@fnordicwalking.de>
This makes sure that when a user hasn't set a Prometheus option it
won't show up in the prometheus.yml configuration file. This results
in smaller and easier to understand configuration files.
We previously filtered out the `_module` attribute in a NixOS
configuration by filtering it using the option's `apply` function.
This meant that every option that had a submodule type needed to have
this apply function. Adding this function is easy to forget thus this
mechanism is error prone.
We now recursively filter out the `_module` attributes at the place we
construct the Prometheus configuration file. Since we now do the filtering
centrally we don't have to do it per option making it less prone to errors.
This results in a smaller prometheus.yml config file.
It also allows us to use the same options for both prometheus-1 and
prometheus-2 since the new options for prometheus-2 default to null
and will be filtered out if they are not set.
This results in a simpler service unit which doesn't first have to
start a shell:
> cat /nix/store/s95nsr8zbkblklanqpkiap49mkwbaq45-unit-alertmanager.service/alertmanager.service
...
ExecStart=/nix/store/4g784lwcy7kp69hg0z2hfwkhjp2914lr-alertmanager-0.16.2-bin/bin/alertmanager \
--config.file /nix/store/p2c7fyi2jkkwq04z2flk84q4wyj2ggry-checked-config \
--web.listen-address [::1]:9093 \
--log.level warn
...
As the configuration for the exporters and alertmanager is unchanged
between the two major versions this patch tries to minimize
duplication while at the same time as there's no upgrade path from 1.x
to 2.x, it allows running the two services in parallel. See also #56037
https://github.com/golang/go/issues/9334 describes how net.Listen (as used by Alertmanager):
* listens on 127.0.0.1 if the listenAddress is "localhost"
* listens on all interfaces if the listenAddress is ""
Instead of setting User/Group only when DynamicUser is disabled, the
previous version of the code set it only when it was enabled. This
caused services with DynamicUser enabled to actually run as nobody, and
services without DynamicUser enabled to run as root.
Regression from fbb7e0c82f.
This commit adds an assertion that checks that either `configFile` or
`configuration` is configured for alertmanager. The alertmanager config
can not be an empty attributeset. The check executed with `amtool` fails
before the service even has the chance to start. We should probably not
allow a broken alertmanager configuration anyway.
This also introduces a test for alertmanager configuration that piggy
backs on the existing prometheus tests.
With `promtool` we can check the validity of a configuration before
deploying it. This avoids situations where you would end up with a
broken monitoring system without noticing it - since the monitoring
broke down. :-)
