Archiv der Kategorie: Computer

Mittels Nullmodem auf eine Alix mit OpenBSD

Veröffentlicht am von

Ich habe mir ja vor einer Ewigkeit diesen hübschen Embeddded-Computer zugelegt. Gegenüber damals bin ich aber irgendwann von Net- auf OpenBSD umgestiegen. Weil ich aber inzwischen der Auffassung bin, möglichst wenig Ballast anzusammeln und herum zuschleppen, habe ich mich weitestgehend von unnötiger Peripherie-Hardware wie Ein- und Ausgabegeräte und anderem Zeug getrennt. Nun betreibe ich diese Box in einer Umgebung, wo es weder Monitor oder Tastatur gibt. Da sie aber noch über eine hinausgeführte serielle RS-232-Schnittstelle verfügt, sollte man den Kram eigentlich auch nicht benötigen. Wenn der Rechner gerade aus Gründen nicht über ein Netzwerk erreichbar ist, so hat man dennoch die Möglichkeit via USB-Seriell-Adapter und Nullmodemkabel sich auf dem Gerät einzuloggen. Folgende Einstellungen müssen Betriebssystemseitig unter OpenBSD gemacht werden.

In der Datei /etc/ttys die Zeile:

tty00   "/usr/libexec/getty std.9600"   unknown off

nach

tty00   "/usr/libexec/getty std.9600"   vt220   on  secure

abändern.

Die Datei /etc/boot.conf erstellen oder bearbeiten und folgende Zeile hinzufügen:

set tty com0

Damit wird auch der Boot-Prozess über die serielle Leitung übertragen. Leider funktioniert das bei mir noch nicht, weil die Boot-Loader Input-/Output-Fehler wirft, denen ich bisher nicht auf den Grund gekommen bin.

Was ich aber ziemlich advanced finde, dass selbst die Initialisierung der Hardware und auch der Zugriff auf das BIOS-Setup über die Serielle Konsole erfolgen kann. Dafür muss lediglich im „BIOS Advanced Features“-Menü die Option „Console Redirection“ auf Enabled gestellt werden. Die Baudrate sollte natürlich identisch mit der des Betriebssystems und dem Terminal-Emulators sein.

Serial-Boot_BIOS_0

Serial-Boot_BIOS_1

Serial-Boot_BIOS_2

Serial-Boot_BIOS_3

Anders als hier aufgeführt, kann man die Baudrate natürlich auch bis auf 115200 Baud herauf setzen, da auf Dauer die 9600 sehr langsam erscheinen – auch wenn es einen gewissen Nerd-Faktor und fast einen meditativen Charakter besitzt, dem Bildschirm beim zeilenweisen Aufbau zu zusehen.

Ob das Ganze auch mit den moderneren UEFI’s geht, weiß ich jetzt nicht. Cool wäre es!

Quelle im OpenBSD FAQ:
http://www.openbsd.org/faq/faq7.html#SerCon

Erstellen eines S/MIME-Zertifikats unter Mac OS X

Veröffentlicht am von

Nicht immer lässt sich GnuPG als e-Mail-Verschlüsselungslösung auf allen Geräten benutzen, da dafür Plug-Ins nötig sind, die nicht für alle Plattformen verfügbar sind. Im Gegensatz zu GnuPG ist S/MIME in den Mail-Programmen bereits integriert. Es funktioniert aber genauso mit Schlüsselpaaren.

Damit man auf dem Mac S/MIME benutzen kann, braucht man zuerst einmal ein Zertifikat. Es gibt einige Stellen, die einem auch kostenlos ein solches Zertifikat ausstellen, doch reicht es eigentlich schon, selber ein Zertifikat zu erstellen. Der Unterschied dabei ist, dass ein selbsterstelltes Zertifikat per se als “nicht überprüfbar” ausgewiesen wird. Es geht also in erster Linie um das Vertrauen.

S-MIME-Zertifikat_erstellen_0

Um ein Zertifikat auf dem Mac zu erstellen, benutzt man das Programm “Schlüsselbundverwaltung”, welches sich im “Dienstprogramme”-Ordner befindet. Im Menü “Schlüsselbundverwaltung” wählt man unter “Zertifikatassistent” den Eintrag “Zertifikat erstellen”. Im sich nun erscheinenden Fenster müssen Schrittweise Einstellungen vorgenommen werden. Hier die einzelnen Schritte in Bildern:

Schritt 1:

S-MIME-Zertifikat_erstellen_1

Hier ist es wichtig, die Option “Standardwerte überschreiben” zu wählen, sofern man mehr als eine e-Mail Adresse im System eingetragen hat. Ansonsten nimmt der Assistent einfach die Adresse, welche als “Hauptadresse” eingestellt ist.

Schritt 2:

S-MIME-Zertifikat_erstellen_2

In diesem Schritt wird die Dauer der Gültigkeit festgelegt. Voreingestellt ist 1 Jahr.

Schritt 3:

S-MIME-Zertifikat_erstellen_3

Nun folgen allgemeine Angaben zur Person bzw. Firma, für welche das Zertifikat erstellt wurde. Bei e-Mail Adresse muss man nun die e-Mail Adresse wählen, für welche das Zertifikat erstellt werden soll.

Schritt 4:

S-MIME-Zertifikat_erstellen_4

Diese Einstellungen können getrost so belassen werden.

Schritt 5:

S-MIME-Zertifikat_erstellen_5

In diesem Schritt wird ausgewählt, wofür das Zertifikat verwendet werden soll. Am besten einfach genau so einstellen, wie im Bild.

Schritt 6:

S-MIME-Zertifikat_erstellen_6

Für welche Dienste das Zertifikat verwendet wird, wird in diesem Schritt angegeben. Für uns reicht die Option “e-Mail-Schutz”.

Die restlichen Schritte können so belassen werden, wie sie voreingestellt sind. Beim letzten Schritt klickt man auf “Erstellen” und dann hat man sein selbsigniertes Zertifikat erstellt und erscheint in der Liste der Zertifikate in der Schlüsselbundverwaltung.

Da wir unserem Zertifikat ja bestimmt selber vertrauen, sollten wir dies auch angeben. Dazu auf das neu erstellte Zertifikat doppelklicken, um das Informationsfenster dazu zu öffnen. Unter dem Eintrag “Vertrauen” können wir nun diese Einstellung vornehmen:

S-MIME-Zertifikat_erstellen_7

Ein weiterer Vorteil von S/MIME gegenüber von GPGMail ist, dass dieses auch unter iOS funktioniert (seit iOS 5). Somit braucht man nicht auf ein eher umständliches Drittanbieter-Programm umzustellen. Um S/MIME unter iOS verwenden zu können, müssen die Zertifikate zuerst auf die iDevices gebracht werden. Am einfachsten geschieht dies, indem man sich selbst eine e-Mail schickt, an welche die Zertifikate angehängt sind. Die Zertifikate können aus der Schlüsselbundverwaltung zu diesem Zweck exportiert werden.

Nun die E-Mail auf dem iPhone bzw. iPad öffnen und auf das angehängte Zertifikat klicken. So wird man nun schrittweise durch die Installation geführt.

pfSense 2.3 auf einem Alix 2D13 Board

Veröffentlicht am von

Vor circa anderthalb Monaten gab es von der Router und Firewall-Distribution pfSense ein größeres Update von Version 2.2.x auf 2.3. Dieses beinhaltet neben zahlreichen Verbesserungen auch eine von Grund auf völlig überarbeitete Web-Oberfläche. Allerdings reagiert das System mit den Standardeinstellungen gerade unter der neuen Web-Oberfläche auf meiner Alix 2D13 ziemlich träge. Um nicht zu sagen – es ist so ziemlich unbenutzbar, weil es permanent zu einer Zeitüberschreitung von Seiten des Web-Servers gibt. Auch der Zugang mittels SSH ist dann nicht mehr so angenehm schnell möglich. Um dennoch die ältere 386-Plattform nutzen zu können, hilft folgende Konfigurationsänderung in der pfSense-Weboberfläche aus.:
Unter Diagnostics -> NanoBSD muss unter dem Menüpunkt Permanent Read/Write Status das Häkchen gesetzt sein.
Für die Zukunft ist es wahrscheinlich besser das alte Alix-Board mit der 500MHz AMD Geode CPU und den 256 MB RAM gegen ein moderneres APU 2 Board zu ersetzen.

Apache Logfiles anonymisieren oder abschalten

Veröffentlicht am von

Soweit ich das richtig verstanden habe, dürfen nach dem deutschen Recht Webserver keine IP-Adressen abspeichern, solange sie aus technischen oder geschäftlichen Gründen nicht zwingend erforderlich sind. (siehe TMG §15)

Das gilt sowohl für den Webserver als auch für Kommentare in den Content-Managemand-Systemen. Ein Apache ist in der Standardeinstellung aber nicht nach der deutschen Rechtslage voreingestellt. Mit ein paar Zeilen in der Konfiguration lassen sich die Logfiles eines Webservers anonymisieren oder ganz abschalten.

Logfiles anonymisieren

Eine Möglichkeit ist das anonymisieren von Logfiles. Die Einträge werden dabei weiterhin in die Dateien geschrieben – doch mit entfernter IP-Adresse. Unter Ubuntu 14.04 wechselt man in das Konfiguraionsverzeichnis /etc/apache2/conf-available/ und öffnet die Datei other-vhosts-access-log.conf, um die Logeinstellungen für vHosts zu ändern. Eine neue Zeile wird hinzugefügt:

LogFormat "[IP] %l %u %t \"%r\" %>s %b" vhost_combined

Danach muss der Webserver neu gestartet werden:

service apache2 reload

Statt der echten IP eines Clients erscheint nun „[IP]“ in den Logfiles.

Auf ähnliche Weise wird die Einstellung für die Errorlogs geändert. Die Datei /etc/apache/apache2.conf öffnen und folgende Zeile hinzu fügen:

ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client [IP]] %M"

Logfiles abschalten

Wer ganz auf den Accesslog verzichten kann, kann diesen auch ganz abschalten und so Ressourcen sparen. Dazu wird in /etc/apache2/conf-available/other-vhosts-access-log.conf einfach die Zeile „CustomLog …“ mit einem vorangestellten „#“-Zeichen auskommentiert. Dasselbe gilt für den Errorlog: Hier muss in /etc/apache2/apache2.conf die Einstellung „ErrorLog“ auskommentiert werden.

Nach jeder Konfigurationsänderung ist ein Neuladen der Konfiguartionsdateien nötig, damit die Einstellung aktiv werden.

service apache2 reload

Update: 12.10.2019 18:00 Uhr

Ich habe mich ja für das vollständige Abschalten der Logfiles entschieden, wenn ein HTTP-Client auf dieses Blog Anfragen schickt.

Um die Access-Logs zu deaktivieren, reicht es nach wie vor aus, die Zeile „CustomLog …“ in der Datei /etc/apache2/conf-available/other-vhosts-access-log.conf aus zu kommentieren.
Um die Fehler-Logs zu deaktivieren, reicht es hingegen beim meinem aktuell eingesetzten Apache nicht mehr, die Zeile „ErrorLog“ in der Datei /etc/apache2/apache2.conf einfach mit einem „#“-Zeichen aus zu kommentieren. Der Apache stört sich stattdessen daran, dass kein Wert für diese Konfiguartion in der Datei vorhanden ist und verweigert das neue Einlesen der Datei bei ihm als einen bereits laufenden, beziehungsweise er würde sich gar nicht erst als Dienst starten lassen. Alternativ lässt sich die Abschaltung des Loggings von gescheiterten Anfragen in der Datei wie folgt konfigurieren.:

…
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a 
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a 
# container, that host's errors will be logged there and not here.
#
#ErrorLog ${APACHE_LOG_DIR}/error.log
ErrorLog /dev/null

#
# LogLevel: Control the severity of messages logged to the error_log.
# Available values: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the log level for particular modules, e.g.
# "LogLevel info ssl:warn"
#
#LogLevel warn
…

wego-Wetterclient für das Terminal

Veröffentlicht am von

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.