[solved] SSH Remote Befehl wird nicht ausgeführt (Nagios Event Handler)

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo!


    Da ich einfach mal davon ausgehe, dass es sich primär um mein menschliches (Linux-)Versagen handelt als um meine Nagios-Kenntnisse, kommt das Thema in den Linux-Bereich :)


    Ich versuche mich kurz zu halten: Gedacht is eine simple Testumgebung mit einem OMD 0.56 auf einem Centos 6.4 x64.
    Ziel: Einen Dienst (hier xinetd) eventgesteuert zu starten, wenn dieser nicht mehr läuft.
    Problem: Das Kommando, dass ich dem ssh Befehl in meinem Bash-Script übergebe, wird scheinbar nicht ausgeführt.


    Ich fange einfach mal an. Hier die Service-Definition (angemerkt sei, dass die Definition völlig aus der Luft gegriffen ist und einfach nur einen Dummy darstellt):


    Code
    1. define service{
    2. host_name centos
    3. service_description Check MK
    4. max_check_attempts 4
    5. event_handler restart-xinetd
    6. check_command check-mk
    7. retry_interval 1
    8. }


    Weiter geht es mit der Command-Definition:


    Code
    1. # XINETD RESTART
    2. define command{
    3. command_name restart-xinetd
    4. command_line /omd/sites/monitor/local/lib/nagios/plugins/restart-xinetd $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
    5. }


    Zuletzt und am wichtigsten, das auszuführende Script in sehr vereinfachter Form (Step 1/2 dient hier nur zu "Debugging-Zwecken"):



    Noch ein paar Infos: Ich kann als monitor-User das Bash-Script als auch den ssh-Befehl ausführen, was dann auch zu einem Neustart vom xinetd auf dem Remote-System führt (Login via RSA Fingerprint). Das Script selbst wird auch ausgeführt, wenn der Event-Handler ins Spielt kommt (taucht dann unter ~/var/nagios/nagios.log auf + Step 1 und Step 2 landen im Log. Auf der Remote-Kiste sehe ich auch ein Login des bla-Users, jedoch wird "sudo /etc/init.d/xinetd restart" nicht ausgeführt (wie gesagt, per Hand funktioniert es, visudo etc. ist alles angepasst).


    Hat jemand eine Idee? Könnte es an Environment-Variablen liegen? Wenn ja: Was müsste ich übergeben bzw. auf dem Remote nachkonfigurieren?


    Besten Dank vorab!


    mfg MrLINK

    The post was edited 1 time, last by MrLINK ().

  • Klingt sehr stark danach, daß dem "sudo" das bei automatischem Aufruf fehlende tty nicht gefällt. Setz' 'mal eine Zeile "Defaults:bla !requiretty" in die sudoers-Datei (vor die für bla relevanten Zeilen mit Kommandos) und schau' Dir die Manpage an (speziell auf SuSE braucht's auch gerne 'mal weitere Optionen zu den relevanten Paßworten, ist hier offenbar nicht der Fall, da sonst auch der manuelle Test fehlschlagen würde, aber jedenfalls ist die Geschichte bei Optionen und Escaping nicht auf allen Linuxen identisch).

  • Tja was soll ich sagen :) Das wars! Gerade durch das ssh -t wird sollte das sudo-Problem behoben sein:


    Code
    1. -t Force pseudo-tty allocation. This can be used to execute arbi-
    2. trary screen-based programs on a remote machine, which can be
    3. very useful, e.g., when implementing menu services. Multiple -t
    4. options force tty allocation, even if ssh has no local tty.


    Aber wie du sagtest, musste ich noch in der sudoers-Datei rumfrickeln.


    Besten Dank!



    mfg MrLINK


    PS: Kann als gelöst markiert werden (Oder kann ich das?)

  • Gerade durch das ssh -t wird sollte das sudo-Problem behoben sein

    Hmmmm ich lese da einen Hinweis, daß es notfalls vielleicht auch ein "ssh -t -t" sein sollte ...

    (Oder kann ich das?)

    Edit Post #1, verfumble Title of selbiges. ;)

  • Gut, ich habe das nochmal ausprobiert und es funktioniert dann tatsächlich (auch) mit ssh -t -t (ohne in der sudoers rumfummeln zu müssen). Da war ich wohl zu zaghaft..


    Aber danke nochmal.



    mfg MrLINK