Custom Local Path

Guten Tag zusammen

Ich würde gerne den Local-Pfad auf “C:\Scripts\CheckMK\local” umstellen. Leider klappt dies bei mir nicht. Wo kann ich genau die Variabel “$CUSTOM_LOCAL_PATH$” definieren? Ist dies eine Umgebungsvariabel?

System: Windows Server 2016
CheckMK: RAW 1.6.0p19

Ich habe zudem versucht die Check_mk.user.yml anzupassen:
local:
enabled: yes

    # max_wait: 60 # max timeout for every sync plugin. Agen will gather plugins data no more than max_wait time.
                   # this is useful to terminate badly written or hanging plugins   

    # async_start: true # start plugins asynchronous, this is normal mode. 

    # patterns will be scanned up down, 
    # configuration is assigned to the first found file matching the pattern 
    execution:
        - pattern     : 'C:\Scripts\CheckMK\local*.*'           # in the local folder.
          timeout     : 180              # in seconds, after expiring timeout all processes matching the pattern will be killed.
          run         : yes             # ALL FOUND files ARE ENABLED

Dies hat leider auch nicht geklappt.

Vielen Dank für eure Hilfe!

Gruss
Robin

Hier sollte soweit ich das seh nur ein “\” fehlen hinter local.
Es kommt aber noch der Einwand wenn ich die YAML Datei richtig lese, dass kein anderes Verzeichnis wie das Default Verzeichnis für Local Checks verwendet werden kann.

Also nix mit eigenem Verzeichnis außerhalb.

Ja sehe ich leider auch so. Es geht auch mit “” nicht.
Wie kann der Ordner bzw. der Ort global überschrieben/umgeleitet werden?

Gar nicht soweit ich das sehe.

Mit einem Symlink könnte es funktionieren: mklink /J C:/ProgramData/checkmk/agent/local C:\Scripts\CheckMK\local (zuerst den local-Ordner löschen: rmdir C:/ProgramData/checkmk/agent/local)

Aber warum gibt es dann die Variable $CUSTOM_LOCAL_PATH$, wenn man sie auf keine Art anpassen kann? Es steht ja CUSTOM im Name. :face_with_monocle: Bin etwas verwirrt… :no_mouth:

Hat niemand vom CheckMK-Support eine Antwort oder muss ich ein Ticket erstellen?

Wir können ja mal @SergejKipnis fragen :wink:

Ich habe mir meine check_mk.user.yml Datei angesehen und $CUSTOM_LOCAL_PATH$ sieht für mich wie ein Macro aus.

$BUILTIN_AGENT_PATH$ -> is C:/Program Files(x86)/check_mk_service/
$BUILTIN_PLUGINS_PATH$ -> is C:/Program Files(x86)/check_mk_service/plugins
$CUSTOM_AGENT_PATH$ -> is C:/ProgramData/CheckMK/Agent/
$CUSTOM_PLUGINS_PATH$ -> is C:/ProgramData/CheckMK/Agent/plugins
$CUSTOM_LOCAL_PATH$ -> is C:/ProgramData/CheckMK/Agent/local

Die folgende Konfiguration funktioniert bei mir.

# ProgramData/checkmk/agent/local folder
local:
    enabled: yes

    # max_wait: 60 # max timeout for every sync plugin. Agen will gather plugins data no more than max_wait time.
                   # this is useful to terminate badly written or hanging plugins   


    # async_start: true # start plugins asynchronous, this is normal mode. 

    # patterns will be scanned up down, 
    # configuration is assigned to the first found file matching the pattern 
    execution:
        - pattern     : $CUSTOM_LOCAL_PATH$\mylocal2*   # Plugin name. * and ? are allowed
          async: no                    # default is no
          #timeout     : 35              # after 35 seconds process will be killed, default is 60 in check_mk.yml
          run         : yes             # execute this plugin.
          async       : yes
          cache_age   : 1000

        - pattern     : '*.*'           # in the user folder. DO NOT REMOVE THIS ENTRY
          run         : yes             # Do not run any files matching this pattern

Hallo,

Der Agent ist so aufgebaut, dass er nur zwei Verzeichnisse kontrolliert: eines mit Core-Binärdateien und ein weiteres mit Bakery&User-Dateien. Beide Verzeichnisse befinden sich immer in Windows-Systemordnern und erhalten einen zusätzlichen Schutz durch das Betriebssystem (mit 100% Garantie).

Nur zur Erinnerung: Der Agent hat die Fähigkeit, automatisch bereitgestellt und aktualisiert zu werden. Auch der Agent ist eine kritische Server-Software, und wir wollen sogar potenzielle Komplikationen und mögliches Chaos wegen der Installation in beliebigen Verzeichnisse zu vermeiden.


P.S. In der Vergangenheit hatten wir die Möglichkeit diskutiert, eigene Makro-Werte zu definieren(oder CUSTOM_LOCAL_PATH zu re-definieren).
global:
defs:
MY_OWN_DIR=‘c:\myscripts\something’
CUSTOM_LOCAL_PATH= ‘d:\scripts’
-pattern:
$MY_OWN_DIR$\local

Das Feature sieht als etwas kompliziert und nicht so wichtig aus.

2 Likes

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.