This reverts commit 413011ddf4.
Using separate lockfile directories prevents the different kea daemons
from using the interprocess sync lockfile.
Keeping the runtime directory around might be the better approach.
This is necessary to allow the usbhid driver to successfully send
commands to the attached UPS.
It is possible to work around this by explicitly using setting the user
flag (e.g. `upsdrvctl -u root shutdown`), though it is much simpler to
install the udev rules rather than patch things further.
Deprecation warning: The standalone 'grafana-server' program is deprecated and will be removed in the future. Please update all uses of 'grafana-server' to 'grafana server'
The error message was:
msg="Failed to read plugin provisioning files from directory" path=/nix/store/gs2cy8n6ndsa1f7msf7ndl8f85xl1pzg-grafana-provisioning/plugins
error="open /nix/store/gs2cy8n6ndsa1f7msf7ndl8f85xl1pzg-grafana-provisioning/plugins: no such file or directory"
Closes#216989
First of all, a bit of context: in PostgreSQL, newly created users don't
have the CREATE privilege on the public schema of a database even with
`ALL PRIVILEGES` granted via `ensurePermissions` which is how most of
the DB users are currently set up "declaratively"[1]. This means e.g. a
freshly deployed Nextcloud service will break early because Nextcloud
itself cannot CREATE any tables in the public schema anymore.
The other issue here is that `ensurePermissions` is a mere hack. It's
effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how
a value is substituted in a query. You'd have to parse a subset of SQL
to actually know which object are permissions granted to for a user).
After analyzing the existing modules I realized that in every case with
a single exception[2] the UNIX system user is equal to the db user is
equal to the db name and I don't see a compelling reason why people
would change that in 99% of the cases. In fact, some modules would even
break if you'd change that because the declarations of the system user &
the db user are mixed up[3].
So I decided to go with something new which restricts the ways to use
`ensure*` options rather than expanding those[4]. Effectively this means
that
* The DB user _must_ be equal to the DB name.
* Permissions are granted via `ensureDBOwnerhip` for an attribute-set in
`ensureUsers`. That way, the user is actually the owner and can
perform `CREATE`.
* For such a postgres user, a database must be declared in
`ensureDatabases`.
For anything else, a custom state management should be implemented. This
can either be `initialScript`, doing it manual, outside of the module or
by implementing proper state management for postgresql[5], but the
current state of `ensure*` isn't even declarative, but a convergent tool
which is what Nix actually claims to _not_ do.
Regarding existing setups: there are effectively two options:
* Leave everything as-is (assuming that system user == db user == db
name): then the DB user will automatically become the DB owner and
everything else stays the same.
* Drop the `createDatabase = true;` declarations: nothing will change
because a removal of `ensure*` statements is ignored, so it doesn't
matter at all whether this option is kept after the first deploy (and
later on you'd usually restore from backups anyways).
The DB user isn't the owner of the DB then, but for an existing setup
this is irrelevant because CREATE on the public schema isn't revoked
from existing users (only not granted for new users).
[1] not really declarative though because removals of these statements
are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467
[2] `services.invidious`: I removed the `ensure*` part temporarily
because it IMHO falls into the category "manage the state on your
own" (see the commit message). See also
https://github.com/NixOS/nixpkgs/pull/265857
[3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";`
[4] As opposed to other changes that are considered a potential fix, but
also add more things like collation for DBs or passwords that are
_never_ touched again when changing those.
[5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
https://learn.netdata.cloud/docs/logs/systemd-journal/
need acces to
Kernel Logs (dmesg):
Capability: CAP_SYSLOG
Description: This capability allows the program to read kernel logs using the dmesg command or by reading the /dev/kmsg file.
System Logs (e.g., /var/log/syslog):
Capability: CAP_DAC_READ_SEARCH
Description: This capability allows the program to read system logs located in directories such as /var/log/.
User Logs (e.g., /var/log/auth.log):
Capability: CAP_DAC_READ_SEARCH
Description: This capability allows the program to read user logs located in directories such as /var/log/.
Kea may clean the runtime directory when starting (or maybe systemd does
it). I ran into this issue when restarting Kea after changing its
configuration, so I think the fact it normally doesn't clean it is a
race condition (it's cleaned on service start, and normally all Kea
services start at roughly the same time).
The previous implementation works fine when the plugins do not already
contain store paths, which is the case for stuff from munin-contrib.
However, for plugins generated via nix (e.g. with writeShellScriptBin),
it tries to fix the paths in it which already point to the nix store,
ruining everything.
If extraAutoPlugins contains values that carry context (e.g. it comes
from a flake input), the keys generated from them using baseNameOf
inherit that context and the config doesn't compile.
This doesn't actually need to be an attrset anyways, so a bit of
internal refactoring lets us fix this without changing the visible API.
The new exporter has proper console scripts definition, that sets up
another executable name.
The package now also shells out to pidof, which is why we require procps
in the unit PATH.
follow-up on 28b3156bc6 which broke
when tokenFile was left empty.
Making both options nullable also allows us to provide a more meaningful
error message when neither authentication method is configured.
The problem we had back then was that `mkRenamedOptionModule` doesn't
work if an option will be moved a level depper, i.e.
services.grafana.provision.dashboards
became
services.grafana.provision.dashboards.settings.provider
I actually planned to remove this before 23.05 (since the change was
already released in 22.11), but as you can see that didn't happen ;-)
I think the grace-period was quite long already. And if someone is
migrating from <22.11 to a current NixOS now, there are very precise
instructions on how to upgrade in the 22.11 release notes.
Having undisclosed recipients results in emails being considered spam as mentioned in #192147, by instead identifying the recipient the emails are no longer considered spam
Netdata creates its control socket at /tmp/netdata-ipc by default, which
is insecure and actually inaccessible with systemd's PrivateTmp enabled.
Originally we patched its source code to move the socket to
/run/netdata/ipc. However, it was removed due to incompatibility when
upgrading to v1.41.0: 1d2a2dc7d0
Fortunately, this new version of netdata adds support for setting the
location of the control socket via the environment variable
NETDATA_PIPENAME. So let's set it for the netdata service and the
command line utility so that they can communicate properly.
Because the local database is used by the osquery deamon, running
osqueri fails with:
IO error: While lock file: /var/lib/osquery/osquery.db/LOCK: Resource temporarily unavailable
I went through all categories that were already present in the grafana
module and added most options from the official docs at
https://grafana.com/docs/grafana/v9.5/setup-grafana/configure-grafana/
I also modified the descriptions of some existing options to match the
official docs more closely.
Previously, we hardcoded a 60 second timer to stop netdata if we didn't have any answer back.
This is wrong and can cause data loss because the SIGTERM sent by systemd can sometimes be not honored.
Which in turn becomes a SIGKILL, causing potential data loss / corruption.
Offer a flag to users and bump the deadline to 2 minutes.
and `lib.getExe` allows a safe handling and potential backport of this.
But for that to work it would require 22.11 to set `pkgs.grafana-agent.meta.mainProgram = "agent"`
Relevant upstream release: https://github.com/grafana/agent/releases/tag/v0.31.0
This commit deletes the assertions that were added in 4ec456b. Those
assertions weren't even working to begin with, and they also cause
assertions leak into the generated YAML.
Invoking cadvisor sent the command line parameter `-storage_driver_user` twice, once passing `cfg.storageDriverHost`. Fix the typo and pass the host config option to the command line parameter `-storage_driver_host`
this converts meta.doc into an md pointer, not an xml pointer. since we
no longer need xml for manual chapters we can also remove support for
manual chapters from md-to-db.sh
since pandoc converts smart quotes to docbook quote elements and our
nixos-render-docs does not we lose this distinction in the rendered
output. that's probably not that bad, our stylesheet didn't make use of
this anyway (and pre-23.05 versions of the chapters didn't use quote
elements either).
also updates the nixpkgs manual to clarify that option docs support all
extensions (although it doesn't support headings at all, so heading
anchors don't work by extension).
apparently pandoc has changed behavior over the past releases, so the
files are no longer in sync. occasionally this requires edits
to the markdown source to not remove an anchor that was there
before (albeit wth a very questionable id), or where things were simply
being misrendered due to syntax errors.
This ensures that the CLI is in sync with the service configuration.
(I tried building apcupsd with --sysconfdir=/etc instead, but it wants
to install stuff there at build time, so I backed out.)
Fixes https://github.com/NixOS/nixpkgs/issues/208204.
Setting up the DeviceAllow list with explicitly configured devices was a
nice idea, but sometimes a configured device (`/dev/nvme0n1` an NVMe
namespace) has a parent device (`/dev/nvme0`) that smartctl needs to
access to query metrics.
Falling back to the block and character definitions is probably a valid
fallback.
Closes#198646
* The options `password`/`basicAuthPassword` were removed for
datasources in Grafana 9. The only option to declare them now is to use
`secureJsonData`.
* Fix description for contactPoints provisioning: when using file/env
providers, nothing will be leaked into the store.
* Fix regex in file-provider usage check: it's also possible to either
use `$__env{FOO}` or `$FOO` to fetch secrets from the environment.
* Fix warning for datasources: `password`/`basicAuthPassword` was
removed, also check for each setting in `secureJsonData` if
env/file-provider was used (then no warning is needed!).
The hack with `either` had the side-effect that the sub-options of the
submodule didn't appear in the manual. I decided to remove this because
the "migration" isn't that hard, you just need to fix some module
declarations.
However, `mkRenamedOptionModule` wouldn't work here because it'd create
a "virtual" option for the deprecated path (i.e.
`services.grafana.provision.{datasources,dashboards}`), but that's the
already a new option, i.e. the submodule for the new stuff.
To make sure that you still get errors, I implemented a small hack using
`coercedTo` which throws an error if a list is specified (as it would be
done on 22.05) which explains what to do instead to make the migration
easier.
Also, I linkified the options in the manual now to make it easier to
navigate between those.
See the discussion below the original PR[1] and #197443 for more
context.
I guess I missed that upon review because the branch was too old and I
cherry-picked the commit onto my deployment branch which is based on
22.05. Sorry for that!
[1] https://github.com/NixOS/nixpkgs/pull/162784#issuecomment-1306848036
Netdev collector needs AF_NETLINK permissions to work. It will fail with
the message "couldn't get netstats: socket: address family is not
supported by protocol" otherwise.
This commit refactors `services.grafana.provision.datasources` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
This commit refactors `services.grafana.provision.dashboards` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
The current `ExecStart` will not allow for multiple sockets to properly
be passed to the program since the extra newline character is interpreted to
be part of the socket path.
