Backup-Shellscript für diesen Webserver

Vor einem Monat fiel diese Seite ja einem WordPress Redirect Hack zum Opfer. Ein verwendbares Backup war gut zwei Jahre alt, was insofern für mich gut war, dass ich der Manipulation des Blogs nachgegangen bin und selber wieder korrigieren konnte. Hätte ich ein aktuelles Backup gehabt, dann hätte ich vermutlich recht schnell den Restore durchgeführt und wäre dann wieder auch wieder in dasselbe Problem gerannt. Aber, es ist trotzdem wichtig, dass man regelmäßig Backups erstellt. Da durch die Piwigo-Fotogalerie die ich als Unterverzeichnis vom Blog angelegt habe, das gesamte Verzeichnis nun sehr viel Speicherplatz benötigt, komme ich mit der kostenlos-Variante vom WordPress-Plugin Duplicator nicht mehr weiter. – Mal ganz davon abgesehen, dass ich den Einsatz von Plugins doch von Anfang an etwas kritisch gesehen habe und mit dem Hack diese Haltung eher noch verstärkt hat.

Da ich mir für dieses Blog bei meinem Hoster nun keinen reinen Webspace, sondern eine virtuelle Computerinstanz mit einem Linux gebucht habe, stehen mir dadurch auch alle üblichen Kommandozeilenwerkzeuge und Programme zur Verfügung, mit denen ich mir mein eigenes Backup-Programm in Form eines kleinen Shellscripts basteln kann. Das ist dann spätestens jetzt die Gelegenheit sie auch mal zu nutzen. Und so habe ich inzwischen einen ersten funktionierten Entwurf im chaos.expert GitLab veröffentlicht, in der Hoffnung, dass ich es schaffe, mit der Zeit etwas auszubauen und zu optimieren. – Auf jedem Fall wird dieses Shellscript mittels einen Cron-Jobs einmal wöchentlich aufgerufen und es sollen immer die letzten vier Archive für einen Restore auf der Instance lokal gespeichert bleiben. Sprich: Kommt ein neues Archiv hinzu – es muss dann schon wenigstens das „Fünfte“ sein, wird dann das älteste Archiv wieder gelöscht.

Für den Fall dass die komplette virtuelle Linux-Server-Instanz ohne Ersatz offline geht und bei meinem Hoster gekündigt wird, muss ich mir noch ein Konzept für die dezentrale Speicherung der Archive überlegen, falls ich zu einem späteren Zeitpunkt den Webserver mit den alten Inhalten wieder online bringen möchte. Es soll also spannend bleiben!

Links:

Kobo Hacking Teil 3 – Der fertige, digitale Bilderrahmen

Neulich habe ich mal durch meine alten Blog-Beiträge durchgeblättert um zu schauen, worüber ich alles so bisher geschrieben habe. Dabei bin ich im Konkreten wieder auf zwei Artikel gestoßen, in denen ich beschreiben habe, wie sich der eBook-Reader Kobo Mini Touch „hacken“ ließ, um Zugang zum Linux unter der Kobo-Software zu bekommen. Damit bot sich dann die Möglichkeit, den kleinen eBook-Reader mit seinem e-Ink Touch-Display für die eigenen Basteleien zu missbrauchen.
In meinem ersten Blogartikel vom 26. Oktober 2014 bin darauf eingegangen, wie man den nötigen Telnet-Zugang auf den Kobo erlangt und die WiFi-Einstellungen auf die eigenen umbiegt. Im zweiten Artikel – erst neun Monate später am 19. Juli 2015 verfasst und veröffentlicht – habe ich geschildert, wie die Verfahrensweise ist, um beliebige Bilder oder Fotos als Bitmap-Grafikdatei in Dateien so umzuwandeln, dass der kleine Kobo mit seinem beschränkten schwarz-weiß Display diese wieder darstellen kann. Soweit hatte ich alles beschrieben, damit der Kobo Mini auch als digitaler Bilderrahmen funktioniert. Woran ich aber vor sechs Jahren nicht mehr gedacht habe, ist, dass ich Bilder mit den Ergebnissen mit in den Blogartikel einzubinden, sodass ein Leser den Wandlungsprozess der von mir verwendeten Fotos nachvollziehen kann. Dabei habe ich damals im Sommer 2015 sogar extra für die Fotostrecke des Bilderrahmens ein paar Fotos im Regenstaufer Lindenpark mit meiner Kamera geschossen. Das hole ich mit diesem Artikel nun doch mal nach.

Original JPEG-Fotos:

Portätmodus
Landschaftsmodus

Link: Vollständiges Fotoalbum „Campus Eckert und Sonnenuntergang“

Mit GIMP erstellte PNG-Bilder (800×600 px, 4 Bit Graustufen):

Porträtmodus
Landschaftsmodus

Link: Campus Eckert und Sonnenuntergang (schwarz/weiß)

Darstellung mit dem Kobo Mini Touch:

Digitaler Bilderrahmen - vertikal
Gehackter Kobo Mini Touch als digitaler Bilderrahmen umfunktioniert
Digitaler Bilderrahmen - horizontal
Gehackter Kobo Mini Touch als digitaler Bilderrahmen umfunktioniert

Allerdings muss ich aber auch dazu sagen, dass der kleine Kobo Mini kein Gyroskop wie Smartphones und Tablet-Computer hat. Um wirklich ungetrübte Freude beim Betrachten der Bilder zu haben, ist es dazu leider nötig, sich beim Zusammenstellen der Bilderstrecke gleich zu entscheiden, ob sie vertikal in einem Porträtmodus oder horizontal dargestellt werden sollen. Er kann nun mal nicht ein Bild automatisch neu ausrichten.

Links:

Commandlinefu

Als ich im vergangenen Herbst nach einer Lösung im Internet recherchiert habe, um eine Audio-Datei (wav, mp3, etc.) aus der Tonspur einer DVD zu erzeugen, bin ich in meinen Suchergebnissen über Beispiele für Kommandozeilen-Befehle auf der Website www.commandlinefu.com aufmerksam geworden. Bei Commandlinefu kann jeder nach der Registrierung einen kleinen Beitrag einstellen für einen Kommandozeilen-Befehl den er oder sie als erwähnenswert erachtet. Dabei wurden – und werden Befehle präsentiert, die entweder etwas Praktisches, etwas Nützliches, etwas Interessantes oder einfach nur etwas Witziges ausführen.
So gab es bis vor etwa zehn Jahren alternative Beispiele, wie sich ein öffentlicher SSH-Schlüssel auf einem Ziel-Host in die Datei ~/.ssh/authorized_keys einfügen lässt. Hintergrund war, dass Apple zwar die vollständige SSH-Suite seit Beginn von Mac OS X als festes Bestandteil integriert hat, aber über etliche Versionen hat das Programm ssh-copy-id gefehlt. So wurden alternative Wege erarbeitet, die mit Hilfe der Standard-Unix-Tools den Schlüssel über ein einziges Shell-Kommando auf den Ziel-Host brachten.xx
Ich habe mal angefangen, ein wenig in der mittlerweile über fast 12 Jahre alten Sammlung zu stöbern und eine wirklich kleine Auswahl in meinem Wiki gesammelt. Aber es steckt noch viel Potenzial in der Sammlung weitere Befehls-Schätze zu entdecken. Es braucht nur etwas Internet und vielleicht einen halben oder ganzen Tag, an dem sich nichts sinnvolleres mit der vorhandenen Freizeit anstellen lässt.
Es gibt im übrigen auch einen Twitter-Account zu Commandlinefu, der einem über einen neuen Beitrag informiert.

Links:

Emulation einer VAX mit SIMH: Die Hardware

Der Host – Der Computer auf dem SIMH ausgeführt wird

Nachdem ich meine ersten Gehversuche in der Emulation der (Micro-) VAX unter SIMH unternommen habe um in DEC’s Betriebssysteme ULTRIX und OpenVMS hineinschnuppern zu können, sowie auch bereits der Gedanke in mir aufkeimte, gleich eine Artikel-Serie daraus zu stricken, hatte ich die Möglichkeit für lau einen Laptop zu übernehmen. Dabei handelt es sich um einen Acer Aspire 7530, welcher vermutlich im Mai 2008 auf den Markt gebracht wurde. Ausgestattet ist das Gerät mit einem AMD Athlon X2 Dual Core QL-60, welcher mit 1,9 GHz getaktet wird und der zwei mal 64 KB Level 1 Cache, sowie 512 KB Level 2 Cache für jeden der beiden Kerne besitzt. Damit ist die CPU-Leistung für diesen dicken, schweren 17″-Laptop (von den Maßen und der Tastatur eigentlich schon eine Mobile-Workstation) laut der damaligen Fachpresse recht mager. Zur sonstigen Ausstattung gehörten 3 GB DDR2 RAM, von dem bis zu 256 MB Video-RAM für die auch eher seinerzeit schwache nVidea GeForce 9400M abgezweigt werden können, und eine 320 GB Festplatte. Die weiteren technischen Merkmale habe ich in meinem Wiki in der Auflistung meiner PC-Familie aufgelistet, waren aber seinerseits bei Marktstart des Gerätes alle marktüblich, spielen dennoch aber für meinen Einsatzzweck keine Rolle.

Nach Erhalt des Gerätes bin ich erst einmal hingegangen und habe für etwas mehr als 20,- Euro noch ein 2 GB Speichermodul gekauft und eingebaut, weil ich der Überzeugung bin, dass ein Computer Arbeitsspeicher nicht genug haben kann. So hat das Gerät nun 4 Gigabyte statt der ursprünglichen etwas krummen 3 Gigabyte. Beim Betrieb dann mit Linux unter Verwendung von LXDE als Window-Manager hat sich dann deutlich heraus gestellt, dass die CPU-Leistung der deutlich limitierender Leistungsfaktor ist, und weniger die Menge des Arbeitsspeichers. Da ich auf meinen Apple-Macs leider die Treiber für TUN/TAP und vde2 nicht korrekt installieren konnte, bin ich doch froh einen separaten Computer zu haben, den ich in erster Linie nur für das Ausführen von SIMH nutzen kann. Von daher ist es erstmal nicht so schlimm, dass modernere Betriebssystem wie ein aktuelles NetBSD unter einer emulierten Digital VAX auf dem Acer-Laptop recht träge gegenüber meinen leistungsfähigeren Macs laufen. Auf dem Acer-Laptop habe ich Debian-Linux als Host-Betriebssystem installiert, wo der TUN/TAP-Treiber vernünftig läuft und die Programm-Pakete auch besser aufeinander abgestimmt sind.

Links:

Die MicroVAX 3900 von DEC als emulierte Computer

Die VAX im allgemeinen (kurz für Virtual Address eXtension) ist eine von der Digital Equipment Corporation entwickelte 32 Bit Rechnerarchitektur. Die 32 Bit VAX-Prozessoren besitzen einen CISC-Befehlssatz. Für die VAX-Reihe hatte DEC auch passend zu der Architektur das Betriebssystem VMS (kurz Virtual Memory System, später OpenVMS) mitentwickelt und auf den Markt gebracht. – Inzwischen wurde und wird auch das Betriebssystem OpenVMS durch die Firma Hewlett Packard Enterprise zu einem 64 Bit System weiter entwickelt. – Auch lässt sich inzwischen auf den Computern der VAX-Reihe NetBSD und Linux betreiben. Es wurde von OpenBSD auch eine Portierung für die VAX-Computer entwickelt, aber diese wurde in ihrer Weiterentwicklung mit OpenBSD 5.9 im Jahr 2016 wieder eingestellt. Ich bin mir aber auch nicht sicher, ob inzwischen die Weiterentwicklung der Portierung von Linux auf die VAX-Architektur wieder bereits eingestellt wurde.

In der stabilen SIMH-Version 3.x wurde die von Digital Equipment Corporation als ersten Computer der VAX-Reihe auf dem Markt eingeführte VAX 11/780 aus dem Jahr 1977 und das im Jahr 1989 wesentlich kleinere Model, die MicroVAX 3900 implementiert. Da die VAX 11/780 das erste Modell der VAX-Familie war, hat Digitial im Laufe der Jahre einen eigenen Benchmark für die hinzugekommenen Modell (-Reihen) geschaffen.: den VUP. VUP steht für VAX Unit of Performance, bei dem das Urmodel als Referenz definiert ist. Der bei den nachfolgenden Modellen angegebenen VUP gibt also den Faktor der Leistung zum Urmodell an. So hat die bereits erwähnte MicroVAX 3900 einen VUP von 3,8 oder die im Jahr 1991 eingeführte VAXStation 4000 M60 einen VUP von 12.

Im vorherigen Beitrag habe ich bereits dargestellt, dass die aktuelle Beta-Version von SIMH gegenüber den stabilen, prekompilierten Versionen in den Linux- sowie BSD-Distributionen für mich die bessere Wahl ist. Ein wesentlicher Punkt von der Beta-Version ist, dass neben den bereits in der stabilen SIMH-Version 3.x verfügbaren VAX 11/780 und der MicroVAX 3900 weitere Computer der VAX-Reihe emuliert werden können. In einer Tabelle in meinem Wiki habe ich mal die neu hinzugekommenen Modelle tabellarisch aufgeführt, die einen sichtlichen Leistungszuwachs gegenüber die MicroVAX 3900 vorweisen können – sofern der Host-Computer für die Verarbeitungsgeschwindigkeit entsprechend leistungsfähig ist. So hatte ich zum Beispiel mal den Versuch unternommen gehabt, auf einem Raspberry Pi Model 1 B mit einem mit 700 MHz getakteten 1-Kern ARM11-Prozessor und NetBSD 7 als Host-Betriebssystem, die MicroVAX 3900 zu emulieren. Als Betriebssystem kam die VAX-Portierung von NetBSD 7 wieder zum Einsatz. Die Verarbeitungsgeschwindigkeit des Raspberry Pi war dabei so langsam, dass auf dem emulierten System der Login-Prozess während diesem bereits wieder Timeouts geworfen hatte. Aber ohne Login ist natürlich auch nur im Ansatz kein Arbeiten mit dem System möglich. Andere User hatten zu dem Zeitpunkt sich mit dem Raspberry Pi der ersten Generation bereits erfolgreich OpenVMS-Cluster gebaut gehabt.

Bei meinen Experimenten, eine der hinzugefügten VAX-Modelle in der Beta-Version zu emulieren, bin ich auf zahlreiche Fehler gestoßen und ich konnte bisher nicht die passenden Geräte-Komponenten (Harddisk-Controller, Festplatten- und CD-ROM Modell) für einen Betrieb zusammenstellen. Andere User haben beim Emulationsversuch – beispielsweise einer VAXStation – nicht die Netzwerkschnittstelle aktivieren können. Es kann natürlich auch sein, dass im Code für die in der aktuellen Beta-4 neu hinzugekommen VAX-Modelle noch Fehler sind. Deswegen beschränke ich mich momentan auf die bereits in stabilen Version vorhandene MicroVAX 3900.

Quelle: The NetBSD Foundation, VAX Hardware Reference (www.netbsd.org)

Noch ein paar Fakten und Informationen zu der Hardware der MicroVAX 3900 selber.:

Der Computer wurde durch DEC mit dem Codenamen Mayfair III im April 1989 im Markt eingeführt. Sie war High-End-Modell der MicroVAX-Familie, welche die MicroVAX 3600 ersetzte, und sollte mit der AS/400-Serie von IBM konkurrieren. Bei der Einführung betrug der Startpreis der MicroVAX 3900 120.000,- US-Dollar. Dieses System verwendete das KA655-CPU-Modul, das einen CVAX-Chipsatz mit 16,67 MHz (60 ns Zykluszeit) enthielt.

RangeServer
IntroducedApril 1989
CPUKA655, CVAX+ Chip
Taktfrequenz16,67 MHz
FPUCFPA
Cycle in ns60
Level 1 Cache1 KiB
Level 2 Cache64 KiB mit von 120 ns Cycle
Arbeitsspeicher16 – 64 MiB ECC
BUS Storage1 x QBUS und 1 x DSSI
Bandbreite3,3 MB/s
HDD Kapazitätmax. 9,7 GB
GehäuseH9642 (19″ breit)
VUP3,8
Einführungspreis in $120.000,-
Supportet OSVMS, ULTRIX, VAXELN
FPU DatentypenF, D, G, H
Netzwerkmax. 2 Ethernet-Ports

Links:

Emulation einer VAX mit SIMH: Der SIMH-Simulator

SIMH (History Simulator) des Computer History Simulation Project ist eine Sammlung von Simulatoren für historisch bedeutende oder einfach nur interessante Computerhardware und -software aus der Vergangenheit. Ziel des Projekts ist es, hoch portable Systemsimulatoren zu erstellen und diese als Freeware im Internet mit frei verfügbaren Kopien bedeutender oder repräsentativer Software zu veröffentlichen.
Das Projekt soll zudem dazu dienen, älterer Software weiterhin eine Umgebung zu bieten, auch wenn die Original-Hardware nicht mehr zur Verfügung steht. Auch wird es verwendet, um Betriebssysteme wie OpenVMS, RSTS, RSX-11, RT-11, TOPS-10 oder TOPS-20 auf PCs laufen zu lassen.

Unter der Liste der emulierten Hardware sind folgende Computer vertreten:

  • einige der PDP-und VAX-Reihe von Digital Equipment Corporation
  • Nova und Eclipse von Data General
  • Großrechner von IBM der 700er-/7000er-Serie
  • Minicomputer von Hewlett-Packard und Honeywell
  • die CDC 1700 von Control Data Corporation
  • den Microcomputer Altair 8800 von MITS (wahlweise mit Zilog Z80 oder Intel 8080 Prozessor)
  • und viele andere

Die aktuelle, stabile Version vom SIMH ist die 3.x. Diese ist auch in allen aktuellen und namenhaften Linux-Distributionen, sowie BSD-Systemen als vorkompiliertes Paket in den Repositories enthalten. Ich aber hingegen bevorzuge lieber den aktuellen Beta-Zweig v4.0 – 19-01 Current von der GitHub Projektseite. Dies hat auch mehrere Gründe.:

  • In der aktuellen Beta 4 ist bereits USE_NETWORK als Teil der Kompilierungsbefehlszeile definiert, damit die PDP-11- und VAX-Simulatoren die Ethernet-Emulation unterstützen.
  • Neben der Emulation von DECs VAX11/780 und MicroVAX3900 aus dem SIMH-Zweig 3.x, wurden in dem Beta-Zweig 4.x Current weitere VAX-Modelle implementiert. – Allerdings muss ich dazu sagen, dass bei meinen Internetrecherchen ich festgestellt habe, dass andere User von fehlerhafter Netzwerkunterstützung berichteten. Ich selber habe bei einigen neu hinzugefügten VAX-Modellen das Problem gehabt, die Datenträger korrekt zu definieren und der Emulator konnte die virtuellen Geräte nicht ansprechen.
  • Von allen (neuen) VAX-Modellen sind die Boot-ROMs mit den eventuellen Patch-Dateien enthalten. Gerade bei Linux-Distributionen wie Debian-Linux, welche den Fokus haben, im Wesentlichen ein System aus freier Software zu bestehen, fehlen die Boot-ROM-Dateien, da sie proprietären Bytecode enthalten.

Um den aktuellen Beta-Release des SIMH-Emulators nun auf dem Computer installieren zu können, ist es wichtig folgende Pakete vorher zu installieren, sofern noch nicht geschehen. (als Benutzer root unter Debian-Linux):

apt-get update && apt-get install git build-essential

Quellcode des aktuellen Beta-Releases laden und den Emulator – zum Beispiel einer MicroVAX3900 von DEC – kompilieren.

$make {simulator-name (i.e. vax)}

git clone https://github.com/simh/simh.git
cd simh
make vax

Die so erstellte Binärdatei wird im SIMH-Verzeichnis in dem Unterverzeichnis BIN/vax gespeichert.

Damit das emulierte System auch Teil des heimischen IPv4 Netzwerkes ist, habe ich bereits in meinem Blog-Artikel „Netzwerk-Bridge unter Linux mit TUN/TAP“ beschrieben, wie unter einem Debian-basierten Linux eben diese einzurichten ist.

Start-Konsole
Start-Konsole mit Hilfe Übersicht

Um die Simulation der MicroVAX3900 nun starten zu können, muss lediglich die erstellte Binärdatei noch ausgeführt werden. SIMH startet dann immer erst in den Kommandomodus. Diese Konsole ist sehr mächtig und beinhaltet eine sehr umfangreiches Hilfesystem in dem alle Parameter zur Ausführung der Simulation, sowie die unterstützten Hardwarekomponenten des emulierten Computersystems aufgeführt werden. Ferner kann über die Konsole auch ein Log über die Simulation erstellt werden.

SIMH-Hilfe show-Befehl
SIMH-Hilfe show-Befehl
Zusätzliche Informationen der Hilfe
Zusätzliche Informationen der Hilfe
Informationen der Specifikationen
Informationen der Specifikationen

Mit der Konsole können auch dann direkt die Maschinen-spezifischen Parameter gesetzt werden und zur Ausführung für ein Betriebssystem der Hardware die Emulation gestartet werden.

Parameter und Boot
Parameter setzen und Boot

Es sei nochmal darauf hingewiesen, dass SIMH neben der VAX-Reihe von DEC auch andere Computerarchitekturen (anderer Hersteller) simuliert. Daher ist die Konsole von SIMH auch bei den anderen Simulatoren ähnlich umfangreich. – Zum Beispiel habe ich die Altair-Emulation mit dem Zilog Z80 Prozessor mal kurz ausprobiert gehabt.

Links: