.LNX-WORLD

Ich letzter Zeit bon ich selbst immer wieder in die gleiche Falle gegangen: Route für ein bestimmtes Netz auf einem Server hinzugefügt (für meinen Zugriff via VPN) und nach einem Reboot – alles wieder weg, ergo keinen direkten Zugriff mehr. Und alles nur weil ich zu faul war mir zu merken wie ich permanente statische Route in Ubuntu erstelle. Das soll sich nun ändern – ich schreibe wie so oft einfach einen Blog dazu – und schon ist es unauslöschlich in meinem Kopf. Hier also:

HowTo: Permanente Routen unter Ubuntu Linux

Für ein Netzwerk eine Route zu erstellen ist ja (fast) allgemein bekannt, aber damit wir in diesem Artikel alle über das gleiche Netz sprechen, hier mein Beispiel für die Route die ich permanent hinzufügen möchte und nach jedem Reboot auch immer gleich online haben will:

route add -net 192.168.101.0 netmask 255.255.255.0 gw 192.168.1.1 dev eth0

Zu Deutsch: Alle Anfragen an und von IPs aus dem netzbereich von 192.168.101.1 bis 192.168.101.255 sollen über das Gateway 192.168.1.1 abgewickelt werden. Das Gateway ist über das Netzwerkinterface eth0 zu erreichen.

Wenn man dies nun so in die Konsole haut, funktioniert die Route gleich und sofort (sofern keine Tippfehler drin sind). jedoch ist diese Route nach einem Reboot wieder weg – und genau das wollen wir ja nicht, wir wollen einen permanente statische Route für dieses Netzwerk!

Um diese statische Route nun permanent zu machen, müssen wir die Datei “/etc/network/interfaces” editieren – ganz unten sammel ich meine Routen um die Übersichtlichkeit zu bewahren.

Wir ergänzen einfach die obige Zeile leicht ergänzt und angepasst:

up route add -net 192.168.101.0/24 gw 192.168.1.1 dev eth0

Mehr ist wirklich nicht zu tun – eine Route also nicht gleich hier einzutragen ist wahrlich nur Faulheit.

Aber hier nochmal kurz der Syntax für die Route:

up route add [-net|-host] / gw  dev

Welche Netzmaske ihr habt, solltet ihr wissen – wenn nicht, habt ihr ganz andere Probleme :)

Auf dem VMware ESXi in Version 4.0 war es noch relativ umständlich SSH zu reaktiveren (hier das alte HowTo). Auf dem neuerem VMware ESXi 4.1 ist es deutlich einfacher geworden! Bei Zugriff auf die VMware Konsole des Servers genügt:

• Drücken der F2 Taste
• Troubleshooting Options
• SSH aktivieren

Viel einfacher geht es nicht. SSH lässt sich seit VMware ESXi 4.1 allerdings auch über den VMware vSphere Client aktivieren, einfach in die Options gehen. Näheres ist in der unten verlinken VMware Knowledge Database auch beschrieben.

Ich kann wie immer nur dem Weg über die Konsole empfehlen – VMware Hardcare Konfigurationen nimmt man einfach ohne GUI vor – das gehört sich so!

Weblinks:

• VMware Knowledge Database
• Veeam RootAccess

VMware ESXi 4.0 – SSH (re) aktivieren
SSH Zugriff auf ESX Server ist etwas an das man sich gewähnt hat und das man oftmals auch braucht. Leider hat VMware beim ESXi 4 eben diesen SSH Zugriff deaktiviert. Selbst an die Konsole, also den Linux Teil des ESX, kommt man nur mir Tricks.

Leider sind diese Tricks durch VMware in keinster Weise supported, aber was stört das, wenn dafür SSH und Konsole auf dem ESXi wieder benutzbar werden?

Trick 1: Zugriff auf die Konsole nehmen
Sobald der ESXi Server hochgefahren ist, also der “Wellcomescreen” zu sehen ist, direkt am VMware ESXi Server auf der Tastatur ALT-F1 drücken, nicht wundern das man keinen Cursor sieht und das Wort “unsupported” ohne “” eintippen, die Eingabe mit ENTER bestätigen. Wenn man sich nicht vertippt hat, wird nun das Rootkennwort abgefragt -> eingeben und hat Zugriff auf die Konsole des ESXi Servers!

Trick 2: SSH (re)aktivieren
Sobald man sich wie in Trick 1 beschrieben Zugriff auf die ESXi Konsole ermöglicht hat, öffnet man sich direkt auf dem VMware ESXi mit dem vi die Datei /etc/inetd.conf
Hier entfernt man mit dem vi an den beiden Zeilen für SSH das führende # (einfach den Cursor dort hinbewegen und einmal x drücken, danach bei Zeile 2 das Ganze einfach nochmal, speicher und beenden des vi geht mit :wq – den Doppelpunkt wirklich mittippen!). Danach sollte die Sektion in etwa so aussehen:

# Remote shell access #
ssh stream tcp nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -K60
ssh stream tcp6 nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -K60

Nun am besten den VMware ESXi Server durchbooten, um die Änderungen wirksam werden zu lassen. Sollte ein Reboot des Systems nicht so einfach möglich sein (das soll ja bei produktiven Servern manchmal zu ungemütlichen Telefonanrufen führen), muß der inetd manuell neu gestartet werden.

Trick 3: inetd manuell neu starten
Zuerst muss die Prozess ID des inetd ermittelt werden. Dies macht man auch direkt auf der Konsole des VMware ESXi, mit dem Kommando:

ps aux |grep inetd

Die Ausgabe des Kommandos sollte in etwa so aussehen:

4896 4896 busybox inetd

Die erste und zweite Spalte der Ausgabe ist die Prozess ID! Diesen Prozess beenden wir dann manuell mit dem Kommando:

kill -HUP PID

Wobei PID für die zuvor ermittelte Prozess ID steht! Nun sollte der SSH Zugriff funktionieren. Alles weitere was man nun machen muß um sich per SSH mit dem VMware ESXi Server zu verbinden, solltet ihr selbst wissen ;)

Manchmal bleiben auch bei VMware Systemen VM´s einfach hängen. Im ersten Schritt sollte man schauen, ob die entsprechende VMware VM nur im VMware vCenter noch als angeschaltet steht, sollte der VMware ESX selbst (via “esxtop” einfach per SSH nachsehen) die VMware VM bereits als offline sehen, hilft nur warten. Im Fall das die VMware VM auch hier noch als aktiv / online gelistet wird, kann man versuchen die VMware VM per SSH Konsole sanft zu beenden (nicht gleich den Kill einläuten! Das sollte immer der letzte Weg sein):

vmware-cmd /vmfs/volumes/[VMname].vmx stop

Sollte das nicht funktionieren sollte man einen “Hard Stop” versuchen (nicht gleich den Kill einläuten! Das sollte immer der letzte Weg sein):

vmware-cmd /vmfs/volumes/[VMname].vmx stop hard

Ich hatte nun einen Fall wo dies auch nicht mehr half. Die VMware VM wollte absolut nicht aus gehen und blockierte mir so mein System. (ACHTUNG – bei der nachfolgenden Methode kann es zu Datenverlust in der hängenden VM kommen) Da half nur noch ein direkter “kill” des Prozesses für die VMware VM – nur wie findet man die passende Prozess ID um auch den richtigen Prozess mit dem kill zu erwischen?  Die VMware ID welche man über “esxtop” erhält ist leider nicht gleich der Prozess ID für die VMware VM auf dem System. Mittels des SSH Kommandos

ps auxfww | grep [VMname]

erhält man die gewünschte Prozess ID der VMware VM im gewohnten ps Syntax. Danach einfach über das SSH Kommando “kill” den Prozess direkt abschießen:

kill -9 [PID]

Egal was es eigentlich ist, als Root sollte ausser Root nichts auf der Datenbank arbeiten. Gerade Webanwendungen wie Typo3 oder WordPress, welche für jedermann zugänglich sind, sollten mit jeweils eigenen Benutzern auf den jeweiligen Datenbanken arbeiten.
Um einen neuen Benutzer für die MySQL Datenbank per Konsole anzulegen, lautet der Befehl wie folgt:

$ mysql -p -u root
CREATE USER 'neuer_benutzer'@localhost IDENTIFIED BY "passwort_fuer_neuer_benutzer";
exit;

Zur Erklärung: Mit dem erstem Teil (mysql -p -u root) sagen wir “Ich will mich auf die MySQL Datenbank aufwählen, ich bin der Benutzer Root (-u root) und habe ein Kennwort (-p). Anschließend wird nach dem Kennwort für den benutzer Root gefragt.

Im zweitem Teil sind wir bereits in der MySQL Konsole und geben hier unseren Befehl an die Datenbank weiter. Ich will einen neuen Benutzer anlegen (CREATE USER) welcher neuer_benutzer heisst und sich nur von hier aus, also von localhost, einloggen darf (‘neuer_benutzer’@localhost). Der neue Benutzer soll sich per Kennwort authorisieren, das Kennwort soll password_fuer_neuer_benutzer lauten (IDENTIFIED BY “passwort_fuer_neuer_benutzer”). Das ist alles was ich in diesem Schritt möchte, führe den Befehl aus (;).
Im letztem Schritt beenden wir die MySQL Konsole (exit;) und sind somit zurück auf unserer Ausgangskonsole (hoffentlich per SSH oder TTY1).