Install version 2.0.0p31 on Windows 2008 R1 (not R2)

[SwampdogMash (Andy)]

Hi all

Hope all is well wherever you are.

I know these are old versions and we are aware of the implications of not running the latest OS’s and CheckMK, but we have some constraints that we cannot work around in the industry we are in. We are currently running CheckMK version 2.0.0p31 and looking to upgrade some old clients from 1.6.0p10. some are Windows 2008 and some are Windows 2008R2

Having looked in Werks and on the forum, the implication is that the install should work, if the Legacy Python install is configured in a rule. We have tried this but still receive the error:

Agent update failed: OS it too old. Please, check the agent rule "Python environment" and set it to "Deploy Legacy environment"

Whilst we know 2008 is unsupported in the later versions of CheckMK, everything we have read seems to suggest it should work…

Werk saying 2008 should be ok

2.2.0 notification that 2008 is not supported now (implying it WAS previously)

“2.6. The Windows agent
In Checkmk 2.2.0, the Windows agent no longer supports Windows 6.0 (Vista and Server 2008 R1). However, on affected systems, the agent from 2.1.0 can still be used.”

It looks like something has gone a bit weird with the MSI as opening it up in 7Zip shows version 3.8 of python in there. Is there anything specific we should be looking for?

andy

EDIT:

For some additinoal info, we have tried doing an agent bakery cleardown by removing all the files in /omd/sites/uk_im/var/check_mk/agents/ and rebaking all the agents. This resulted in the same file size with the same hash, and the same python3.8.zip included in the MSI file. The HASH.conf file in the /omd/sites/uk_im/var/check_mk/agents/windows_msi/_PACKAGES folder also looks correct so is this a bug or have we missed something?

{'agent_encryption': False,
 'agent_paths': {'bin': '/usr/bin',
                 'config': '/etc/check_mk',
                 'lib': '/usr/lib/check_mk_agent',
                 'var': '/var/lib/check_mk_agent'},
 'agent_port': 6556,
 'check_mk_version': '2.0.0p31',
 'checkmk_agent_package': True,
 'cmc_real_time_checks': None,
 'file_hashes': {},
 'install_python': {'installation': 'install',
                    'python_env': '3.4',
                    'usage': 'auto'},
 'is_ipv6_primary': False,
 'package_name': 'check-mk-agent',
 'super_server': 'xinetd'}

[SwampdogMash (Andy)]

Hi all.

Anyone got any ideas on this one? I know these are old versions, but I cannot see anything in WERKS so far that suggests this is fixed up to say 2.0.0p38 - is this a bug?

Is there any way we can work around it to get agents to install on 2008R1 and R2 using Python 3.4 instead of 3.8?

Andy

[andreas-doehler (Andreas)]

You can only deploy the agent without the Python environment or you can try this rule.

The last line “Deploy legacy…” is important here.

[SwampdogMash (Andy)]

Hi @andreas-doehler. This is exactly what we have configured (set the legacy settings here) but the baked agent SAYS that it should have python 3.4, but the package contains 3.8… Tried this on 2 different installs of 2.0.0p31 server and got the same result, I wondered if this is some sort of bug. As per the screenshot below, the agent looks to be 3.4, but when downloaded it is actually 3.8 contained in the MSI package. (python_3.8.zip). It also is exactly the same size as the package that is supposed to have python 3.8…

For reference, the underlying Server OS of the CheckMK server is RedHat 7.9 (Maipo) in case this makes a difference to MSI generation in some way.

Any ideas?

Agent List - Extract from Bakery list

Contents of the MSI

[SwampdogMash (Andy)]

Hi everyone. I know that this is a bit of a stretch, quite old versions and a bit off the beaten track but can anybody give a hint as to what might be happening here?

Not sure how we can make this work on the unfortunately old versions of OS that we are forced to use to support production products that we have created historically that CANNOT be end-of-lifed, but still need old OS to support them.

It seems like the package creation part of the bakery is not working as expected on more than one installation of CheckMK which means either:

1. Both our builds have been done in a way which causes issue (possible)
2. something is not configured correctly (feels like things are correct, see above
3. There is something not quite right with CheckMK itself

Is there a workaround we could use for this in some way?

Andy

[SwampdogMash (Andy)]

It seems that the same behaviour is also replicable on version 2.1.0p17 of the server running on Red Hat Enterprise Linux Server release 7.9 (Maipo). Is this something to do with the underlying OS?

[lars.getwan (Lars)]

Hi Andy,

this looks like what you need: Correct processing of the rule Install Python runtime environment
Fixed in 2.1.0p25

Best regards
Lars