[BUG] 1.6.0-daily - Agent Bakery - Deploy custom files on Windows: wrong bin path

Hello,
I think I have found a small bug in the bakery (1.6.0-2020.11.12.cee) when a custom script should be deployed into bin on a windows host.

There is one custom package defined:

OMD[cmk]:~/local/share/check_mk/agents/custom$ tree
.
`-- robotmk-plugin
    `-- bin
        `-- robotmk.py

It is shown and activated in the rule I am configuring for a Windows host:

image

After baking and installing the agent, the script is not placed in the bin folder, but inside the agent folder:

image

I have debugged the agent_bakery.py script and have found that in case of Windows the middle_path is empty; it should be bin:

image

This is how the middle_path gets set correctly on my side:

image

image

Probably not the best and final solution… perhaps someone from tribe29 can have a look on this.
Thanks,
Simon

The Windows agent does not have a standard bin directory. Maybe that’s why it is not used.

When deploying custom files to a Linux agent files in a bin subdirectory land in /usr/bin.

I think @simonm’s argument is valid and i would also title this as a agent bakery bug.
If @SergejKipnis can have a look it would also help if this not also happens in 2.0 :slight_smile:
As the code is complete different in 2.0 agent_bakery.py and i had no time to test, i don’t know if the same problem exists there.

Just to play safe, can anybody reproduce this behaviour?

@r.sander I have just done again a Vanilla agent installation, it contains a bin directory on my VM:
image

Regards,
SImon

Oh, I stand corrected.

Hi all,

a quick check of the context help within Checkmk states the following:

Note: When using the windows agent, all logical paths point to the same location - the agent installation dir.

I know that this is also not exactly what is happening, because the files are put into “ProgramData” and not into the same directory as check_mk_agent.exe, but let’s just say that the deployment to subdirectories is just not implemented for Windows hosts.

Hi,

the deployment to subdirectories is just not implemented for Windows hosts

Sorry, I don’t agree in this point. It is possible for the windows agent bakery to deploy files already in /ProgramData/checkmk/agent/config and /ProgramData/checkmk/agent/plugins without any modification.

and not into the same directory as check_mk_agent.exe

In fact, this would be the totally wrong place. It would mix up stock files with user/custom files.

From my understanding, the paths below /ProgramData/checkmk/agent/ are the right place to store custom files (in plugins, config etc.) - and with the small patch above it is possible for /ProgramData/checkmk/agent/bin, too.

Regards,
Simon

Hi Simon,

of course, ProgramData is the right place. I never doubted that. I am just saying, that the context help in Checkmk in not very precise here. We probably forgot to update it, when we split the files between the directories ProgramData and ProgramFiles (x86).

That does not change the fact, that this feature of deploying custom files to sub-directories on Windows hosts, was ever supposed to work as you expect.

The fact that this seems to work for /config and /plugins would rather be the uninteded behaviour (i.e. bug). The only directories that are supposed to be conisder here are also stated in the context help:

Within a package folder you can create the following subfolders: lib, bin, var, config. These folders are the logical target paths for the files.

But as I said before, not for Windows.

Hi,

(if I understand this issue correctly) it also works for Windows:

OMD[test]:~/local/share/check_mk/agents/custom/Check-Test$ tree
.
└── lib
    └── local
        └── Check-Test.ps1

2 directories, 1 file

will go to C:\ProgramData\checkmk\agent\local\Check-Test.ps1

it also works for Windows:
will go to C:\ProgramData\checkmk\agent\local\Check-Test.ps1

Hm… If your package path was lib/local/, where did the lib part go on windows?

‘lib’ is on Windows the folder "C:\programdata\checkmk\agent"

Hi Andreas,

‘lib’ is on Windows the folder “C:\programdata\checkmk\agent”

Maybe, but intentional?
This seems more like a bug to me. It looks like the first path element in both cases (bin in my, lib in Christophs case) simply gets stripped. This is why Christoph is getting local and my script is placed in C:\programdata\checkmk\agent.

Regards,
Simon

Yes
From the “quick help” - When using the windows agent all logical paths point to the same location. The agent installation directory (this was 1.5 since 1.6 it is the C:\programdata.…)

I have found out this now on a fresh CMK 1.6.0p19.cee site:

Created custom file packages for Windows & Linux:

OMD[deploy19]:~/local/share/check_mk/agents/custom/mycustomfiles_linux$ tree
.
|-- bin
|   `-- foo_in_bin.txt  
|-- config
|   `-- foo_in_config.txt
|-- lib
|   `-- foo_in_lib.txt
`-- var
    `-- foo_in_var.txt

4 directories, 4 files

OMD[deploy19]:~/local/share/check_mk/agents/custom/mycustomfiles_windows$ tree
.
`-- lib    #  <---- !!!
    |-- bin
    |   `-- foo_in_bin.txt
    |-- config
    |   `-- foo_in_config.txt
    |-- lib
    |   `-- foo_in_lib.txt
    `-- var
        `-- foo_in_var.txt

5 directories, 4 files

(watch the additional “lib” folder for Windows)

Then I installed the agent package (with either the linux/windows custom file package):

On Linux:

locate foo_in_ | grep -v omd
/etc/check_mk/foo_in_config.txt
/usr/bin/foo_in_bin.txt
/usr/lib/check_mk_agent/foo_in_lib.txt
/var/lib/check_mk_agent/foo_in_var.txt

On Windows:

image

=> On Windows, the upper “lib” folder is needed to place the files correctly in subfolders bin,config,lib and var of C:\programdata\checkmk\agent. Then everything seems to work as expected.

Ok that makes sense :slight_smile:

Hi, guys!

I would say, that this feature hasn’t been released yet. It was “a bit” implemented somewhere in 1.2 and now has undocumented(experimental) status.

Also, I would suggest requesting a development “custom files for Windows”.

If you really need it, write to me directly.

2 Likes

Hi Sergej,
thanks for your message.
We have discussed this, and as we found out that this additional “lib” folder obviously produces the expected results on Windows, we don’t need any change/fix.
Thanks & regards,
Simon

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact @fayepal if you think this should be re-opened.