Kategorie: Linux

Xenserver 7 xensource.log und xenstored-access.log laufen voll – syslog Loglevel Anpassung

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.

Alle hier gezeigten Anpassungen erfolgen auf eigenes Risiko – bitte nur durchführen, wenn die Auswirkungen bewusst sind – ich schließe jede Haftung aus!

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.

Wenn ihr wieder auf den Standard umstellen wollte, dann einfach das error wieder durch * ersetzen!

 

XenServer 6.x: Virtuelle Maschine von ISO statt von HDD booten (Rescue Mode)

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.

Xen recovery

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

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

 

Debian 8 – Jessie – auf XenServer 6.5 installieren

Hier eine kleine Anleitung wie ihr die aktuelle Debian Version 8 – Jessie – auf eurem XenServer 6.5 installiert.

1. Installationsmedium besorgen

Zunächst besorgt ihr euch die 64 bit Version des Netinstallers von Debian (Link) und legt diese so ab, dass ihr sie zur Installation in Xen zur Verfügung habt (z.B. in einer CIFS ISO Library). Altertiv brenn ihr die ISO auf CD und legt sie auf dem XenServer Host in das Laufwerk.

2. Installation der VM über XenCenter

Nun startet ihr XenCenter und wählt den gewünschten Host oder Pool zur Installation aus und klickt auf New VM um den Installationswizard zu starten.

Als Template wählt ihr hier Debian Wheezy 7.0 (64-bit) aus, dieses Template arbeitet auch hervorragend mit der Jessie Installation.

Debian Installation

Nach dem klicken auf Next gebt ihr dem Kind einen Namen und wenn erforderlich eine Beschreibung

Installation Debian

im folgenden Dialog wählt ihr dann den Speicherort des ISO aus – alternativ das DVD Laufwerk im Host. Die Parameter unter Advanced OS boot parameters braucht ihr nicht an zu passen.

debian Installation

Ihr wählt nun den Host Server aus – oder lasst diesen automatisch vergeben. Dann bestimmt ihr wieviel CPU Kerne und Arbeitsspeicher die VM verwenden soll und gebt an, wie viel Storage Platz zur Verfügung stehen.
Im Networking weist ihr der VM ein oder mehrere Netzwerk Adapter zu.

Hiermit ist die Einrichtung der VM abgeschlossen und die VM taucht nach kurzer Zeit im XenCenter auf. Hier wechselt ihr dann in die Consolen Ansicht der VM.

3. Installation von Debian Jessie

Die Installation von Debian startet nun, und ihr müsst einige Frage beantworten zur Installationsart, Partitionierung der Disk, Hostname, Administratoren Benutzername und Passwort, Normaler Benutzername und Passwort und einige weitere Variablen angeben.

Zum Abschluss wird die VM automatisch gebootet und euer System steht zur Verfügung.

Es müssen jetzt noch die Xentools installiert werden, dazu mounted ihr im XenCetner die xs-tools.iso an eure VM und gebt dann in der Shell ein:

mkdir /mnt/cdrom
mount /dev/cdrom /mnt/cdrom
/mnt/cdrom/Linux/install.sh

Den Systemneustart könnt ihr hier überspringen, da ihr jetzt noch in der VM die Netzwerkumgebung einrichten müsst, falls ihr keinen DHCP Server benutzt.

Dazu passt ihr die Einstellungen in der Konfigurationsdatei /etc/network/interfaces an:

nano /etc/network/interfaces

Hier müsst ihr die Zeile mit iface eth0 inet dhcp entsprechend eurer gewünschten IP Adresse anpassen, hier ein Beispiel wie die Datei dann aussehen sollte:

# The primary network interface
auto eth0
allow-hotplug eth0
iface eth0 inet static
   address 192.168.178.100
   netmask 255.255.255.0
   gateway 192.168.178.1

Zusätzlich müsst ihre noch die Nameserver eintragen bzw. überprüfen, ob schon welche eingestellt sind.
Hier könnt ihr dann eure üblichen DNS Server eintragen – z.B. die von eurem Provider – oder ihr nehmt die von Google

nano /etc/resolv.conf

mit dem Inhalt

nameserver 8.8.8.8
nameserver 8.8.4.4

Damit die Anpassungen übernommen werden, das Netzwerk zur Verfügung steht – und die Xentools ihren Dienst verrichten, müsst ihr jetzt noch das System neu starten.

Damit seid ihr fertig!

How to: Debian 7 Wheezy auf Debian 8 Jessie aktualisieren

Die Linux Distribution Debian 8 ‚Jessie‘ wurde am 25.April nach ca. 2 Jahren Entwicklungsarbeit veröffentlicht.
Viele Pakete wurden aktualisiert, Apache, PHP und Konsorten sind jetzt relativ frisch enthalten.

Knapp 2 Wochen sind nun seit dem Release vergangen – wir kommen jetzt in die Zeit wo es sich lohnt upzudaten :)

Bei Debian ist es so, dass auch zwischen ‚Major Releases‘ relativ gut und sicher upgedatet werden kann.
Ob man das machen möchte – oder lieber seine Server von Grund auf neu installiert – das bleibt jedem selbst überlassen.
Es gibt ja noch Support für Debian 7 ‚Wheezy‘ – daher besteht kein Zwang zum upgrade.

Zum Update meldet ihr euch bitte als Root User an dem System an, alternativ könnt ihr die Arbeiten unter sudo ausführen, unten beschrieben ist die Methode als Root User!

1. System Backup erstellen – Daten sichern

Der ganz Erste und wichtigste Punkt beim Update ist, dass ihr eine Sicherung eurer wichtigen Daten und System Einstellungen vernehmt. Nur so könnt ihr im Zweifelsfall sicher stellen, dass ihr zu einem laufenden System zurück kehren könnt!

Was sollte mindestens gesichert werden?

  • Alle Konfigurations Dateien, am einfachsten das komplette /etc Verzeichnis
  • Debian Paket Informationen (/var/lib/dpkg, /var/lib/apt/extended_states, /var/lib/aptitude/pkgstates)

Benutzer Verzeichnisse werden beim Update nicht angefasst, auch Datenbanken nicht direkt, dennoch würde ich empfehlen, diese zu sichern, da z.B. bei den Datenbanken durch das Update von MySQL unter Umständen nicht vorhersehbare Probleme eintreten können.

Solltet ihr eine Virtualisierungslösung für euren Server nutzen (XEN oä) – dann könnt ihr in der Regel auch vor dem Update einen Snapshot des Servers anfertigen – dann geht das Backup relativ schnell :)

2. Downtime einplanen

Updates gehen nicht ohne Neustart von Diensten plus Neustart des Servers zum Update Ende. Hier müsst ihr also einplanen, dass Teile bzw. Dienste eures Servers, für einen gewissen Zeitraum nicht erreichbar sein werden. Dieser Zeitraum liegt irgendwo zwischen 1 und 3 Stunden, jenachdem wie viel Nacharbeit ihr noch vornehmen müsst. Solltet Ihr User oder Kunden auf dem Server haben, dann solltet ihr überlegen diese vorab zu informieren.

3. Wheezy auf aktuellen Stand bringen

Bevor ihr auf Jessie geht, müsst ihr erst einmal dafür sorgen, dass Wheezy auf dem aktuellen Stand ist, dazu benutzt ihr das folgende Shell Kommando

apt-get update && apt-get upgrade

4. sources.list Datei anpassen

Debian nutzt zum Updaten der Paket ‚apt‘ – und dazu gehört eine Datei mit Informationen über das zu verwendende Repository. Diese Datei heißt /etc/apt/sources.list und enthält benötigte URL und/oder Pfade für die Debian Pakete. In dieser Datei müssen alle ‚wheezy‘ gegen ‚jessie‘ getauscht werden.

Die Datei sieht so – oder so ähnlich aus:

deb http://httpredir.debian.org/debian wheezy main
deb-src http://httpredir.debian.org/debian wheezy main

deb http://httpredir.debian.org/debian wheezy-updates main
deb-src http://httpredir.debian.org/debian wheezy-updates main

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main

hier werden mit dem folgenden Befehl die benötigten Änderungen durchgeführt, die erste Zeile erstellt euch ein Backup der sources.list

cp -p /etc/apt/sources.list /etc/apt/sources.list.deb7
sed -i 's/wheezy/jessie/g' /etc/apt/sources.list

5. Update aller Pakete

Nun haben Debian den Ort der neuen, aktuellen Pakete mitgeteilt, also müssen wir auch für die Installation dieser Pakete sorgen. Dieser Schritt muss vor dem eigentlichen Upgrade auf ‚Jessie‘ erfolgen.

apt-get update && apt-get upgrade

Bitte achtet bei diesem Schritt auf möglicherweise auftretende Hinweis Boxen oder Rückfragen der Paket Installationen – sollten diese bei euch angezeigt werden (hängt davon ab, welche Pakete ihr installiert habt) – dann lest euch das gut durch, seht euch ggf. die Differenz Dateien an – und macht euch Notizen über das, was in den Hinweisen steht – hier erhaltet ihr ggf. Hinweise wo noch Nacharbeiten zu erledigen sind!

6. Upgrade auf Jessie durchführen

Nachdem nun alle Updates ausgeführt sind, kommt das eigentliche Upgrade auf Debian 8 ‚Jessie‘ dazu folgenden Befehl ausführen

apt-get dist-upgrade

Auch hier wieder auf mögliche Hinweis boxen achten, siehe Punkt 5.

 7. Abschluss Arbeiten

Herzlichen Glückwunsch – euer System läuft nun auf Debian 8 ‚Jessie‘.

Es lungern noch einige Paket auf dem System welche ihr entfernen könnt, dazu den folgenden Befehl nutzen:

apt-get autoremove

Damit noch ausstehende Kernel Änderungen durchgeführt werden können, führt bitte einen Reboot des Servers durch

reboot

Wenn ihr euch nun einloggt könnt ihr euch die aktuelle Debian Version ansehen bzw. überprüfen

cat /etc/debian_version

sowie die installierte Kernel Version ansehen

uname -a

Bitte überprüft alle Dienste ob sie laufen – wenn nicht, schaut in die Logfiles oder eure Notizen und nehmt entsprechend benötigte Änderungen vor.

Hinweise zu Apache Installationen

Von Wheezy nach Jessie ändert sich die Apache Version von 2.2.x auf 2.4.x – damit gehen einige Änderungen in den Konfigurationsdateien einher, welche vor einem erfolgreichen Neustart angepasst werden müssen, ihr solltet auf jeden Fall einen Blick auf die Apache Seite werfen (Link) und eure Konfigurationen entsprechend überprüfen bzw. anpassen.

Besonders erwähnen möchte ich die folgende Änderung:

2.2 Konfiguration:

Order allow,deny
Allow from all

2.4 Konfiguration:

Require all granted

Wenn ihr das nicht anpasst – werdet ihr keine eurer Seiten aufrufen können ‚Access denied’…

In Options Zeilen müsst ihr darauf achten, dass alle Optionen ein + oder – vorangestellt haben (oder keine), im Zweifel fehlt hier in der 2.2 Konfiguration das ein oder andere + Zeichen

2.2 Konfiguration:

Options -Indexes IncludesNOEXEC +SymLinksifOwnerMatch +ExecCGI

2.4 Konfiguration:

Options -Indexes +IncludesNOEXEC +SymLinksifOwnerMatch +ExecCGI

Wenn ihr das beachtet, dann sollten schnell alle Probleme behoben sein. So – happy updating – und wenn ihr auf Probleme stoßt oder Fragen habt – bitte hier kommentieren!

Titelbild: Juliette Taka BELIN, Lizenz: Creative Commons Attribution 3.0 oder GNU GPL v2 oder später

WordPress und NGINX – ‚client intended to send too large body‘ – Fehlerbehebung

Bei einer Installation von WordPress unter NGINX bin ich auf den folgenden Fehler gestoßen:

client intended to send too large body: 6668887 bytes, client: 10.10.10.10, server: XXX.de, request: „POST /wp-admin/async-upload.php HTTP/1.1“,
host: „XXX.de“, referrer: „http://XXX.de/wp-admin/media-new.php“

Dieser Fehler ist aufgetreten, obwohl die PHP Einstellungen 20MB Dateien akzeptieren.

Innerhalb von NGINX wird nochmals die Dateigröße überprüft. Um diesen Fehler zu beheben, muss in der NGINX Konfiguration der Parameter client_max_body_size erstellt bzw. angepasst werden. Für diesen Wert gilt ein Standardwert von 1M.

nano /etc/nginx/nginx.conf

Hier muss man nun, innerhalb von http{…} die folgende Zeile eintragen, soll die Anpassung nicht Serverweit gelten, sondern auf eine einzelne Domain beschränkt werden, dann müssen die Anpassungen innerhalb von server{….} oder location{….} erfolgen!

client_max_body_size 20M;

danach noch NGINX neu starten

service nginx reload

Nach dem Neustart kann man nun die größere Datei problemlos hochladen.  Selbstverständlich kann man auch einen anderen Wert als 20M angeben!