thingybob.de

In XenServer 7 wurde das Layout der Dom0 Disk geändert, das Log Verzeichnis hat nun eine eigene 4GB Partition für /var/log.

In der Standard Einstellung von XenServer kann es passieren, dass diese Partition sehr schnell voll läuft.
Nun sollte man meinen, dass dieses keine größeren Auswirkungen hat – allerdings stimmt diese Annahme nicht.

Zum Beispiel wird das Einschalten des HA Modus für einen Pool in der Regel fehl schlagen.
Sollten ein oder mehrere Partitionen auf den Xen Hosts voll sein, dann kann es passieren, dass beim Einschalten der HA Funktionalität der Prozess hängen bleibt, zum Reboot einzelner Hosts führt und VMs nicht mehr erreichbar sind.

Wenn man einen Host mit einer vollen /var/log Partition neu startet, dann wird die Verbindung zum Pool fehl schlagen, in der xsconsole werden dann unter anderem keinerlei Netzwerk Informationen mehr angezeigt.

Kurz gesagt: sollten /var/log Partitionen auf Hosts in einem Xen Pool voll sein – dann kann es zum Ausfall des kompletten Pools führen.

Als schnell Lösung kann man, bevor man eine Aktion wie HA einschalten durchführt, die Größe der Partition prüfen und ggf. die nicht benötigten Logfiles löschen

Ich möchte hier zeigen, wie das Logging für xensource.log und xenstored-access.log geändert werden kann, denn der Parameter

xe log-set-output

wird zumindest in meinem Test nicht respektiert. Hier sollte man, in Theorie, den Loglevel einstellen können (debug, info, warn, error).
Wenn man sich das Logfile xensource.log ansieht, dann sieht man Einträge ähnlich diesem hier:

Nov 4 13:11:07 host1 xenopsd-xc: [debug|host1|3 |queue|xenops_server] Queue.push ["VM_check_state", "583a65f4-bb23-34ee-aabd-1b63bc71d250"] onto redirected 583a65f4-bb23-34ee-aabd-1b63bc71d250:[ ["VM_check_state", "583a65f4-bb23-34ee-aabd-1b63bc71d250"] ]

also ganz klar Debug Einträge.

In dem Logfile xenstored-access.log steht ‚debug‘ nicht im logging – allerdings werden teilweise read/write Befehle auf VMs geloggt bei denen es sich offensichtlich um Debug Einträge handelt. Wenn man die unten stehenden Anpassung durchführt, wird man danach sehen, dass wesentlich weniger in das Logfile geschrieben wird.

Die Anpassungen für das Logging nehmen wir direkt im Syslogger der Dom0 vor, dazu loggen wir uns auf die Konsole des jeweiligen Hosts ein und führen in der Shell den folgenden Befehl aus:

nano /etc/rsyslog.d/xenserver.conf

hier finden wir dann unter anderem die folgenden Einträge:

# Xapi, xenopsd echo to syslog local5
local5.* -/var/log/xensource.log
# xenstore access to syslog local3
local3.info -/var/log/xenstored-access.log

diese ändern wir wie folgt ab:

# Xapi, xenopsd echo to syslog local5
local5.error -/var/log/xensource.log
# xenstore access to syslog local3
local3.error -/var/log/xenstored-access.log

Speichern die Änderungen und starten den Syslogger neu

service rsyslog restart

geloggt werden nun alle Ereignisse mit dem Level Error und höher.

Ihr möchtet eure XenServer VM von einer ISO booten – z.B. von einer Live CD oder eine Wiederherstellungs CD?

Hier ist die Lösung:

Zunächst mountet ihr die ISO Datei – danach fahrt ihr die VM herunter.

Dann geht ihr im Menü unter VM auf Start und wählt dort Start in Recovery Mode aus.

Das war schon der ganze Trick – die VM startet nun von der ISO.

Ein weiterer Neustart und ihr seid wieder auf der VM selbst.

NGINX ist ein sehr performanter Webserver, kann jedem nur empfehlen diesen als Alternative zu Apache aus zu testen.

Heute möchte ich kurz zeigen, wie man im {server} Teil der Konfiguration eine Umleitung einrichten kann, welche folgende Bedingungen erfüllt:

1. Umschreiben des Domain Namens von www.domain.de nach domain.de
2. Umleitung von http nach https

In Realität lassen sich mit dieser Umleitung auch weitere Bedingungen abdecken, zum Beispiel auf einen komplett anderen Domainnamen zu leiten.

Hier kommt nun die Anpassung der Konfig:

server {
server_name domain.de www.domain.de
set $wanted_domain_name domain.de;
if ($http_host != $wanted_domain_name) {
 rewrite ^(.*)$ https://$wanted_domain_name$1;
}
}

Was passiert ist, dass alles, was nicht dem wanted_domain_name entspricht, eben in diesen umgeschrieben wird – simples!

Wenn auch noch die wanted_domain immer per https ausgeliefert werden soll, dann muss auch für diese noch ein Rewrite eingerichtet werden, ebenfalls im Serverblock:

# HTTPS umleitung
if ($scheme != "https") {
 rewrite ^ https://$host$uri permanent;
}

Offenbar bereitet man sich bei Amazon Web Services auf eine Zombie Apokalypse vor – anders kann ich mir die Folgende Passage – aus Punkt 57.10 – aus den am 08.02.2016 veröffentlichten ToS (Nutzungsbedigungen)  nicht erklären:

However, this restriction will not apply in the event of the occurrence (certified by the United States Centers for Disease Control or successor body) of a widespread viral infection transmitted via bites or contact with bodily fluids that causes human corpses to reanimate and seek to consume living human flesh, blood, brain or nerve tissue and is likely to result in the fall of organized civilization.

Auf Gut Deutsch gilt die Einschränkung dann nicht, falls eine weit verbreitete Virusinfektion auftritt, welche durch Bisse oder Kontakt mit Körperflüssigkeiten übertragen wird, und welche dazu führt, dass menschliche Leichen wieder belebt werden und versuchen menschliches Fleisch, Blut, Gehirn oder Nervengewebe zu konsumieren, was wahrscheinlich zum Untergang der gesamten Zivilisation führt.

Gut zu wissen!

Amazon ToS

Wichtig: Gegebenenfalls auf die Englische Version umschalten – die Deutschen Nutzungsbedingungen sind noch nicht angepasst :)