*-version: Curl from https://endoflife.date first, then use hardcoded version

[seraphyn]

Describe the solution you'd like

In the Iciniga plugin gitlab-version the current version of gitlab is hardcoded (Line 31 - Line 275).

It would be good if there was an option here that pulls the latest released version of gitlab from the internet.

As an example:

➜  ~ curl -s https://gitlab.com/api/v4/projects/278964/releases/ | jq '.[]' | jq -r '.name' | head -1
GitLab 15.11

Many greetings and thanks for the plugins

Christian

Additional context

No response

[markuslf]

Hmmm... in a datacenter environment, the majority of admins voted for offline capabilities of the plugins.

If we fetch version info from Github & Co. (what we did in the past), we only know that there is a new version, not whether it is end-of-life. Experience has shown that the "beware, you are running 1.2.3, but there is 1.2.4 available" warning is not effective in a datacenter environment - it is much more important to know if it is EOL.

Thinking out loud:

• A myproduct-eol (can stay offline) plugin plus myproduct-version (goes online to Github or product pages, the "old" behavior).
• Or the current *-version plugins try to get the EOL info from https://endoflife.date, and only if that fails after a reasonable timeout (3 seconds) they use their built-in offline info.

Currently I prefer the latter, but have to think about this.

[slalomsk8er]

I would like to know 2 things from a version check:

1. is it EOL
2. is there a security update that requires me to immediately plan a change

In general terms I would like a switch to enable online requests but for GitLab specifically one can just ask it, if it's up to date: https://gitlab.example.com/admin/version_check.json {"latest_stable_versions":["16.0.1"],"latest_version":"16.0.1","severity":"success","critical_vulnerability":false,"details":""} https://about.gitlab.com/handbook/sales/process/version-check/#use-the-internal-api-to-check-the-cache

[markuslf]

In summary, we will improve this and most of the current "version" plugins like this:

1. Try to get EOL data online from https://endoflife.date
2. If this fails within 7 seconds (default), we will use the built-in offline data to check for EOL.
3. Try to get additional information about outstanding security patches as suggested by @slalomsk8er (depends on the application, of course).

Plugin will raise an alert when

1. Product reaches EOL in the next 30 days (default)
2. A security patch is available

[seraphyn]

That sounds wonderful, thank you

[markuslf]

Re-opened, we still need to implement this. ;-)

[markuslf]

Now fetching info from https://endoflife.date first, then reading from local file (requires updated libraries):

• apache-httpd-version
• fedora-version
• fortios-version
• gitlab-version
• grafana-version
• keycloak-version
• mysql-version
• nextcloud-version
• php-version
• postfix-version
• postgresql-version
• rhel-version
• wordpress-version

[markuslf]

Moving the "check for gitlab security patches" feature request to the new ticket https://github.com/Linuxfabrik/monitoring-plugins/issues/688