Skip to content

Booten eines Compaq EVO D510 ohne Keyboard

Ich habe eben meinen Linux Home-Server aufgelöst, da in der Familie ein Desktop Rechner benötigt wird. Die einzige Aufgabe, die der Server erfüllt hat war eh nur das Backup des NAS. Das werde ich in Zukunft mir einer externen Festplatte erledigen. Auf dem Server habe ich ausserdem noch einige Webseiten für Tests gehostet. Da ich aber nicht auf einen physikalischen Server verzichten will, habe ich aus dem Keller einen alten Compaq EVO Rechner (Proz 2GHz/1GB RAM) ausgegraben und ein Ubuntu Server 12.04 LTS installiert. Jetzt muss ich bloss noch die Test-Webseiten umziehen.

Für die Installation habe ich ein USB-Keyboard und ein Display angeschlossen (logisch ;-) ). Da ich nach der abgeschlossener Installation das Gerät ohne Tastatur und Monitor betreiben möchte und den Server nur noch via SSH steuern will, habe ich kurzerhand Tastatur und Bildschirm ausgestöpselt. Nach betätigen des Netz-Schalters hat die Maschine dann auch gestartet. Dachte ich wenigstens. Da aber der EVO auch nach zwei Minuten noch nicht per SSH erreichbar war, habe ich kurzerhand den Monitor wieder angeschlossen. Die Meldung, die ich zu Gesicht bekam erfreute mich nicht besonders: KEYBOARD ERROR

Ich habe im BIOS gesucht, jedoch nichts gefunden, das wirklich weiter geholfen hätte. Beim Booten verlangte der Rechner jedes Mal nach einer Tastatur. Jetzt musste Google ran. Nach kurzer Zeit hatte ich bei HP die, nicht ganz offensichtliche, Lösung gefunden.

Go into F10 setup- Password Options-- This selection is displayed only if a power-on password is set. It allows you to enable or disable network server mode, which allows the computer to boot the operating system when the power-on password is enabled, with or without a keyboard or mouse attached. When attached to the system, the keyboard and mouse remain locked until the power-on password is entered.

Gesagt getan. Passwort gesetzt, Netzwer/Server Mode aktiviert und siehe da. Der Rechner startet anstandslos ohne Keyboard. Und noch etwas zum Schluss. Unbedingt das gesetzte Password irgendwo notieren, denn sobald eine Tastatur angestöpselt wird, verlangt das BIOS das Password um das System zu starten.

Wenn die Wurzel abgesägt wird.

Heute informierte mich Dirk via Email, dass ich in etwas mehr als einem Monat heimatlos sei und ich mir deshalb eine neue Bleibe suchen muss. Das hört sich jetzt sehr dramatisch an. Aber ihr könnt beruhigt sein, es geht lediglich um den Root-Server, auf dem mein Blog, mein Wiki und meine Emails (noch) beheimatet ist.

Also habe ich gleich angefangen mich nach einem neuen zu Hause für meine Digitalen Daten-Silos umzusehen. Eben dieser Dirk hat mich auf uberspace.de aufmerksam gemacht. Das Konzept der jungen Truppe hat mich sehr angesprochen. Am Abend dann habe ich mich mit einem guten Kollegen zu einer Pizza getroffen. Der wiederum hat mir den Schweizer Hoster cyon.ch ans Herz gelegt. Das Angebot (Kiwi) sieht auch auf den zweiten Blick sehr gut aus.

Wenn ihr nun aber den ultimativen Hosting-Tipp parat habt. Nur her damit. Ich denke, dass ich mich spätestens bis Ende der Woche entscheiden werde um genug Zeit zu haben, alle meine Daten zu übersiedeln.

Automount mit autofs

Durch einen Tipp von Ramon von Adminstories bin ich auf den Dienst autofs gestossen. Dieser Verbindet Netzwerk-Shares quasi auf Anfrage und unterbricht die Verbindung nach festgelegter Zeit wieder. Ich nutze dieses Feature um mich mit meinem Backup-Server an den NAS zu hängen, wenn um ein Uhr Nachts die Sicherung "losrauscht".

Wie das Ganze nun funktioniert aber vor allem wie man den Dienst einrichtet erklären die beiden von Adminstories um einiges besser als ich es könnte. Nämlich hier. Vielen Dank an dieser Stelle für euren tollen Artikel.

PuTTY und "Server refused our key"

Ich will auch von Windows Rechnern (ja, gibt's bei mir zu Hause auch) auf Linux Server zugreifen. Ich mache das mit SSH und einem RSA-Schlüsselpaar. Als Client-Software verwende ich PUTTY. Um ein Schlüsselpaar zu erstellen, startet man das Programm "PuTTY Key Generator" (puttygen.exe). Mit einem Mausklick auf den Button "Generate" und ein wenig Mausgeschubbse generiert man sich die Schlüssel. Mit den beiden Buttons "Save public key" und "Save private key" werden die Schlüssel auf die Festplatte geschrieben. Der öffentlichen Schlüssel muss nun auf den Server kopiert werden und dort in die Datei ~/.ssh/authorized_keys überführt werden.

Hier bin ich nun in die Falle getappt. Denn nach dem Einfügen des öffentlichen Schüssels in besagte Datei und einem ersten Anmeldeversuch meldet mir PuTTY "Server refused our key". Was war passiert?

Der öffentliche Schlüssel in der Datei, die aus dem PuTTY Key Generator erstellt worden ist hat folgendes Format.

---- BEGIN SSH2 PUBLIC KEY ---- Comment: "rsa-key-20110416" AAAAB3NzaC1yc2EAAAABJQAAAIB5yJ/HodElR8lAzKQGrgfNyG9s3KwCGVR5/8l0 6d9tjCdcwDqmJxL6jBlJhY6BdZHv8m8LMXmI/E9lJl8kkms3QJGUqmHMYVv1tf2w TMXeWttP1oLDWHgg7txId5ewG2vSFLKShLeuXykPaQHzYUwBFEzWmMIh8VvjxgC5 9tsTlQ== ---- END SSH2 PUBLIC KEY ----

Die ersten beiden sowie die letzte Zeile kann schon mal gelöscht werden. Ebenfalls muss der Schlüssel in eine Zeile gepackt werden. Dass sieht dann so aus: (In vim macht man das mit der Tastenkombination Shift+J / Ausserdem nicht vergessen, die Leerschläge aus dem Key zu löschen!!)

AAAAB3NzaC1yc2EAAAAB.........WmMIh8VvjxgC59tsTlQ== (gekürzt)

Ob der String nun wirklich bloss aus einer Zeile besteht, kann überprüft werden, indem in vim die Zeilennummerierung mit ":set number" eingeschaltet wird.

Zum Schluss fügt man an den Anfang der Zeile, in unserem Fall, "ssh-rsa" ein. Jetzt kann der Schlüssel in diesem Format auf dem Server in die Datei authorized_keys eingetragen werden.

ssh-rsa AAAAB3NzaC1yc2EAAAAB.........WmMIh8VvjxgC59tsTlQ== (gekürzt)

Jetzt steht einer erfolgreichen Verbindungsaufnahme mit dem Server nichts mehr im Weg. Natürlich bin ich da nicht selber draufgekommen. Wer sich den Original-Artikel anschauen möchte findet ihn hier

MediaWiki - Im PdfExport keine Bilder

Seite einiger Zeit betreue ich in der Firma fünf Wikis die mit MediaWiki betrieben werden. Unter anderem setzte ich seit den ersten Gehversuchen das Plugin PdfExport ein. Vergangene Woche habe sämtliche Wikis auf den neusten Stand gebracht. Dabei habe ich festgestellt, dass es auch für das genannte Plugin eine neue Version gibt. Bei der ersten Generierung einer PDF-Datei musste ich feststellen, dass zwar der Text in eine PDF-Datei "verwurstet" worden ist, aber sämtliche Bilder fehlten.

Auf der Diskussionsseite der Erweiterung ist man sich anscheinend auch nicht schlüssig, was in diesem Fall nun zu tun ist. Nachdem ich sämtliche Vorschläge durchprobiert habe und keiner mich zu Ziel brachte habe ich es eben selber versucht. Ich habe zwar noch nie etwas mit PHP gemacht, aber so schwer wird da ja wohl nicht sein. (dachte ich) Beim Debugging ging's schon los, da ich keinen Schimmer hatte, wie ich während der Laufzeit einer PHP-Anwendung Variablen zu Gesicht bekomme. Ich habe es schlussendlich geschafft den Inhalt von Variablen in ein Textfile auszugeben. So konnte ich mir ein Bild machen, was für HTML-Code an den Befehl htmldoc übergeben wird. Dieser Befehl ist dafür zuständig aus einer HTML-Datei eine PDF-Datei zu erstellen.

In diesem Text-File konnte ich sehen das für die Bilder der folgende Pfad verwendet worden ist.

<img alt="TestArea.jpg" src="http://tw1/images/e/e0/TestArea.jpg" width="473" />

Was soweit stimmte, da das Bild angezeigt wird, wenn ich diese URL im Browser eingegeben habe.

Ich habe lange im Code gesucht. Schlussendlich war aber eine entscheidende Kleinigkeit schuld. Da es sich bei den Wikis um virtuelle Hosts auf einer Maschine handelt, müssen diese in der Datei /etc/hosts unter 127.0.1.1 eingetragen werden. Nach diesem Eintrag funktionierte wieder alles wie es sollte.