EPEL 8 Repos do not include check-mk

CMK version:
N/A
OS version:
RHEL8
Error message:
EPEL No longer contains the checkmk packages

I have searched this site for quite some time and find no reference to this issue.
We were mirroring EPEL for our internal installation of check-mk-agent. As of RHEL8, the EPEL 8 repos here:

dl.fedoraproject.org/pub/epel/
https://dl.fedoraproject.org/pub/epel/8/Everything/SRPMS/Packages/c/

do not contain check-mk.

We are a fully automated environment, and are curious as to whether the check-mk-agent will be returning to EPEL in its RHEL8 iteration?

It still is present in the EPEL 7 repos, so it stands to reason EPEL 8 should have it too.

Hi @cvquesty

I hardly believe that people in the Checkmk forum can answer
something that is referring to… EPEL. :slight_smile:

Be that as it may, whether it is or isn’t in EPEL, you’d probably
wouldn’t want it from anywhere else than the Checkmk server itself,
anyway.

Especially if you use one of the commercial editions, agents are fully
equipped with all plugins and all necessary configuration through the
bakery.

No public repository, will ever provide agents like that. And even if
it were the “plain” agent, you’re still “better off” getting it from the server
itself, because it’ll be the one that “fits”.

No one hinders you, to take those agents then - either your baked
ones or the “raw” ones - and “integrate” them into
your “fully automated environment”.

E.g. we do have YUM repository servers. We just take the agent
RPM, move it into a repository, and then we distribute it
as if it were any other software.

HTH,
Thomas

1 Like

It’s primarily that the install documentation lists a procedure to install from EPEL, but that doesn’t work for RHEL8 due to the fact the repos do not contain the agent.

Yes, we will need to use a yum/dnf repo, and will likely mirror into our airgapped environment eventually. We are already irroring EPEL 7/8/9 adn my guess is we selected check-mk because it was present in the RHEL 7 repos. Bot now that we’re upgrading everything to RHEL 8, we’re noticing it isn’t even available at EPEL.

We’re using “raw”, and I just took over this environment.

I just spemt quite some time looking for any reference to these yum servers you refer to here. The documentation only refers to EPEL, and there is no documented reference to your own Yum repos. Could I get a little help on that?

In EPEL 7 you have Checkmk Agent 1.4… :rofl:

We also run a fully automated environment but since 2.0 we can download the baked agent for that specific host we find that much more secure.

1 Like

Hi Jerald

Unless I misunderstand you, the official Checkmk documentation refers to EPEL for the Checkmk server installation, not the agent. [1]

To install the Checkmk agent the official documentation refers to one’s own server. [2]

No, using one’s own repository servers is not part of the official Checkmk documentation,
that is something we happen to use, and I shared it with you.

Based on your statements, you could “abuse” your existing repository servers, then, too. I’m sure your administrators know how to create an additional repository for them, but if needed, I found a - quite extensive - article from IBM/RedHat describing how to create one [3].

HTH,
Thomas

Links:
[1] Installation on Red Hat and derivatives
[2] Monitoring Linux - Downloading RPM/DEB packages
[3] Create an Apache-based YUM/DNF repository on Red Hat Enterprise Linux 8

1 Like

Yeah, I already created a repo and dropped the single file I need into it.

The main problem I have is the documentation says one thing and I come on here and everyone is treting me like an idiot because I, oh I don’t know, RTFM. The downloads are hidden behind a bunch of active web-gyrations rather than just providing a yum repo over the download, and I had to create one myself. Further, the repos which checkmk’s own docs say should contain their tool AND is the only documented method of installation on RHEL-family hosts doesn’t even exist at EPEL, rendering all documentation completely null and void.

I’m just saying “do better”. If a tool wants to be taken seriously, then put the darned thing in the repos (EPEL allows for owner changes) and have your documentation reflect reality. I really don’t think that’s too much to request.

Anyhow, I solved my own problem, and will DEFINITELY be looking for a replacement tool.

Hi Jerald,

welcome to the Checkmk community!

Thomas already answered most of the questions. I just want to clarify some viewpoints of Checkmk GmbH:

We are aware of several distributions providing or having provided the Checkmk agent as part of some kind of “universe” or community maintained package repositories. Since this might or might not conflict with agents installed via the bakery (commercial editions) or deployed by Ansible (all editions), we never put much energy into “mainlining” the agent.

Same goes for the Checkmk server: If I remember correctly, there were some non OMD packages of Checkmk included in several distributions around 2013 or 2014 that installed a bunch of dependencies (Nagios, rrdtool, WATO…) to build a working Checkmk. (Disclaimer: back then, I was only a watcher and IT journo, no crew member) For consistency, non OMD Checkmk has been ceased long time ago and things like the OpenSSL 3 stuff (see the blog) proves this right.

So, since commercial editions are going to be free to test in the mid-term, providing our own repos will be a way to go in the near future, mainlining to distributions probably will never happen.

I assume, your environment has some quite old Checkmk servers and agents. So you should probably start updating everything. As a rule of thumb: All 1.x versions of Checkmk should be considered insecure. And Checkmk 2.0 also recently went out of support, but might still get fixes for crucial security issues.

Thus: Let’s update your environment to the latest Checkmk. I am quite sure, you will at least understand some architecture decisions (I do not support them all, still I have to explain them).

Now I am curious: Which version is your Checkmk environment?

4 Likes

BTW: Since my job is documenting stuff, I always want to know what is wrong about the manual. What is hard to find? Which behavior of Checkmk seems illogical? Which architectural decisions need more explanation?

With all due respect, this is untrue. Unless you can point me to where it says, that we as Checkmk host YUM repositories. The official guide only mentions EPEL, as on some RedHat derivates, you need to enable EPEL, so the Checkmk server setup can pull dependencies from there.

As already said, due to the architecture of Checkmk, you typically install the server from the setup file downloaded from our download portal and then download the agent setups from your Checkmk server.

Most of the time, when someone refers to YUM/APT repositories, they are internal repositories created by and for that specific organization.

Lastly I want to say I am sorry, that you feel like Checkmk is not the right tool for you. I am sure, no one here intended to be offensive or aggressive towards you. Yes, Checkmk can be daunting to get started with, especially inheriting it and yes, sometimes folks around here (including myself) forget, how hard first steps with Checkmk can be. From what I am reading, all of this is a big misunderstanding, which I would love to resolve, if you are willing to give it another try.

4 Likes

3 posts were split to a new topic: How to do automatically download the Checkmk agent