Schlagwort-Archive: Debian

Linux Gast bekommt keine IP mehr nach VMWare Umzug

Wenn man einen Linux-Gast für eine VMWare kopiert und angibt, dass man ihn kopiert hat, bekommt er keine IP-Adresse.
Das liegt daran, dass in der /etc/udev/rules.d/70-persistent-net.rules die MAC-Adresse fest eingetragen ist.

Also vi /etc/udev/rules.d/70-persistent-net.rules:

SUBSYSTEM==“net“, ACTION==“add“, DRIVERS==“?*“, ATTR{address}==“00:50:56:xx:xx:xx“, ATTR{dev_id}==“0x0″, ATTR{type}==“1″, KERNEL==“eth*“, NAME=“eth0″

Dort dann die MAC und ggfs. den Namen anpassen. Nach einem Neustart ist die Welt wieder in Ordnung … und erreichbar. 🙂

ssh Verbindungen werden unterbrochen – ServerAliveInterval

Manchmal kann es schon nerven:
Man bearbeitet gerade etwas im ssh-Fenster, muss mal was Nachschlagen oder Telefonieren – und schon ist das ssh-Fenster wieder zu.

Lösung:
ServerAliveInterval Einstellung für den jeweiligen Client oder auch – sofern gewünscht – auf dem Server.

PUTTY
In den Sitzungseinstellungen geht man auf „Connection“ und dort gibt man unter „Sending of null packets to keep session active“ beim Punt „Seconds between keepalives (0 to turn off) den gewünschten Wert in Sekunden an.
Gerne verwendet: 300 = 5 Minuten
Putty ServerAliveInterval

LINUX Client (ssh)
Hier passt man die ssh Einstellungen entweder systemweit (/etc/ssh/ssh_config) oder für den einzelnen Benutzer (~/.shh/config) an. Sollte die Datei für den Benutzer nicht existieren, kann man sie neu anlegen. Eintrag:

Host *ServerAliveInterval 300
ServerAliveCountMax 2

LINUX Server
Man kann auch für den OpenSSH Server einen ServerAliveInterval hinterlegen, um die Sitzungen offen zu halten. Dazu trägt man in der /etc/ssh/sshd_config folgendes ein:

ClientAliveInterval 300
ClientAliveCountMax 2

Zur Erklärung:
Der Eintrag Server-/ClientAliveInterval gibt an, wann die Verbindung mit einem ’null packet‘ aktiv gehalten werden soll.
Der Server-/ClientAliveCountMax ist die Anzahl der Versuche, die unternommen werden, um die Verbindung aufrecht zu halten.
Kommt in diesem Beispiel zweimal keine Antwort, wird der Tunnel geschlossen.

 

VMWare: Installation vom USB-Stick

Möchte man bei VMWare (z.B. im VMWare Player) ein Betriebssystem wie Ubuntu oder Windows 7 installieren, kann es sein, dass man das „Wunsch-OS“ nur als Installations-USB-STick vorliegen hat.
Solche Sticks kann man sich mit z.B. mit Linux Live Key leicht erstellen.

Leider lässt sich der VMWare Player nicht so leicht davon überzeugen, dass man vom USB-Stick auch booten möchte.

Lösung:
Man erstellt eine leere neue virtuelle Maschine und öffnet anschließend die .vmx.
Also in meinem Fall war das eine „Ubuntu 64-bit.vmx“.
Dor fügt man mit einem Editor einfach folgende Zeile hinzu:

firmware = „efi“

Nun wird ein alternatives BIOS verwendet. Drückt man beim Start jetzt die ‚ESC‘-Taste, sieht man einen Bootmanager:

Dort wählt man dann seinen USB-Stick aus:

Ab jetzt läuft die Installation los und man kann sein Wunschsystem installieren.

Sollte man übrigens seinen VMWare Player dazu bewegen wollen direkt ins BIOS zu booten, fügt man in die vmx folgende Zeilen ein:

bios.bootDelay = „6000“
bios.forceSetupOnce = „TRUE“

Nach dem ersten Besuch im BIOS wird dieser Parameter automatisch wieder auf FALSE gesetzt und das System bootet wieder normal weiter.

PHP Warnung: Module ‚modulname‘ already loaded in Unknown on line 0

Problem:
Ein virtueller Debian Server sendet alle 30 Minuten eine Mail mit folgendem Betreff:
[ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

Inhalt:
PHP Warning:  Module ’ssh2′ already loaded in Unknown on line 0

Okay … der erste Hinweis ist schon da: Wenn das Modul schon geladen ist, dann möchte wohl jemand noch einmal laden.
Kleiner Test: Auf der Kommandozeile ‚php -v‘ erzeugt eine ähnliche Meldung.

Ursache:
In PHP gibt es zwei Möglichkeiten, wie die Module geladen werden können:
1. Man kompiliert die Erweiterung direkt in die PHP binay.2. Man läd sie als ’shared extension‘ über eine ini-Datei (php.ini) nach.
Hat man jetzt das Modul einerseits bereits einkompiliert und ruft es zusätzlich aus der php.ini auf, wird das zwar funktionieren, aber es wird eine Meldung erzeugt, dass das Modul schon geladen ist.

Lösung:
Die php.ini öffnen und nach der Zeile extension=ssh2.so (oder anderem Modulnamen) suchen.

Beispiel:
vi /etc/php5/apache2/php.ini
extension = ssh2.so suchen und so auskommentieren ;extension = ssh2.so

Jetzt die Anwendung (in meinem Fall den Apache) neu starten.
Das wars …

Debian on ESXi: info: mpt raid status change on

Das Problem:
Es wird von einem virtuellen Debian Server immer wieder eine Mail generiert:

Betreff: info: mpt raid status change on <SERVERNAME>
Inhalt:
This is a RAID status update from mpt-statusd.  The mpt-status program reports that one of the RAIDs changed state:
Report from /etc/init.d/mpt-statusd on <Servername>

Wer erzeugt diese Meldung?
Infos zum Paket:
Paket: mpt-status

Ermittelt den RAID-Status von mpt- (und anderen) HW-RAID-Controllern
Mit der Software mpt-status kann auf die laufende Konfiguration und den Status von SCSI-HBAs (Host-Bus-Adapter) der Firma LSI zugegriffen werden. Dies ermöglicht das Überwachen von Zustand und Status der RAID-Konfiguration.

Lösung:
Um die Nachrichten los zu werden, kann man spontan folgendes (mit root Berechtigungen) tun:

/etc/init.d/mpt-statusd stop
echo RUNDAEMON=no > /etc/default/mpt-statusd
Damit ist man die Meldungen schon einmal im aktiven System los.
Natürlich könnte man das Tool einfach über ‚apt-get remove mpt-status‘ entfernen, aber ich wollte zunächst ja nur die Meldungen loswerden. 🙂
Ursachenforschung:
Ich habe im Netz Hinweise gefunden, dass das mit dem SCSI-Controller zu tun hat, den VMWare/ESXi bei der Erstellung des neuen Debian Rechners verwendet.
Standard ist der „LSI Logic Parallel“ SCSI Controller.
Verwendet man stattdessen den „LSI Logic SAS“ Controller, werden mpt-status und weitere Tools garnicht erst installiert.
Das habe ich allerdings noch nicht getestet.