Herunterfahren einer XEN-virtualisierten Anlage

Hallo Community & Pascom Entwickler,

Meine MobyDick läuft (leider vollvirtualisiert) unter Citrix XenServer.
Bei einem Stromausfall sollte der XenServer die Mobydick nun herunter fahren können.

Leider kann Xen das bei vollvirtualisierten Umgebungen nicht von sich aus.
(Man kann sie einfach “Ausschalten”, aber nicht “herunter fahren”)

Der Xen kommuniziert mit der UPS über das OpenSource-Tool “apcupsd”.

Meine Lösungsansätze wären:

  1. “apcupsd” auf der MobyDick installieren
  2. Den MobyDick per SSH remote herunter fahren.
  3. Einfach “Ausschalten”

Zu …

  1. Ich will nichts weiter auf der Anlage laufen haben und weiss nicht mal ob es geht :wink:
  2. Hier scheitere ich am Login als root per SSH und an der passwortlosen “key authentication”
    (Ich habe bereits die /etc/ssh/sshd-config angepasst und ssh neu gestartet,
    den Schlüssel des Clients in die “~/.ssh/authorized_keys” der User “Root” und “Admin” gepackt,
    “~/.ssh” mit den Rechten “chmod 755” und die “authorized_keys” mit “chmod 600” versehen)
  3. Scheint mir ein wenig hart.

Hat hier evtl. jemand einen Vorschlag oder Lösungsansätze?

Vielen Dank im Vorraus!

Robert

Hallo Robert,

die Variante 3) wirfst Du bitte sofort in den Müll :slight_smile:
Zu 1) den acupsd könnten wir evtl. mal in die Firmware aufnehmen, alternativ wären die Network UPS Tools einen Blick wert, die sind etwas “enterpreisiger”.

Als schnelle Lösung wirst Du Dich nochmal mit dem SSH Login auseinandersetzen müssen. Wenn ich Probleme mit dem Biest habe, starte ich den sshd mal gerne im Debug-Modus und im Vordergrund auf einem abweichenden Port ( z.B. /usr/sbin/sshd -Dd -p 2222)
Man sieht dann sofort was schief läuft und muss den sshd nicht ständig neu starten. Du musst beim Testen halt aufpassen, das Du Clientseitig auch den geänderten Port verwendest.

Falls es dennoch nicht klappen will gäbs auch noch den Entwickleransatz (Quasi Variante 4): Du könntest dem Daemon einen “Herunterfahren” Job in die Queue stellen. Hierzu brauchst Du aber dann wieder eine Scriptsprache mit MySQL Zugang, etwa Perl oder PHP.

Gruß,

Thomas

Hallo,

  1. Hier scheitere ich am Login als root per SSH und an der passwortlosen “key authentication”
    (Ich habe bereits die /etc/ssh/sshd-config angepasst und ssh neu gestartet,
    den Schlüssel des Clients in die “~/.ssh/authorized_keys” der User “Root” und “Admin” gepackt,
    “~/.ssh” mit den Rechten “chmod 755” und die “authorized_keys” mit “chmod 600” versehen)

das klappt eigentlich. Ich selbst habe letztes mal vergessen “permitrootlogin” auf “yes” zu stellen. Denn dann kann das mit dem Zertifikat schon klappen, aber der Paramter verhindert das. Auch ist ~/.ssh/authorized_keys auskommentiert. Evtl. hast Du das übersehen?

Btw.: Ich arbeite gerade an einer neuen Firmware, diese wird dann Paravirtualisierung unterstützen.

LG
Mathias

Hallo Mathias,

erneut vielen Dank für die Hilfe! Wie oft Du Leute auf das offensichtliche stößt ist schon interessant.
Das nächste mal schau ich 3-10 mal hin.

Es war: “permitrootlogin” auf “yes” ! ( Vor die Stirn klopf)
Den Parameter hab ich einfach übersehen!

Jetzt gehts. :slight_smile:

Vielen vielen Dank!
Robert