Netz - Rettung - Recht

Vergangene Woche hatte ich darüber berichtet, wie man - unter Debian Jessie - PHP-FPM mit mod_fastcgi installieren kann. In den Kommentaren hatte Sven mir dann nachfolgend erläutert, wie sich die Einbindung einfacher und besser über mod_proxy_fcgi lösen lässt, vorausgesetzt, man hat (wie in Debian Jessie) einen Apache 2.4 vor sich.

Da mir das ebenfalls vorzugswürdig erscheint, beschreiben ich in der Folge nunmehr diese Variante.

Nach über einem Jahrzehnt habe ich dieser Tage mal wieder einen Eggdrop installiert und konfiguriert - einen IRC-Bot, für diejenigen, denen letzteres mehr sagt als ersteres. Das ist ganz praktisch, denn u.a. loggt der Bot einen Channel mit, so dass sich aus dem Log ebenso lustige wie unsinnige bunte Statistiken erzeugen lassen, und zum anderen kann er mir morgens das Logfile des letzten Tages mailen, damit ich nichts wichtiges verpasse: FOMO at its best. (Wobei ich gestehen muss, seit Jahren nicht mehr in die Mails hineingeschaut zu haben, aber nun gut.)

Statische Webseiten sind nett (und durchaus wieder im Kommen), aber zumindest für manche Zwecke sind dynamisch generierte Seiten und die auf diese Weise ermöglichte Interaktivität doch dann besser oder gar notwendig. Facebook, bspw., würde sich als statische Seite dann doch eher schwierig gestalten.

Die Welt dynamischer Webseiten

Scriptsprachen

Dynamisch generierte Seiten bedingen, dass beim Aufruf einer Webseite nicht nur eine auf dem Server abgelegte Datei angezeigt wird, sondern dass ein Programm dort läuft, das die Ausgabe mehr oder weniger live generiert. Das hat ganz andere Implikationen für die Sicherheit des Servers, denn nunmehr läuft dort von außen erreichbarer Code, der schlimmstenfalls noch durch die Nutzer selbst aufgespielt werden kann. Nicht jeder, der seine ersten Gehversuche mit Scripts macht, hat dabei auch Fragen der IT-Sicherheit ausreichend im Blick - um das Problem einmal stark verharmlosend zu beschreiben. Gerade PHP hat nicht den Ruf, zumindest in den ersten Jahren seiner Entwicklung großes Gewicht auf das Fördern oder gar Erzwingen sicherer Praktiken gelegt zu haben, und viele lern(t)en es vor allem als eine Art Templating-Sprache kennen, die man irgendwie in seine HTML-Seiten einbettet, um ihnen damit eine erweiterte Funktionalität zu verleihen, ohne dabei groß an Konsequenzen zu denken (schuldig, euer Ehren!).

Rechteprobleme

Besondere Schwierigkeiten kommen hinzu, wenn mehr als ein Benutzer auf dem Server Scripts nutzen will. Denn wenn der Webserver bzw. der von diesem gestartete Interpreter das Script ausführen will, muss er es lesen können. Dann muss er aber - logischerweise - auch die Scripts aller anderen nutzer lesen können, was bedeutet, dass Nutzer A ein Sript schreiben kann, mit dem er sich die Scripts von Benutzer B anzeigen lassen kann, samt aller dort gespeicherten Informationen (Datenbankpassworte usw.), ebenso wie Dateien, die Benutzer B anlegt. Und wenn das Script irgendwelche Dateien anlegt (man denke an hochgeladene Bilder), dann werden diese Dateien unter der Nutzerkennung des Webservers angelegt, so dass der Benutzer dann keinen vollen Zugriff darauf hat. Das ist alles etwas unschön, weshalb man schon bald die Möglichkeit geschaffen hat, Scripts (sei es Perl, sei es Python, sei es PHP) unter der Benutzerkennung des jeweiligen Nutzers laufen zu lassen, dem das Script “gehört”.

suexec und suphp

Das schafft zwar andere Probleme, insbesondere im Bereich der Performance, denn nun kann ein Webserverprozess nicht mehr beliebig viele Scripts in parallelen Threads abarbeiten, weil diese ja vielleicht verschiedenen Nutzern gehören, so dass für jedes Script ein neuer Interpreter-Prozess gestartet werden muss, aber es ist doch in der Regel vorzugswürdig.

Für Scripts, die über die CGI-Schnittstelle (ja, ich weiß, das “I” steht schon für “Interface”) gestartet werden, stellt suexec die entsprechende Funktionalität bereit. Für PHP tat das traditionell suphp. suphp gibt es aber in Debian Jessie nicht mehr. Was also tun?

Als Lösung bietet sich PHP-FPM an.

Hat man dem eigenen Webserver erfolgreich SSL beigebracht und für ein valides Zertifikat gesorgt, bspw. mithilfe von Let’s Encrypt, finden sich in der Konfigurationsdatei (bei Debian: /etc/apache2/mods-available/ssl.conf) noch etliche Schrauben und Rädchen, an denen man drehen kann.

Bereits vergangene Woche berichtete ich von meinen Irrungen und Wirrungen des letzten Jahrzehnts mit SSL/TLS im Web. Erst Ende 2015 hatte ich mich aufgerafft, über StartCom für einige Domains Zertifikate erstellen zu lassen, und parallel die Berichterstattung über Let’s Encrypt verfolgt.

Der Workflow für die Erstellung und Pflege von HTTPS-Zertifikaten kann schnell komplex werden:

• Am Anfang steht die Erzeugung eines Schlüsselpaares, denn das spätere Zertifikat wird nur derjenige verwenden können, der auch den passenden privaten Schlüssel hat.
• Dann ist für jedes Zertifikat ein Certificate Signing Request (CSR) zu erstellen; das ist quasi die Roh-Form des späteren Zertifikats mit den notwendigen Informationen, die darin enthalten sein sollen.
• Dieser CSR muss dann von der Zertifierungsstelle (Certificate Authority, CA) digital signiert werden.
• Das so entstandene Zertifikat muss gespeichert und in die Webserver-Konfiguration eingebunden werden.
• Der ganze Ablauf ist nur zielführend, wenn die CA von den verbreiteten Browsern anerkannt ist, den von ihr signierten Zertifikaten also vertraut wird. Dafür wollen die meisten CAs Geld. Zudem müssen sie sich über einen mehr oder weniger aufwendigen Weg zumindest vergewissern, dass derjenige, der ein Zertifikat für einen bestimmten Hostnamen ausgestellt haben möchte, über diesen auch verfügen kann.
• Zertifikate werden in der Regel nur für einen begrenzten Zeitraum - meistens ein Jahr - ausgestellt. Danach müssen sie (rechtzeitig!) verlängert werden.

Let’s Encrypt ist angetreten, diese Abläufe weitestmöglich zu vereinfachen.

Datenströme im Netz zu verschlüsseln ist wichtig, aber auch zunehmend Allgemeingut. Telnet würde sicherlich niemand mehr zum Zugriff auf einen entfernten Rechner nutzen; stattdessen nimmt man SSH. Auch bei anderen Protokollen ist die Übertragung von Passworten im Klartext schon lange out: es fing an mit APOP für den Zugriff über POP3 und CRAM-MD5 für SMTP-Auth, und schon etliche Jahre nutze ich nur noch POP3S/IMAPS/SMTPS, also eine komplette Verschlüsselung des gesamten Datenstroms. So hat auch das auf SSH basierende SCP/SFTP schon lange FTP ersetzt, und nachdem sich mittlerweile auch NNTPS und der verschlüsselte Zugriff auf IRC-Server verbreitet haben, bleiben nur noch wenige Protokolle “offen”.

Selbstverständlich sollte auch - zumindest - die Übertragung von Passworten via HTTP gesichert werden, was die Einrichtung von HTTPS erfordert. Je mehr sich webbasierte Dienste und Apps verbreiten, desto wichtiger ist das. Es ist allerdings - leider - nicht ganz so einfach.

Serendipity, kurz s9y, ist das Blogsystem, mit dem dieses Blog betrieben wird, und Serendipity ist - unter diesem Namen - gestern ein Teenager geworden.

Damit ist es ungefähr so alt wie dieses Blog, das am 01.06.2016 seinen 13. Geburtstag feiern wird, und begleitet mich auch schon fast so lange, nämlich seit dem 01.01.2005 (wobei ich ja fast vermute, dass der Schnitt nicht ganz so exakt auf dieses Datum fiel, aber was will man machen?).

Mehr Glückwünsche:

• Happy Birthday Serendipity
• Die wilde dreizehn …

Eigentlich wollte ich schon vor gut drei Jahren, im Januar 2013, über dieses Thema schreiben, als ich die ersten Backup-Jobs dieser Art eingerichtet habe, aber irgendwie ist aus dem angefangenen Entwurf nie ein fertiger Blogeintrag geworden. - Nun denn, auf ein neues.

Nicht nur der heimische Rechner will regelmäßig gesichert werden; auch bei dedizierten Servern oder vServern ist ein regelmäßiges Backup vonnöten, um im Falle eines Falles nicht ohne (Code und) Daten dazustehen. Früher war es üblich, dass zu einem Server auch ein - meist per FTP zugänglicher - Backupplatz gehörte, der genügend Raum für ein Backup (auch über mehrere Generationen) bot. Mittlerweile müssen solche Angebote aber nicht selten kostenpflichtig hinzugebucht werden oder stehen gar nicht mehr zur Verfügung. Zwar ist es natürlich möglich, die Datensicherung auf einen anderen (eigenen oder fremden) Server durchzuführen, wobei sich die Maschine im heimischen Keller in der Regel wegen der geringen Upload-Bandbreiten nicht anbietet - schließlich will man nicht nur sichern, sondern notfalls auch wiederherstellen können. Eine Alternative ist aber Cloud-Speicher, bspw. Amazons S3 (Simple Storage Service). Die Kosten sind bei inkrementiellen Backups überschaubar: ein Gigabyte Speicherplatz kostet pro Monat ungefähr 3 Cent, dazu kommen noch geringen Kosten für Zugriffsoperationen in der Größenordnung von einem halben Cent pro 1.000 Zugriffe und für den ausgehenden Traffic - also vor allem für einen Restore - 9 Cent pro GB, jeweils zzgl. MWSt. Wöchentliche inkrementielle Backups mit monatlichen Vollbackups für vier Server kommen auf gut 10$.

Wer - privat oder beruflich - Outlook nutzt, weiß wahrscheinlich, dass die dort gespeicherten Inhalte - E-Mails, aber auch Kontakte, der Kalender, Aufgaben u.a. - in einer .pst-Datei abgelegt werden, wobei diese Abkürzung für Personal Storage Table steht. Wird Outlook an einem Exchange-Server betrieben, wird man in der Regel auf seinem lokalen Rechner eine .ost-Datei finden, eine Off-line Storage Table, die die auf dem Server gespeicherten Inhalte offline bereitstellt, falls zum Server keine Verbindung besteht.

Das Exportieren der eigenen Daten ist daher auch vergleichsweise leicht: sie lassen sich aus Outlook heraus in eine .pst-Datei exportieren und aus einer solchen auch wieder importieren. Was aber, wenn man eine .pst-Datei ohne Outlook lesen möchte? Oder wenn der Export scheitert, weil - bspw. am Arbeitsplatz - der Zugriff auf .pst-Dateien gesperrt worden ist?

In beiden Fällen helfen Tools. Konvertierungsprogramme von .ost nach .pst finden sich bei Google. Und - bspw. - der PST Viewer von PST Walker Software kann sowohl .pst- als auch .ost-Dateien anzeigen. Weitere Tools können in das und aus dem proprietären .msg-Format konvertieren oder auch E-Mails u.a. als .eml-Dateien speichern.

Es fing harmlos mit einem Beitrag von Kris Köhntopp bei Google+ an:

C64 Archon als Browsergame. Endlich mal was sinnvolles.

Allerdings macht es nicht sehr viel Spaß, Archon gegen sich selbst zu spielen.

Aber so stieß ich immerhin auf “World of Longplays” bei Youtube und stellte fest, dass es Videos von einer Vielzahl wohlvertrauter Spiele aus meiner Kindheit und Jugend gibt, ausreichend, um stundenlang in Nostalgie zu versinken: Archon. Adept (Archon II). Raid on Bungeling Bay. Ghostbusters. Bruce Lee. The Last Ninja. Defender of the Crown. The Great Giana Sisters. Und North & South. Und Pirates!. Wobei mir auffiel, dass es davon Remakes für Windows gibt. Und die gibt es interessanterweise dann auch für wenig Geld bei Steam, nämlich “The Bluecoats: North vs South” und “Sid Meier’s Pirates!”.

Das habe ich dann auch direkt ausprobiert - wenn schon einmal Wochenende ist …

Was soll ich sagen … erneut gäbe es viel zu berichten aus der Welt von Elite: Dangerous: über das letzte Update, instabile Server, gemeinsame Unternehmungen mit anderen Spielern weltweit, neue Missionen, neue Erfahrungen, neue Schiffe; aber wiederum hat die fürs Spielen investierte Zeit nicht genug Zeit zum Schreiben gelassen. Und da ich nunmehr für die kommenden Wochen zeitlich wiederum anderweitig verplant bin, werde ich auch nicht dazu kommen, all das nachzuholen.

Ich kann - leider - nur erneut ein paar Bilder sprechen lassen:

Eine Vulture vor einer Sonne.

Eine Sidewinder, das Schiff, mit dem jeder Spieler startet, bei der “Betankung” in der Corona eines Sterns.

Ein Federal Assault Ship, einer der neuen Schiffstypen aus Version 1.4.

Ein Federal Assault Ship beim “Tanken”, gesehen aus Sicht des Sterns.

Und ja: das Spiel fasziniert. Ungemein.

[Dieser Eintrag wurde nachträglich im November 2015 veröffentlicht.]

Still ist es geworden die letzten Wochen hier im Blog nach der Urlaubsrückkehr … dabei hätte es allerlei zu schreiben gegeben, namentlich über meine Wege durch die Weiten von Elite: Dangerous, dem ich die letzten Wochen große Teile meiner arbeitsfreien Zeit gewidmet habe.

Und eigentlich hatte ich auch vor, zu berichten: über das Missions-System, über Community Goals und meinen Flug weit raus nach Hutton Orbital zum dortigen Community Goal, mit dem ich mein neues “Allround”-Schiff, eine ASP Explorer, eingeweiht habe. Über meine Erfahrungen damit und die - späte - Erkenntnis, dass ein Schiff mit großem Frachtraum und großer Reichweite deswegen noch nicht optimal für den Weltraum-Kampf geeignet ist. Über meine neueste Erwerbung, einen Imperial Courier, der mir das - im Vergleich - vermittelt hat. Und … und … und …

Aber leider fehlt die Zeit, daher will ich es mit einem Bild belassen:

Black Arrow, eine ASP Explorer.

[Dieser Eintrag wurde nachträglich im November 2015 veröffentlicht.]

Wie praktisch ist es für die Illustration von Blogbeiträgen aus dem Urlaub doch, wenn man einen Ehepartner hat, der gerne, gut und viel fotografiert. Man bittet einfach schnell um die Speicherkarte aus der Kamera, findet im kleinen Netbook, das die Flugreise mitgemacht hat, sogar einen passenden Schlitz für den Leser und bedient sich dann aus der reichen Bilderauswahl. Gut, bei mehreren hundert (großen) Fotos war es vielleicht keine so kluge Idee, im Explorer große Symbolbilder anzeigen zu lassen … der Rechner rödelt nämlich vor sich hin und mag nicht mehr reagieren. Aber man kann den Explorer ja zwangsweise schließen oder notfalls den Prozess im Taskmanager beenden. Und wenn auch das nicht hilft, fährt man den Rechner eben runter. Und wenn er im Shutdown-Bildschirm hängt, kann man immer noch hart den Strom abschalten - einige Sekunden lang den Power-Knopf zu drücken genügt.

Vielleicht wäre es allerdings klug gewesen, das nicht mit der SD-Karte im Leser zu machen. Oder sie nicht während des Shutdowns herauszunehmen. Oder wenigstens vorher die Schreibschutzlasche auf “locked” zu schieben. Dann hätte die SD-Karte danach vielleicht auch noch ein Filesystem gehabt. Konkret hatte sie leider keines mehr. Das bedeutet: keine Bilder für den Blogbeitrag, sehr begrenzte Begeisterung bei der Fotografin …

Zurück in heimische Gefilde und am größeren Laptop dann der Versuch einer Rettung. Von PhotoRec habe ich bisher viel Gutes gehört - insbesondere soll das Programm auf einer Ebene unterhalb des Filesystems arbeiten, so dass dessen Fehlen nicht stört, und rein lesend, d.h. auch auf einer schreibgeschützten Karte, agieren können. Und, was soll ich sagen? Es funktioniert. Einfach, zuverlässig, toll.

Die Schritt-für-Schritt-Anleitung beschreibt die Vorgehensweise: defekte Karte einlegen, PhotoRec mit Administratorrechten starten, zu rettendes Laufwerk und Partition auswählen, Art des Filesystems angeben und wählen, ob nur der unallozierte Platz (gelöschte Dateien) oder die komplette Partition gescannt werden soll, Verzeichnis für die geretteten Dateien (auf einem anderen Datenträger …) angeben, und los geht es. PhotoRec scannt die nicht mehr als formatiert erkannte SD-Karte, rettet alle Dateien - nicht nur Fotos -, die es findet, und speichert sie am angegebenen Ort. Dabei erhalten Bilddateien als Zeitstempel (modification time) den aus den Metadaten (EXIF) ausgelesenen Aufnahmezeitpunkt, außerdem werden enthaltenen Thumbnails nochmals gesondert extrahiert. Auf diese Weise kann man die Dateien nach dem Aufnahmezeitpunkt ordnen und sie auch schnell durchblättern, also die “richtigen” Bilder zügig finden. Das ist deshalb wichtig, weil PhotoRec natürlich nicht nur die verlorenen 400 Urlaubsbilder findet, sondern über 2.000 andere, längst gelöschte Fotos aus den letzten drei oder vier Jahren.

Fazit: Operation gelungen, Haussegen hängt wieder gerade.

Nach einigen erfolgeichen Bergbau-Expeditionen mit meinem neuen Transporter muss ich gestehen, dass mich das Leben als Bounty Hunter doch etwas mehr reizt. Schon vor dem Kauf des Transporters hatte ich daher wieder einige Missionen mit meiner treuen Cobra eingeschoben und so die Einstufung Competent und den Rank “Cadet” in der Federal Navy erreicht.

Eine Sidewinder als “Taxi”.

Nach der Lektüre des Tutorials “Bounty Hunting Locations & Primer” habe ich daher meinen Transporter an Ort und Stelle geparkt, mir als “Taxi” eine günstige Sidewinder zugelegt und meine Cobra wieder eingesammelt. Einige längere Ausflüge in “High Intensity Ressource Extraction Sites” in Zaonce und etwas Glück mit lukrativen Missionen (für bis zu 1 Mio. Credits) haben nicht nur mein finanzielles Polster ausgebaut, sondern auch meine Flugfähigkeiten verbessert, so dass ich allmählich das Gefühl bekomme, die Sache einigermaßen im Griff zu haben und auch mit mehreren Gegnern und etwas, aber nicht allzuviel größeren Gegnern klarzukommen. Außerdem habe ich so auch mit der Alliance den Status “friendly” und den Rang “Midshipman” bei der Federal Navy und “Outsider” bei der Imperial Navy erlangt, neben dem Status “allied” mit einigen “local factions.

Ein unangenehmes Erlebnis mit einer geborsteten Sichtscheibe brachte mich dazu, auch das Lebenserhaltungssystem gegen ein besseres Modell auszutauschen; außerdem habe ich mir eine stärkere Hüllenpanzerung zugelegt und meine Sekundärbewaffnung von zwei Multi-Cannons auf zwei Cannons geändert. Nach dem Einbau stärkerer Triebwerke ist jetzt allerdings die Energieversorgung nicht mehr ausreichend, so dass beim Ausfahren der Waffen zwangsweise einige (nicht so dringend benötigte) Systeme abgeschaltet werden müssen. Ob sich dieses neue Setup bewährt, wird sich zeigen müssen - nach unserem Urlaub, soweit sich dann mal wieder Zeit für einen längeren Raumflug findet.

Vielleicht habe ich bis dahin auch genügend Credits für einen Asp Explorer zusammengespart …

[Dieser Eintrag wurde nachträglich im September 2015 veröffentlicht.]

Ab und an etwas Abwechslung schadet nicht - nach diesem Motto habe ich mich vor rund 14 Tagen erstmals mit einer anderen Möglichkeit des Geldverdienens in Elite: Dangerous beschäftigt: dem Asteroiden-Bergbau. Gewappnet mit dem “Elite: Dangerous Mining Guide” und einer Liste von Systemen mit “Pristine Metallic“-Ressourcen habe ich meine noch im Dock herumstehende Adder für wenig Geld auf ein Bergbau-Schiff umgerüstet und meine ersten Erfahrungen gesammelt.

Dazu gehört,

• dass jeder Asteroid nicht mehr als ein halbes, allenfalls ein ganzes Dutzend abbaufähige Splitter hergibt;

• dass man - um das dröge und aufhaltsame manuelle Aufsammeln der Splitter zu vermeiden - nicht nur einen Collector Limpet Controller braucht, sondern auch die entsprechenden Dronen benötigt, die man als “Munition” kaufen kann, die aber auch jeweils eine Tonne Laderaum benötigen,

• dass man beim Starten einer Drone kein Ziel erfasst haben darf, weil sie sonst nur genau diesen Klumpen einsammelt und dann abschaltet, und

• dass in einem bloß als “metal rich” bezeichneten Ring nicht allzuviel wertvolles zu finden ist und es sich eigentlich nur wahrhaft lohnt, nach “(pristine) metallic” Ausschau zu halten.

Doch auch so ist die Bergbau-Tätigkeit einigermaßen aufhaltsam; nervig vor allem, dass die Raffinerie ständiges Händchenhalten benötigt, selbst wenn man in ein Modell mit sehr vielen Slots investiert hat, weil auch bei freien Slots (bspw. nach erfolgreicher Herstellung einer Tonne Rohstoff) die nächsten Metalle oder Mineralien wieder von Hand zugeordnet werden müssen. (Das allerdings soll immerhin in einem der nächsten Updates geändert werden.)

Störend auch, dass der knappe Frachtraum so schnell voll ist. Nach den ersten Probeflügen habe ich meine Adder daher in eine weitere Cobra umgetauscht, die zudem noch Platz für etwas Bewaffnung neben den Bergbau-Lasern hatte. Das ging schon besser.

Moria, ein Type-6-Transporter, gelandet auf einem Außenposten.

Richtig lohnenswert hat sich der Bergbau allerdings erst nach der Anschaffung eines (in dieser Ausbauvariante immerhin rund 4 Mio. Credits teuren) Type-6-Transporters gestaltet, den ich mir heute zugelegt habe. Damit lassen sich pro Stunde Flugzeit rund 500.000 bis 650.000 Credits verdienen, je nachdem. So lässt es sich arbeiten, auch wenn das Schiff nur auf ein mittelgroßes Landing Pad passt.

[Dieser Eintrag wurde nachträglich im September 2015 veröffentlicht.]