23
Aug
Gelesen: Vergebung von Stieg Larsson
Geschrieben von: Pfefferoni   

Lang hat es gedauert, aber in den vergangen Tagen habe ich den dritten und letzten Teil der Millenium-Triologie von Stieg Larsson beendet. "Vergebung" knüpft nahtlos an die Geschehnisse des zweiten Teils an und befasst sich eigentlich mit der Beleuchtung der Hintergründe dieser Geschehnisse. Die Erläuterungen im zweiten Teil waren also nur die Spitze des Eisbergs. Während der erste Teil bis auf die Protagonisten losgelöst von den Folgeromanen zu sehen war, ist der dritte Teil so eng mit dem zweiten verwoben, dass es m.E. äußerst respektabel ist, dass Stieg Larsson es geschafft hat, die Teile so zu schreiben, dass sie eigenständig lesbar sind, ohne dass sie für diejenigen langweilig werden, die schon die vorangegangenen Teile kennen.

[Nur lesen, wer den zweiten Teil kennt - Spoiler-Gefahr]

Die Morde, die im zweiten Teil zentrales Thema waren, sind aufgeklärt. Obwohl der Verdacht von Lisbeth abgelenkt ist und sie selbst Opfer schwerer Körperverletzung geworden ist, befindet sie sich in Untersuchungshaft. Mikael arbeitet derweil ununterbrochen an der Aufklärung der Hintergründe, die ihn bald selbst zur Zielscheibe werden lassen. Allerdings nicht von "gewöhnlichen" Verbrechern, sondern seitens des Staates. Der versucht nämlich die Ereignisse um Lisbeth, die sich im zweiten Teil als sehr bedeutend für die schwedische Sicherheitspolitik herausgestellt haben.
Obwohl Lisbeth isoliert wird, gelingt es Mikael ihr einen Teil ihrer Ausrüstung zu beschaffen. Auf die Art und Weise, kann Lisbeth weitreichende Recherchen durchführen, die später entscheidend für ihren Prozess und somit ihre Rehabilitation sein werden. Das dabei der ein oder andere auf der Strecke bleibt ist unumgänglich.

[Spoiler Ende]

Stieg Larsson lässt, wie aus den vorangegangen Teilen bekannt, wieder kein Detail aus, was es mir gerade zu Beginn des Buches schwer gemacht hat, am Ball zu bleiben. Der Roman nimmt dennoch stetig Fahrt auf und letztlich will man ihn gar nicht mehr zur Seite legen, weil es einen regelrecht danach lüstet zu sehen, wie das hochkomplexe Kartenhaus, das Larsson beschreibt, mit wenigen gezielten Eingriffen einstürzt.

Wer die ersten beiden Teile gelesen hat, kommt eigentlich nicht um diesen letzten herum. An mancher Stelle des Romans habe ich Ansatzpunkte für einen weiteren Teil erahnt. Doch leider wird es aus der Feder von Stieg Larsson keine weiteren Romane geben, da er bereits 2004 an einem Herzinfarkt verstorben ist.
Das Stieg Larsson weitere Teile in dieser Romanreihe geplant hat, ist belegt. Insgesamt sollten es wohl 10 Bücher werden, wobei 3 weitere Teile schon geplant waren und Teil 5 weitestgehend abgeschlossen war. Zur Veröffentlichung wird es jedoch nicht kommen, da Larssons Lebensgefährtin diesen Schatz in seinem Sinne hütet. Angesichts der veröffentlichten drei Teile und der Brisanz, die in ihnen steckt, hätten die weiteren sieben Teile wohl reichlich Sprengkraft in sich gehabt.

 
19
Aug
Dem Webserver SSL beibringen
Geschrieben von: Pfefferoni   

Das Aufsetzen eines Joomla-tauglichen Webservers habe ich ja schonmal ausführlich beschrieben. Jetzt stand ich vor der Aufgabe, diesen Webserver SSL-tauglich zu machen. Ich muss zugeben, von SSL und dem Erstellen von Zertifikaten nur wenig Ahnung zu haben. Dementsprechend bin ich auch erstmal einem Tutorial gefolgt, dass im Nachhinein betrachtet sehr rudimentär ist: Ich hatte ein Zertifikat erstellt, hier was kopiert, da was symbolisch verlinkt, den Apache-Webserver etwas umkonfiguriert und SSL lief. Mit Firefox war dieses Tutorial einigermaßen brauchbar. Ich brauchte das Zertifikat nur einmalig genehmigen und es lief. Der Internet Explorer sieht das allerdings etwas anders. Bei jedem neuen Besuch der Seite, beschwerte dieser sich über Zertifikatsfehler, gegen die auch das Importieren des Zertifikats nicht half.

Dank Chris bin ich dann auf die Fährte des Problems gelangt und seine zahlreichen Links und Tipps haben schlussendlich zum Ziel geführt. Meine Nutzer müssen nun nur noch einmalig ein Zertifikate importieren und werden im Internet-Explorer fortan nicht mehr mit Zertifikatfehlern genervt.
Ich habe übrigens Zertifikate selbst erstellen wollen, weil der Webserver nur in einem internen Netz verwendet wird. Er kann und wird somit nicht aus dem Internet angesprochen, womit ich ein kostenpflichtiges (und problemloses) Zertifikat einer Root-CA wie VeriSign überflüssig fand. Andererseits ist das interne Netz ziemlich groß und wird nicht nur von mir und meinen Nutzern verwendet, so dass ich Wert auf die verschlüsselte Übertragung gelegt habe.

Aus diesem Grund war es notwendig, dass ich mich selbst zu einer Certifcate Authority - kurz CA - mache, um meine selbsterstellten Zertifikate zu signieren. Ein Nutzer der Webseite braucht dann nur das CA-Zertifikat importieren und diesem vertrauen. Alle weiteren Zertifikate, die mit diesem signiert sind, werden dann automatisch als vertrauenswürdig eingestuft.

An dieser Stelle möchte ich nun meine Vorgehensweise zusammenfassen, die ich aus Tipps von Chris, Tutorials und persönlichen Trial&Error gesammelt habe.

Zertifikate ertsellen und signieren

Für das Erstellen der Zertifikate habe ich ein Tutorial von HowToForge verwendet, welches sehr ausführlich ist. Allerdings enthält es keine Anleitung zur Installation und vor allem Konfiguration eines Apache. Diesen Punkt habe ich weiter unten ausgeführt.

Zunächst habe ich stumpf nach Anleitung den Ordner 'CA' und darin 'newcerts' und 'private' angelegt. Ich habe dies im Home-Verzeichnis von root gemacht, da theoretisch noch andere Personen den Server administrieren können müssen und mein persönlicher Account nur temporär ist. Des Weiteren darf niemand unberechtigtes Zugriff auf diesen Ordner haben, da er Schlüssel enthalten wird, die geheimgehalten werden müssen. Sollte dieser private Schlüssel in falsche Hände gelangen, sind alle damit signierten Zertifikate nicht mehr vertrauenswürdig und müssen gesperrt werden.

server:~# cd /root
server:~# mkdir CA
server:~# cd CA
server:~# mkdir newcerts private

Im Ordner CA werden nun die Dateien 'serial' und 'index.txt' erzeugt. 'serial' dient - wie der Name schon andeutet - als Quelle für eindeutige Seriennummer und wird bereits beim erstellen mit '01' belegt. Jedesmal wenn ein Zertifikat erstellt wird, wird diese Ziffer automatisch hochgezählt. 'index.txt' stellt eine kleine Datenbank dar, in der meine erstellten Zertifikate verwaltet werden.

server:~# echo '01' >serial
server:~# touch index.txt

Als nächstes wird eine Konfigurationsdatei namens 'openssl.cnf' erstellt

server:~# vi openssl.cnf

und mit folgenden Inhalt befüllt

#
# OpenSSL Konfigurationsdatei
#
dir = .

[ ca ]
default_ca    = CA_default

[ CA_default ]
serial = $dir/serial
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/cacert.pem
private_key = $dir/private/cakey.pem
default_days = 365
default_md = md5
preserve = no
email_in_dn = no
nameopt = default_ca
certopt = default_ca
policy = policy_match

[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ req ]
default_bits = 1024 # size of keys
default_keyfile = key.pem # name of genarted keys
default_md = md5 # message digest algorithm
string_mask = nombstr # permitted characters
distinguished_name = req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
# Variable name          Prombt string
#---------------------      --------------------
0.organizationName = Organization Name
organizationalUnitName = Organizational Unit
emailAddress = Email Address
emailAddress_max = 40
localityName = Locality Name
stateOrProvinceName = Province or State
countryName = Country Name (2 letter code)
countryName_min = 2
countryName_max = 2
commonName = Common Name
commonName_max = 64

# Default values for the above,    for the consistency and less typing.
# Variable name            Value
#-----------------------------    ------------------------------------
0.organizationName_default = Meine Firma
localityName_default = Meine Stadt
stateOrProvinceName_default = Mein Bundesland
countryName_default = DE

[ v3_ca ]
basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always

[ v3_req ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash

Konfigurationsdatei zum Download (muss anschließend in openssl.cnf umbenannt und an die eigenen Gegebenheiten angepasst werden).

Die Bedeutung der einzelnen Abschnitte können oben erwähnten HowTo entnommen werden. Ab jetzt werden Zertifikate erstellt. Als erstes wird das Zertifikat und der private Schlüssel der CA erstellt:

server:~# openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem↵
-out cacert.pem -days 3650 -config ./openssl.cnf

Mit 'req -x509' wird das eigentliche Zertifikat generiert, '-extensions v3_ca' gibt dabei die Art des Zertifikats an, wie es im entsprechenden Abschnitt der Konfiguration angegeben ist (hier also ein CA-Zertifikat mit Passwort). Der private Schlüssel wird in das 'private'-Verzeichnis geschrieben, des Zertifikat selbst in den aktuellen Ordner. Das Zertifikat der CA selbst erhält eine Lebensdauer von 10 Jahren. Das ist durchaus sinnvoll, da mit Ablauf des CA-Zertifikats alle damit signierten Zertifikate ihre Gültigkeit verlieren würden. Die Gültigkeit der einzelnen Zertifikate ist in der Konfigurationsdatei mit 'default_days = 365' auf ein Jahr festgelegt.

Im nächsten Schritt wird der Zertifikats-Request erstellt, mit dem zukünftig der Webserver authentifiziert werden soll.

server:~# openssl req -new -nodes -out req.pem -config ./openssl.cnf

Im folgenden Dialog sind der "Organizational Unit Name" (OU), die Kontak-Email-Adresse sowie der "Common Name" (CN) nacheinander anzugeben. Als OU kann man einen Hinweis daruf geben, wofür das Zertifikat gedacht ist (bsp. eben für den Webserver). Der CN ist die IP oder FQDN des Systems, dass mit diesem Zertifikat authentifiziert werden soll. Im Falle des Webservers wäre das genau die Adresse, die man im Browser angeben würde. Ist der CN falsch und stimmt nicht mit der Adresse überein wird sich der Browser über einen Zertifkatfehler beschweren, da er davon ausgeht, dass das Zertifikat missbraucht wird (dieser Fehler ist mir u.a. auch unterlaufen, weshalb der IE sich so penetrant beschwert hat).
Als Ergebnis erhält man zwei Dateien: den privaten Schlüssel des Zertifikats (key.pem) und den Zertifikats-Request (req.pem). Dieser Request kann übrigens wiederverwendet werden, wenn das Zertifikat nach Ablauf der Gültigkeit erneut signiert werden muss. Beide Dateien sollte man also aufheben.

Nun muss der Zertifikats-Request von der selbsterstellten CA signiert werden. Das abgefragte Passwort ist jenes, welches beim Erstellen des CA-Zertifikats zu Beginn vergeben wurde.

server:~# openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem

Als Output erhält man das Zertifikat (cert.pem) sowie eine Kopie im Ornder 'newcerts', welche die aktuelle Seriennummer (aus 'serial') als Namen trägt. Die Datenbank 'index.txt' wurde um einen Eintrag erweitert.
Jede Zeile darin steht für ein Zertifikat. In der ersten Spalte steht ein Buchstabe, der das jeweilige Zertifkat als gültig (V wie valid), abgelaufen (E wie expired) oder zurückgezogen (R wie revoked) kennzeichnet. In der zweiten Spalte ist das Ablaufdatum des Zertifikats angegeben in der Form YYMMDDHHmmssZ (wobei Z für Zulu-Zeit steht - also Greenwich Mean Time). Die dritte Spalte enthält das Rückzugsdatum des Zertifikats und ist beim Status V oder E entsprechend leer. Die vierte Zeile enthält die Seriennummer, die aus der 'serial' heraus vergeben wurde. Die fünfte Spalte enthält den Speicherort und die sechste Spalte den Distinguished Name (also C,ST,O,OU und CN wie sie im CA-Zertifikat bzw. dem ausgestellten Zertifikat festgelegt wurden).
Die Ausgabedatei enthält nun die verschlüsselte und die lesbare Version des Zertifikats. Um beides zu trennen ist folgendes nötig:

server:~# mv cert.pem tmp.pem
server:~# openssl x509 -in tmp.pem -out cert.pem

Zu guter Letzt muss das CA-Zertifikat an den Nutzer gebracht werden. Je nach Möglichkeiten kann man es auf Netzlaufwerken oder per Mail den Nutzern zukommen lassen. Man kann das Zertifikat aber auch zum Download als crt-Datei anbieten. Dazu reicht es die Datei 'cacert.pem' in das www-Verzeichnis zu kopieren und umzubennen und die Besitzverhältnisse neu zu regeln.

server:~# cp cacert.pem /var/www/meinpfad/beliebiger_name.crt
server:~# chown www-data:www-data /var/www/meinpfad/beliebiger_name.crt

Das Zertifikat kann nun über die entsprechende Web-Adresse abgerufen werden. Beim Öffnen des Zertifikats wird man in der Regel automatisch durch die lokale Installation geführt. Anschließend sollten alle damit signierten Zertifikate anstandslos von IE und Firefox akzeptiert werden.

Apache SSL-fähig machen

Um den Apache SSL-fähig zu machen, bin ich wie folgt vorgegangen. Ich habe zunächst im Apache-Ordner ein Verzeichnis für Zertifikate angelegt und mein Zertifikat nebst Schlüssel dorthin kopiert.

server:~# mkdir /etc/apache2/ssl
server:~# cp /root/CA/cert.pem /etc/apache2/ssl/cert.pem
server:~# cp /root/CA/key.pem /etc/apache2/ssl/key.pem

Im Ordner '/etc/apache2/sites-available' habe ich nun eine neue Datei namens 'ssl' angelegt

server:~# vi /etc/apache2/sites-available/ssl

und mit folgendem Inhalt befüllt:

<VirtualHost *:443>
DocumentRoot "/var/www/pfad"
  <Directory "/var/www/pfad">
    allow from all
    Options +Indexes
  </Directory>
  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/key.pem
</VirtualHost>

Nun noch einen Link unter 'sites-enabled' auf die eben erstellte Datei setzen

server:~# ln -s /etc/apache2/sites-available/ssl /etc/apache2/sites-enabled/ssl

Damit der Apache auch weiß, dass er auf Port 443 lauschen soll, notiert man dies in der '/etc/apache2/ports.conf' mit

Listen 443

Abschließend muss das SSL-Modul akitiviert und Apache neu gestartet werden

server:~# a2enmod ssl
server:~# /etc/init.d/apache2 restart

Alternativ kann man diese Konfiguration auch im Webmin vornehmen. Ab diesem Zeitpunkt sollte der Webserver SSL-verschlüsselt laufen.

Ich hoffe, das ich nichts vergessen oder durcheinander gebracht habe. Wenn doch, möge man mich kurz per Mail, Kommentar oder Twitter darauf hinweisen und ich arbeite dann die Korrektur ein. Ich kann Fehler - gerade im Bereich Apache - nicht aussschließen, da ich durch ein zu schnelles 'Enter' mir zwischenzeitlich die komplette Apache-Konfigurations zerschossen habe.
U.a. bekam ich auch die Fehlermeldung "Could not bind on address [::]:443" beim Start des Apache, was daran lag, dass - warum auch immer - in der 'ports.conf' zweimal der Eintrag 'Listen 443' stand.

 
17
Aug
Mein sportliches Motivationsloch und ich ...
Geschrieben von: Pfefferoni   

Was Sport den lieben Sport angeht, befinde ich mich derzeit in einem absoluten Tief. Seit Wochen bin ich nicht dazu gekommen, außer mich aufs Pferd zu setzen, auch nur einen Meter zu Laufen, Schwimmen, Radeln oder sonstwie sportlich zu betätigen. Gut, zwischendurch hat es mich 2 Wochen mit Erkältung außer Gefecht gesetzt, aber selbst wo ich jetzt wieder gesund bin und eigentlich keine Ausrede habe, fällt es mir schwer, etwas zu tun.

Es ist aber auch grad irgendwie komisch: Ich weiß, dass ich etwas Sport treiben sollte, damit die mühsam antrainierte Fitness nicht den Bach runtergeht. Andererseits fühl ich mich grad so pudelwohl in meiner Haut, dass ich keinen Anlass sehe, Sport zu machen, weil zum Beispiel gerade kein Bedürfnis habe, Pfunde zu verlieren oder groß Muskeln aufzubauen. Dann ist da dieses elendige Wetter: Planen kann man schonmal gar nicht, Laufen auf Tartan oder Trimmdichpfad ist bei den Wassermassen - naja - unangenehm, Radeln sowieso und außerdem gefährlich, Schwimmen ginge natürlich, aber da hakt dann so ein psychologischer Effekt (oder so) ein, dass Regenwetter und Schwimmen (Wasser, Sommer, Sonn) sich irgendwie wiedersprechen.

Ich könnte natürlich in den Fitnessraum. Ausdauer (auf dem Stepper oder Fahrrad) kombiniert mit Muskelaufbau an den Geräten scheint ja eh die effektivste Art des Abnehmens und Trainierens zu sein ohne dem Jojo-Effekt zu wiederfallen. Fitnessraum verbinde ich aber mit Herbst und Winter, wenn Outdoor-Sport schon wegen den Temperaturen kaum geht (ich weiß, es gibt kein schlechtes Wetter, nur falsche Kleidung, aber das ist nunmal so bei mir verankert). Also tu ich mich jetzt im vermeintlichen Sommer schwer, dahin zu gehen.

Und allgemein: Dieses Wetter raubt mir jegliche Motivation mein Büro oder Wohnung zu verlassen. Jetzt hab ich es!
Ich geb dem Wetter die Schuld,

- also der Erderwärmung,
- also dem Klimawandel,
- also den Treibhausgasen und Feinstaub,
- also allgemein der Luftverschmutzung,
- also eigentlich den Luftverschmutzern,
- also ganz speziell den Autofahrern,
- also im Einzelnen doch ich selbst.

Verdammt.

 
11
Aug
BuntZeit
Geschrieben von: Pfefferoni   

Ich hatte ja jüngst davon berichtet, dass ich wieder mit dem Malen angefangen hab. Da Morrighan so viel von der BuntZeit geschwärmt hat und da das offene Atelier in Wolnzach ist (quasi um die Ecke - 65km), hab ich mich kurzer Hand bei Petra Dockendorf angemeldet, um den Pinsel zu schwingen. Am Montag war ich dann zum ersten Mal da und ich versprech, dass es nicht das letzte Mal war.

Zunächst wusste ich gar nicht was ich malen sollte. Ich hab mir daher eine Handvoll Fotos geschnappt und hab dann vor Ort spontan entschieden, was es werden soll - meine Pfefferoni. Während die Grundierung getrocknet ist, hab ich noch ein kleines Bild gemalt, wo ich wirklich nur den Pinsel aufgesetzt hab und geschaut hab, wohin es geht. Das Bild von meiner Pfefferoni ist natürlich noch nicht fertig, weil ich eine 50x60cm Leinwand gewählt habe und gerade der Kopf ist nicht mal eben so hingemalt, aber es ist schon deutlich zu erkennen, wohin es geht. Morrighan hat übrigens wieder alle Eindrücke in einer Collage zusammengefasst.

Meine Pfefferoni ist in der oberen Reihe als drittes Bild zu sehen und mein kleines Pinsel-Schwing-Bild kann man in der Totalaufnahme unten links erkennen.

Diese Möglichkeit des offenen Ateliers hat mich übrigens total begeistert. Man kann 2 Stunden abschalten und lernt neue interessante Leute kennen. Im offenen Atelier kann man aber vor allem auch neue Techniken ausprobieren, um einem Bild beispielsweise Plastizität zu geben. Techniken, die man daheim womöglich nie ausprobieren würde, weil man nicht weiß, wie man rangehen soll oder es schlicht eine kleine Sauerei ergeben würde (Morrighans Silberfolie fliegt sicher immernoch irgendwo rum). Dann stehen einem unzählige Farben, Pinsel und Leinwände in jeder Größe zur Verfügung. Obwohl die 50x60cm-Leinwand eher mittelgroß ist, ist es eine Größe, die ich niemals zu Hause bearbeiten könnte, allein schon, weil mir der Platz dafür fehlt. Also wer die Möglichkeit hat, an solch einem offenen Atelier teilzunehmen, sollte sie unbedingt ergreifen. Ich fahr da gerne 130 Kilometer! So viel zeit muss sein ;)

Am 18. September findet in wolnzach übrigens die Vernissage "Bunte Welten" statt, in der Bilder gezeigt werden, die im offenen Atelier entstanden sind.


 
09
Aug
HdRO: Es war einmal ...
Geschrieben von: Pfefferoni   

Vor nicht all zu langer Zeit musste ich feststellen, dass die Aktivität meiner leibgewonnen Sippe fast am Nullpunkt angelangt war. Da just zu diesem Zeitpunkt, meine Raidgemeinschaft sich zur Sippe formiert hat, bin ich den logischen Schritt gegangen und habe die Sippe gewechselt. Dass das ein Schuss in den Ofen war, ist mittlerweile hinreichend bekannt.

Damals hatte ich noch geschrieben, dass meine alte Sippe sich reaktiviert hat. Aus dem Grund bin ich ganz klein mit Hut zu meiner alten Sippe zurück. Das Ruder hatte eine alte Bekannte übernommen, die mit ihrem Mann schon lange in der Sippe ist und wegen Familienzuwachs pausiert hatte. Eben dieser hat nun das Laufen gelernt, was es der Bekannten leider wieder unmöglich macht, öfter zu spielen. Aber das RL geht nunmal vor und da hat auch jeder Verständnis!

Lange Rede, kurzer Sinn: Ich führe jetzt meine neue alte Sippe an. Und weil ich so enorm viel Ahnung von Sippenführung hab, lass ich erstmal alles so laufen wie es eben läuft. Als neue Mitglieder werden maximal alte Bekannte aufgenommen, alte inaktive Spieler haben Bestandsschutz und werden frühestens nach der Umstellung des Accountsystems im Herbst gekickt (wir gehen davon aus, das einige Spieler ohne Life Time Account erst dann wieder aktiv werden, wenn das System umgestellt ist. Bis dahin warten wir also ab.).
In dieser "Ruhephase" werden wir u.a. die Webseite unserer Sippe neu gestalten - also neu aufsetzen, also eigentlich komplett neu machen. Des Weiteren müssen wir sippenintern aktiver werden. Damit meine ich nun nicht unbedingt, den Leutnant von Dol Guldur im Hardmode legen, aber zumindest Gruppen-Instanzen oder epische Quests. Ich denke, nur wenn wir als harter Kern aktiv untereinander sind, können wir auch glaubwürdig neue Mitglieder rekrutieren. Das steht dann übrigens an, wenn Webseite, TeamSpeak und Interna Hand und Fuß haben.

Das ist also der grobe Schlachtplan. Auf in die Schlacht!

Tags:
 
<< Start < Zurück 1 2 3 4 5 6 7 8 9 10 Weiter > Ende >>

Seite 1 von 17