wego-Wetterclient für das Terminal

wego ist ein ASCII-Wetterclient für das Terminal, welcher eine go-Bibliothek um einen python-Wrapper schnürt, um via curl Wetterinformationen auf das Unix-Terminal zu holen. Eine schöne nerdige Art, wie man die aktuelle Wettervorhersage auch ohne HTTP-Overhead und Webbrowser hübsch auf den Computer dargestellt bekommt. Ich habe mir diesen mal auf meinem Mac installiert.

Features:

wego-forecast

  • zeigt forecast-Wetterdaten für den Zeitraum von 1 bis 7 Tagen
  • hübsche ASCII-Art Icons
  • angezeigte Informationen (Metrische, imperiale und SI-Einheiten)
    • Temperatur
    • Windrichtung und Geschwindigkeit
    • Vorhersage
    • Niederschlagsmenge und Wahrscheinlichkeit
  • SSL
  • Unterstützung mehrerer Sprachen
  • automatisches Konfigurationsmanagement mit ingo

Abhängigkeiten:

  • eine laufende Go-Umgebung ab Version 1.5
  • UTF-8 Terminal mit 256 Farben
  • eine vernünftige proportionale Schrift
  • einen API-Key für das BackEnd

Installation

Mit MacPorts oder jedem anderen beliebigen Paket-Manager Go installieren:

sudo port install go

Einen separaten Ordner für die Source-Files und Binaries von Go im Heimatverzeichnis anlegen:

mkdir Applications/Go

Umgebungsvariable setzen:

export GOPATH=/Users/franky/Applications/Go

Zum Installieren oder Updaten des wego-Binaries in der gesetzten $GOPATH-Variable ausführen:

go get -u github.com/schachmat/wego

Setup

  1. Einmal wego ausführen. Dies führt zu einem Programmabbruch und einer Fehlermeldung. So wird aber im Heimatverzeichnis die Datei .wegorc erzeugt.
  2. Mit forecast.io einen Account erzeugen
    1. Unter https://developer.forecast.io/register einen Account erzeugen
    2. Folgende Konfigurationsvariablen in der Datei .wegorc anpassen:
      backend=forecast.io
      location=40.748,-73.985
      forecast_api_key=YOUR_FORECAST.IO_API_KEY_HERE
  3. Danach weitere persönliche Einstellungen, wie Verwendete Einheit, Sprache usw. anpassen.
  4. wego erneut ausführen. Und schon wird das Wetter von forecast für die nächsten Tage vorhergesagt.

Mit dem Befehl Applications/Go/bin/wego wird dann die Wetterabfrage gestartet. Alternativ kann man sich aber noch einen passenden Alias in der .profile im Heimverzeichnis anlegen.

SIGINFO

Durch eine der letzten FreakShow-Podcastfolgen bin ich auf ein tolles Feature hingewiesen worden. Wenn sich im Terminal ein laufender Prozess befindet, so kann man durch Drücken der Tastaturkombination <Ctrl> + <T> eine Abfrage an diesen sich seinen aktuellen Status anzeigen lassen.
Ursprünglich unter DEC’s VMS implementiert, wurde diese Funktion später in den Terminaltreiber von 4.3BSD übernommen.
Wie in dem folgendem Screenshot zu sehen, besitzt das Unix-Programm dd für SIGINFO sogar einen eigenen Handler.

dd mit SIGINFO

dd mit SIGINFO

Leider gibt es die Funktion nur auf allen BSD-Systemen, bzw. deren Derivaten wie OpenBSD und Mac OS X, aber nicht unter Linux.

Meine Spieleliste

Was macht man so, wenn man Langeweile hat.? Man kommt auf die komischsten Ideen. Dabei ist mir mal in den Sinn gekommen, zu erfassen mit welchen Computerspielen – vornehmlich auf PC und Mac – ich in meinem bisherigen Leben so meine Zeit verdaddelt habe. Wobei ich sagen muss, dass ich längst nicht alle wirklich durchgespielt habe. Ich hoffe dennoch, dass ich in Zukunft weiterhin Zeit und Muse haben werde, damit diese länger wird. Zum gegenwärtigen Zeitpunkt freue ich schon sehr auf die Veröffentlichung von Thimbleweed Park von Ron Gilbert, welches ich 2014 auf Kickstarter mit gefundet habe.

Link zur Liste im Wiki

Suchmaschinen in Chrome-Browser verwalten

Aus bildungstechnischen Gründen bin ich vorläufig für die nächst Zeit genötigt einen Windows-PC zu benutzen. Aber mir war klar, dass ich den Internet Explorer als Standart-Browser nicht benutzen werde. Argumente dazu habe ich zwar im Moment keine, es wird sicherlich dennoch welche geben, die meine Entscheidung stützen können. Ich habe mich dann doch erstmal für Google Chrom entschieden. Mein Beweggrund zu dieser Entscheidung war, dass Chrome bereits ein eigenes PlugIn für Adobe-Flash integriert hat und nicht der Flash-Player von Adobe separat systemweit installiert werden muss. Wenn man dennoch Google nicht als Suchmaschine verwenden möchte, so kann man in den Einstellungen eine andere wählen oder – wenn nicht angeboten – eine weitere hinzufügen. Die in der Adresszeile eingegeben Begriffe werden so nicht mehr von Google verarbeitet, sondern an die eigene präferierte weitergeleitet. Ich selber habe mich für DuckDuckGo entschieden. Wie weit das in Bezug auf Datenschutz gut ist, weis ich jetzt nicht, aber es ist zumindest ein Anfang. Anbei also die Werte, die in den Browsereinstellungen eingetragen werden müssen.

Zu erreichen über „Chrome anpassen und einstellen“ -> Button „Suchmaschinen verwalten“

Einträge in Chrome für DuckDuckGo als Standart-Suchmaschine

Einträge in Chrome für DuckDuckGo als Standart-Suchmaschine

Erstellen eines eigenen SSL-Server-Zertifikates

Nachdem ich mir vor sechs Wochen wieder ein vServerchen geleistet habe um meinen Senf in diesem Blog ablassen zu können, bin ich für mich mal die Frage durchgegangen wie ich das mit der Transportverschlüsselung löse. Denn früher hatte ich das nämlich bei dieser Domain noch nicht getan. Für mich war ganz klar, dass ich über meinem ISP keine zusätzliche 50,- Euro für ein von einer offiziellen Zertifizierungsstelle signiertes SSL/TLS-Zertifikat jährlich ausgeben werde. Die Lösung des Ganzen befindet sich sowieso in Form eigener Bordmittel in jedem Linux oder lässt sich im Zweifel auch auf anderen Systemen nachinstallieren. Im nachfolgenden werde ich meine eigene CA erstellen, um mir mein eigenes SSL-Zertifikat erzeugen zu können.

1. Erstellen der CA

Ist OpenSSL – beziehungsweise als Alternative neuerdings gerne auch LibreSSL – auf dem Rechner installiert, ist es mal der Ordnung halber praktisch sich einen Ordner ca anzulegen, wo die Dateien abgelegt werden sollen.

root@linux# mkdir /root/ca
root@linux# cd /root/ca

Die Gültigkeit setze ich mit 10 Jahren bewusst erst einmal sehr hoch an. Läuft die CA aus, so werden nämlich auch alle damit signierten Serverzertifikate ungültig. Die CA enthält einen geheimen Schlüssel, welcher automatisch erzeugt und in der Datei cakey.pem abgelegt wird. Das CA-Zertifikat wird nach cacert.pem geschrieben. Der folgende Befehl erzeugt einen Schlüssel für das Zertifikat mit einer Länge von 2048 Bit:

root@linux# openssl req -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 3650
Generating a 2048 bit RSA private key
..............................................................
..............................................................
.........................................+++
......................................+++
writing new private key to 'cakey.pem'

Wer den geheimen Schlüssel der CA kennt, kann damit beliebige Serverzertifikate signieren. Deshalb wird diese Schlüsseldatei nicht im Klartext auf der Festplatte abgelegt, sondern mit einer Passphrase verschlüsselt. Diese Passphrase benötigt man immer dann, wenn mit dieser CA neue Zertifikate ausgestellt werden sollen.
Danach wird man gebeten, Daten einzugeben, welche die CA identifizieren. Diese werden dem Client angezeigt, wenn er aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen. Der Code für Deutschland ist DE. Wenn ein Feld leer bleiben soll, so reicht es, einen Punkt ein zu geben. Ansonsten wird der in eckigen Klammern stehende Defaultwert eingetragen.
Das Feld Common Name (CN) ist hier der offizielle Name der Zertifizierungsstelle. Für die eigene CA reicht es, den eigenen Namen einzutragen.
Am Ende sind dann die Dateien cacert.pem und cakey.pem entstanden.
Vorsichtshalber sollten man die Rechte so setzen, dass die Schlüsseldatei nur für root lesbar ist.:

root@linux# chmod 600 cakey.pem

Mit dem Befehl

root@linux# openssl rsa -in cakey.pem -noout -text

kann man nun einmal prüfen, ob sich der Schlüssel mit der Passphrase öffnen lässt.

2. Schlüssel für das Serverzertifikat erzeugen

Nachdem nun die eigene CA vorhanden ist, kann diese nun endlich eigene Zertifikate herausgeben. Dazu wird zunächst ein 2048 Bit langer RSA-Schlüssel erzeugt, welcher mit AES 256 verschlüsselt auf der Platte abgelegt wird. Die Passphrase muss diesmal nicht sonderlich geheim sein, da sie ohnehin im Anschluss wieder entfernt wird. OpenSSL lässt allerdings keine leere Phrase zu.

root@linux# openssl genrsa -out serverkey.pem -aes256 2048 -days 3650

Jetzt ist es ganz praktisch die Passphrase wieder zu entfernen, da der Server auch ohne Zutun des Administrators in der Lage sein soll, den Schlüssel zu lesen. Sonst müsste bei jedem Booten der Machine ein Passwort eingegeben werden.

root@linux# openssl rsa -in serverkey.pem -out serverkey.pem

3. Certificate Signing Request erzeugen

Der nächste Schritt zum eigenen Zertifikat ist ein CSR. Dies muss dann nur noch von der CA signiert werden. Hier sind wieder Angaben analog zum Erstellen der CA nötig, was oft Verwirrung stiftet. Die allgemeinen Daten kann man gegebenfalls gleich wie oben eingeben.

root@linux#  openssl req -new -key serverkey.pem -out req.pem -nodes

ACHTUNG, jetzt kommt das Wichtige: Beim Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name stehen, unter dem der Client den Server anspricht! Wird das Zertifikat für eine HTTPS-Verbindung zu www.domain.tld verwendet, so muss der Common Name eben genau www.domain.tld heißen. Andernfalls wird der Browser das Zertifikat nicht akzeptieren, da er davon ausgehen muss, auf dem falschen Server gelandet zu sein.

Common Name (eg, YOUR name) []: www.domain.tld
Email Address []: name@domain.tld

Weitere Optionen kann man einfach leer lassen.

A challenge password []:
An optional company name []:

4. OpenSSL-Konfiguration anpassen

Leider kann man bei OpenSSL nicht alle Daten als Kommandozeilenargumente übergeben. Einige Einstellungen müssen lästigerweise in der Datei /etc/ssl/openssl.cnf geändert werden, bevor man signieren kann. Dazu die Datei öffnen und folgende Zeilen in der Sektion [ CA_default ] anpassen.

dir             = .              # Where everything is kept
new_certs_dir   = $dir           # default place for new certs
private_key     = $dir/cakey.pem # The private key
RANDFILE        = $dir/.rand     # private random number file
default_days    = 3650           # how long to certify for

Das Feld default_days ist auf 365 Tage voreingestellt und gibt die Gültigkeit des Zertifikates an. Dieses setze ich wie im Beispiel auf 10 Jahre herauf.
Wenn bei dem Serverzertifikat kein Bundesstaat angegeben ist, wird folgende Änderung unter [ policy_match ] benötigt.

stateOrProvinceName     = optional

Nun muss man noch einige Dateien anlegen:

root@linux# echo 01 > serial
root@linux# touch index.txt

5. Serverzertifikat signieren

Als krönenden Abschluss signiert die eigene CA nun das Zertifikat

root@linux# openssl ca -in req.pem -notext -out servercert.pem

6. Zertifikate installieren

Wohin die erzeugten Zertifikate installiert werden sollen, hängt vom jeweiligen Serverdienst ab. Was ihnen aber allen gemeinsam ist, es werden nur die Dateien cacert.pem, servercert.pem und serverkey.pem benötigt. Die Datei cakey.pem wird nicht benötigt und sollte nicht auf dem Server liegen sondern am besten sicher auf einem anderen Rechner verwahrt werden.
Da es sich bei den Dateien im wesentlichen nur um Textdateien handelt, ist es prinzipiell egal wie sie heißen. Der Übersicht halber und zur besseren Ordnung kann man sie aber auch im Nachhinein in eine umgänglichere Form unbenennen.

cacert.pem -> ca.crt
servercert.pem -> server.crt
serverkey.pem -> server.key

Jetzt sind das aber alles keine neuen Erkenntnisse. Im letzen Jahr erst wurde mit Let’s Encrypt eine alternative Zertifizierungsstelle ins Leben gerufen, um für alle Server-Betreiber kostenlose Zertifikate anbieten und ausstellen zu können. Diese wird unter anderem von der Mozilla und der Electronic Frontier Foundation gesponsert. Man wird sehen wie sich das entwickeln wird.