I’m still new to NixOS, but created a working Package that uses a overlay.
I wanted to create a package that can be imported with a single import line, but be able to configure a systemd service, and that’s what I came up with: github.com/BenediktSeidl/nixos-check_mk_agent-overlay/
The Package itself is a shell script that can be further enriched by plugins which can be other shell scripts or python scripts. Until now only two plugins are implemented, but more could follow.
Is this the correct way to do it? How can the Package be improved? What best practice have I ignored? Where can I find more Information about writing Packages that are not part of the NixOS distribution?
I know this is an old thread and I don’t really have answers to your questions, other than it looks decent at a glance, but did you consider submitting a PR to nixpkgs for the derivation and the module?
I am in a situation in which I would like to have a checkmk agent running on a NixOS system as well and it would be great to just have it as part of nixpkgs.
You would probably get good feedback as part of the PR review process as well.
Thanks Benedikt! I’m currently using your package and it provides basic functionality to monitor NixOS servers. Now I was trying to quickly add monitoring for Varnish, which doesn’t seem to be easily possible.
my repo is in quite bad shape, sorry. i wanted to rewrite it, as it implements the plugin system in a very strange way, but never found time to do it. the checkmk version is also quite dated
thanks for the hint and the github ping, i would have missed it otherwise.
interesting to see how they implemented it. i have not implemented support for cmk-agent-ctl, my flake just opens a unencrypted tcp port. in my setup i have some firewall rules to make sure only the checkmk server can connect.
also interesting that they extract it from a rpm package. i think it should be relatively easy to build it from source.
full configuration and support for all official plugins is quite some work.
Yeah, it feels a bit like a prototype, but a working one at least!
I also did the same with the firewall, only our monitoring servers can access the TCP-Port.
That point with the RPM package is interesting, I’ll write another comment and will also mention that. Maybe you can also join the discussion in the issue, if you want!
To note for the discussion here, the RPM extraction was explained in the GitHub issue. We could “build” from upstream for the nixpkgs PR.
Currently I want to avoid this to keep a later integration of the agent bakery possible.
On another note, the overlay from @bese31 is probably the best solution if you want to keep it simple. We only built our own version mainly to have control over the updates/packaging and to enable TLS support.
On one hand I would like to keep it simple, on the other hand I also want to be able to add the plugins I need. On my non-nixos hosts I have monitoring for varnish enabled. Also redis is monitored via the plugin I get from the agents page of my CheckMK instance.
Our initial goal was to extract plugins bundled with bakery (in my understanding they are then put into the rpm/deb) into the package too. This is why unpacking the RPM (along with ensuring parity with other hosts) was my first approach.
We currently have no access to an enterprise-licensed instance though so that’s blocked until then.
what would your workflow look like?
open checkmk, configure agent, build agent. provide agent for download without auth so it can be accessed by the nix build process (?), adapt your local flake so the hash of the freshly baked agent match, roll it out on your nixos servers?
how do you support different bakery configuration for different hosts?
how do you want to support users of the raw edition that have no access to the agent bakery?
what would the workflow for regular nixos users look like if they want to configure the agent or plugins?
as you can probably imagine by now i would have preferred a way to have the agent configuration implemented in nix, so you don’t have to use the agent bakery at all. this way you have full flexibility, even if you use the raw edition.
downside of this approach: if you have a mixed environment (as you seem to have) you have to do the configuration twice: one time in checkmk with the agent bakery (for rpm and apt packages), another time in your nixos configuration.
BUT: don’t let you discourage by strangers on the internet! you have a working and up to date implementation, got some thumbs up by nixos maintainers. keep going
I am sorry but supporting the agent bakery is not on the horizon for me as I do not have a use case for that feature.
If anyone wants to contribute they are welcome to do so.
When you look at the “newer version” of the PR you might notice it is now built from source. We first built the cmk-agent-ctl as well as the waitmax binary and then simply wrap them in the next step…
