Na toll! Eher so zufällig fällt mir auf, dass wir hier unter einem völlig veralteten Kernel arbeiten! Und ich dachte, wenn ich Debian 7.6.0 installiere, wird der aktuellste Kernel installiert? Nun, entweder habe ich bei der Installation was falsch gemacht, oder es wird tatsächlich nur ein veralteter Kernel installiert.
Um herauszubekommen, welcher Kernel derzeit installiert ist, gibt man den folgenden Befehl ein:
uname -r
Dann kommt eine Ausgabe wie diese hier:
3.2.0-4-amd64
Das ist der Kernel, der bei mir auf dem Server läuft, und der ist schon ein paar Tage alt. Wir sind doch jetzt schon irgendwo bei 3.17 oder zumindest mal 3.16? Gerade wegen der Hardware muss ich eigentlich den aktuellen Kernel installieren.
Ist ein Kernelupdate nötig?
Darüber streiten sich die Geister. Kurz gesagt, es passiert auch nichts schlimmes, wenn man es nicht tut. Andererseits, ich habe einen teuren Haswell-Prozessor und einen neuen Chipsatz eingebaut, dessen Funktionen ich auch gerne nutzen möchte. Zwar wird der Rechner auch mit dem 3.2er Kernel laufen, aber es könnte gut sein, dass manche der neuen Funktionen nicht optimal genutzt werden. Zum Beispiel bringt der Haswell neue Ruhemodi mit, wobei ich nicht weiß, ob er sich selbst bei Inaktivität in diese versetzt, oder vom Kernel in diese versetzt werden muss. Neue Prozessoren bringen oft neue Befehlssätze mit, die vom alten Kernel evtl. noch nicht unterstützt werden.
Nachdem ich den Kernel aktualisiert hatte, bootete der Rechner bedeutend schneller. Klar ist das kein Beweis dafür, dass der neue Kernel besser ist. Aber es ist doch ein Indiz. Es zeigt mir halt, dass die höheren Durchsatzraten des Chipsatzes oder eine ausgereiftere Multikern-Unterstützung eingesetzt wird. Zumindest vermute ich das.
Das ist das Problem, Sicherheit und Stabilität sind eine Sache, Aktualität eine andere. Ubuntu aktualisiert in meinen Augen zu oft, so dass man ständig sich um das System kümmern muss, Debian aktualisiert zu selten, so dass man mit neuer Hardware hinterherhinkt. Die Wahrheit, oder besser gesagt das Optimum, liegt wahrscheinlich irgendwo in der Mitte... Wie auch immer, ich werde den Kernel aktualisieren. Ob ihr das auch machen möchtet, könnt ihr ja anhand eurer Hardware entscheiden. Sollte es ein neuerer Rechner sein, würde ich aktualisieren, ist es eher ein älteres Modell, wird es wohl eher nicht nötig sein.
Editieren von Konfigurationsdateien
Das ist eine Aufgabe, die wir noch öfter machen müssen. Viele bevorzugen den Editor VI, aber ich kann dem absolut nichts abgewinnen. Total kompliziert und unhandlich. Ich bevorzuge Nano, der sich genau so benimmt, wie man es von einem Editor irgendwie erwartet...
Hier kommen jetzt ein paar Probleme zum Tragen, die sonst eher zu vernachlässigen sind. Ich benutze Putty mit Jaws. Der tatsächliche Cursor und der auf der Braillezeile angezeigte Cursor sind nicht gleich. Tatsächlich ist es so, dass der tatsächliche Cursor 1 oder 2 Felder links des Cursors ist, der auf der Braillezeile angezeigt wird. Das ist nicht schlimm, aber man muss es wissen, sonst löscht man evtl. die falschen Zeichen. Bis ihr euch daran gewöhnt habt, arbeitet hier sehr vorsichtig.
Die wichtigsten Tastenkombinationen für Nano sind am unteren Bildschirmrand angezeigt. Hier wird fast nur mit der STRG-Taste gearbeitet. STRG+X z. B. schließt den Editor und fragt gegebenenfalls nach, ob Änderungen gespeichert werden sollen.
Hinzufügen von Paketquellen
Debian holt sich ja Pakete von seinen Paketquellen. Hier liegen die Dateien, die für die Installation von Programmen nötig sind. Die neuen Kernel, ist jetzt das Plural kernels?, liegen in einem eigenen Repository, den Backports. Backports sind Rückportierungen. Neuere Pakete, wie z. B. eine neuere Kernelversion, werden so angepasst, dass sie auch unter einer älteren Distribution arbeiten. So muss der Kernel 3.16 z. B. rückportiert werden, damit er mit der Debian 7.6.0 Distribution kompatibel ist.
Also muss das Repository der Backports auch dem Server mitgeteilt werden, damit er auch dort nach Paketen sucht.
Die Liste der Paketquellen ist eigentlich eine simple Textdatei, in die wir nur 3 Zeilen einfügen müssen. Also öffnen wir die Datei im Editor Nano mit folgendem Befehl:
sudo nano /etc/apt/sources.list
Den Rest der Datei lassen wir mal ganz in Ruhe, das sind die Paketquellen, woher Debian ohnehin seine Pakete holt. Das ist ja in Ordnung, wir wollen unten nur 3 Zeilen hinzufügen. Mit den Pfeiltasten gehen wir also ganz runter, und geben dort folgende Zeilen ein:
# Backports Paketquellen
deb http://ftp.de.debian.org/debian/ wheezy-backports main contrib non-free
deb-src http://ftp.de.debian.org/debian/ wheezy-backports main contrib non-free
Ihr könnt die Zeilen auch markieren und kopieren. Um sie in das Putty-Fenster einzufügen, wechselt dann in dieses, zieht die Maus zum Cursor und drückt dann auf der Maus die rechte Maustaste. Dann wird die Zwischenablage ins Putty-Fenster eingefügt. Das könnt ihr auch mit Befehlen machen.
Mit STRG+X schließen wir den Editor. Nano fragt noch, ob er die Datei überschreiben soll, ich antworte mit "y", ich hab ja alles noch in Englisch. Der Dateiname wird mir angezeigt, auch hier drücke ich Enter, fertig! Wir haben erfolgreich eine Paketquelle hinzugefügt.
Den neuen Kernel installieren
Mit dem schon bekannten Befehl
sudo apt-get update
aktualisieren wir eben noch schnell die Paketliste. Um den Kernel nun aber installieren zu können, müssen wir apt-get explizit mitteilen, dass wir das Paket aus dem Backports-Repository haben wollen. Mit folgendem Befehl wird der Kernel installiert:
sudo apt-get install -t wheezy-backports linux-image-amd64 linux-headers-amd64
Es werden nun eine Menge Pakete installiert. Wie ich schon sagte, auch Pakete, von denen der Kernel abhängig ist, werden mit installiert.
Nun muss noch mit sudo reboot der Rechner neu gestartet werden.
Und wenn wir uns jetzt wieder am Server anmelden und wieder mit uname -r die Kernel-Version abfragen, erhalten wir folgende Ausgabe:
3.16-0.bpo.2-amd64
Das sieht doch schon wesentlich besser aus! nachdem wir das gerettet haben, kann's ja normal weitergehen. 🙂
One more thing...
Also einer meiner besten Freunde ist Kumpel Zufall! Ich suche ja schon nach einer Möglichkeit, auch ohne Monitor zu wissen, wann der Server nun hochgefahren ist. Und beim relativ unmotivierten Herumsurfen bin ich regelrecht über die Lösung gestolpert.
Die Linux Kommandozeile kennt tatsächlich einen einfachen Befehl, den PC-Lautsprecher piepsen zu lassen. Gedacht ist das für Skripte, und genau für so was nutzen wir den jetzt. Gebt mal in der Eingabeaufforderung "beep" ein. Passiert nix? OK, dann müssen wir das eben noch nachinstallieren:
sudo apt-get install beep
Nun müssen wir eine Datei editieren, die sich rc.local nennt. Wer noch mit DOS-Begriffen was anfangen kann, das ist so was wie die autoexec.bat. 🙂 Nachdem alle Dienste und Systemkomponenten gestartet sind, wird diese Datei ausgeführt. Was hier drin steht, kommt also als letztes dran. Das bietet sich ja geradezu an, oder? 🙂
sudo nano /etc/rc.local
Damit wäre die Datei offen. Geht nun mit den Pfeiltasten ganz bis an das Ende der Datei. Als letzte Zeile steht da:
exit 0
Genau über diese Zeile schreiben wir jetzt den Beep-Befehl rein, so dass die beiden letzten Zeilen so aussehen:
beep -f 800 -l 500
exit 0
Nun noch mit STRG+X die Datei speichern, fertig.
Der Parameter -f legt die Frequenz des Tons fest, der parameter -l die Länge. Probiert auf der Konsole ruhig erst mal ein paar Variationen aus, aber ich finde, diese Kombination ist so ganz in Ordnung. Beep ohne Parameter gibt einen viel tieferen und kürzeren Ton aus. Ich finde, der ist etwas zu leise und könnte leicht überhört werden.
Gebt mal "sudo reboot" ein, um den Rechner neu zu starten. Wenn er fertig hochgefahren ist, wird als letztes der Piepton abgespielt. Nun braucht man nicht mehr raten, wann der Server bereit ist!
