IPCop is back

ipcopisback

Es war nicht mehr auszuhalten mit IPFire. Das Ding frisst sich bei mir innerhalb weniger Tage fest und dann ist man nur noch am Proxy-Cache leeren, URL-Filter neu starten und rebooten, in der Hoffnung, dass danach das Netz wieder performant läuft. Außerdem bekomme ich die Logik der Firewall nicht in meinen Kopf. Egal welches Netzsegment ich für welche Uhrzeit oder welchen Dienst sperre … entweder läuft gar nix mehr im ganzen Haus oder alles flutscht durch.

Jetzt hab ich mir wieder einen IPCop installiert und muss sagen: Die Installation von IPCop 2.x hat sich gegenüber 1.x nicht geändert – man fühlt sich sofort zu Hause. URL Filter und BOT sind mit an Bord und tun auch, was man einstellt. Und das Netz im Haus? Fühlt sich nicht nur schneller an, ist auch messbar flotter. Außerdem sind die Sperrmeldungen von IPCop einfach schön 😉

Passwortänderung, PuTTY und Kollegen

Damit meine Kollegen ihre Passwörter auf dem schulischen Mailserver selbst ändern können will ich diesen keine Möglichkeit direkt über Horde5 zur Verfügung stellen. Im Kontext von Heartbleed wurde mir klar, dass Aufrufe zur Passwortänderung nämlich von Lehrer/innen schlicht ignoriert werden oder Passwörter gewählt werden, die diesen Namen nicht verdienen.

Ich habe nun vor, die Passwortverwaltung einerseits selbst in der Hand zu halten, so weit es eben geht, und andererseits aber auch nicht zu sehr zu gängeln.

Es wird deswegen die Möglichkeit geben, sich über SSH mit einem Passwort-geschützten Schlüssel am Mailserver anzumelden und dort passwd zu nutzen, das wiederum ein paar Prüfroutinen auf die Eingaben loslässt. Restricted Shell sollte genug Sicherheit bieten. So richtig böse ist keiner und wenn doch, dann ist der Mailserver eben weg.

Will also ein Lehrer sein Passwort selbst verwalten, dann erhält er von mir in einer verschlüsselten Mail einen TrueCrypt Container und das zugehörige Passwort. im Container befinden sich PuTTYPortable.exe, puttygen.exe und seine private Schlüsseldatei im SSH Format. Weiter kommt noch eine Anleitung mit dazu – denn: Die Ersteinrichtung von PuTTY überlasse ich ebenfalls dem Benutzer.

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Mit puttygen muss man zuerst den SSH Key über /Conversions /Import key importieren und dann den privaten Schlüssel im PPK Format wieder abspeichern. Beim Import fragt puttygen nach dem Passwort für den Schlüssel.

http://portableapps.com/apps/internet/putty_portable

In PuTTYPortable sind dann die folgenden Einstellungen vorzunehmen:

  • unter /Session sind der Server und der Port einzustellen
  • unter /Connection /Data /Auto-login-username ist der Benutzername einzutragen
  • unter /Connection /SSH /Auth wird über den Schalter /Browse die vorher erstellte PPK Datei mit dem privaten Schlüssel ausgewählt

Ist PuTTY erst einmal zufrieden gestellt, dann speichert man die ganze Geschichte unter /Session ab, so dass man sich dieses Gefrickel in Zukunft sparen kann.

Pam_unix prüft bei entsprechender Konfiguration und in Zusammenarbeit mit pam_cracklib einiges ab, was zu simple Einfälle unmöglich macht. Da muss ich aufpassen, dass ich nicht übertreibe.

Da an keiner Stelle im Prozess der Passwortänderung auch nur Sternchen angezeigt werden, sind die Fehlerquellen sicherlich Legion. Dazu kommt, dass ein solches Verfahren die meisten schlicht abschrecken wird. Schwarze Felder mit blinkenden grünem Strichlein sind die wenigsten gewohnt.

Das ist dann eben so. Ein Kollateralschaden.

Am Rad

War mir total entgangen, dass WordPress im Back- wie auch Frontend Fonts von Google verwendet und diese selbstverständlich von deren Servern lädt. Da stolperte ich erst drüber, als ich diesen Blogpost durch Zufall fand. Keiner meiner vielen RSS Feeds brachte mir dieses Thema auf die Agenda … Mist.

Google hatte demnach auch hier die Möglichkeit genau zu sehen, welche Seite in meinem Blog von welcher IP Adresse aus aufgerufen wird. Es ist zum Kotzen.

Seit gerade eben steckt hier das Plugin Disable Google Fonts von Milan Dinic im System, das ich nun großzügig über alle meine WP Installationen hinweg verteile.

WP mit Google Font

WP mit Google Font

WP ohne Google Font

WP ohne Google Font

Nur auf Lebensart wird dies nicht glücken – da brauche ich andere Lösung, weil ich dort selbst einen Font von Google nutze, diesen aber bisher nicht lokal eingebunden habe. Der von meinem Kubuntu vorgeschlagene Ersatz … der hat einen WAF von 0.

Australis

Der neueste Designkram von Mozilla wäre mir eigentlich egal, wenn ich meine Statusbar noch hätte. Die wurde aber entsorgt, so dass ich keinen Nagios Checker mehr sah und NoScript sowie ABE nach oben rutschten. Außerdem gab es CookieKiller nur noch per Kontextmenü und die Anzeige von Links, über die ich meine Maus hielt, tauchte mal rechts und mal links im Browserfenster auf, was aus einem kurzen Kontrollblick ein Suchspiel machte.

Jetzt habe ich zwei weitere Addons – und Firefox sieht wieder aus wie er soll:

https://addons.mozilla.org/de/firefox/addon/classicthemerestorer/

https://addons.mozilla.org/de/firefox/addon/status-4-evar

Herzblutfolgen

Meine beiden Schuldomains kvfg.net und kvfg.org hatten COMODO Zertifikate, die ich bei PSW aus der Kategorie Lite kaufte und die sich austauschen ließen. Bisher erfolgte die Lieferung derselben zusammen mit allen nötigen Dateien für den Aufbau einer passenden Zertifizierungskette. Dieses mal war dem nicht so.

Ich erhielt von PSW zwar wieder die cert.cabundle Datei – ein Austausch derselben gegen die vorhandene cert.cabundle reichte für Firefox aber nicht aus. Firefox meldete

sec_error_unknown_issuer

Chromium zickte nicht rum, dafür aber auch Rekonq und Konqueror. Nach der Lektüre von gefühlt 100 falschen Anleitungen im Netz und nach etwas herumprobieren, wie ich mir selbst die richtigen Teile einer Zertifizierungskette zusammenkleben könnte, weiß ich nun endlich, wie es geht:

Man besorgt sich hier bei Comodo die nötigen Dateien

  • COMODORSAAddTrustCA.crt
  • COMODORSADomainValidationSecureServerCA.crt
  • ComodoSSL.ca-bundle

und klebt diese mit cat in der folgenden Reihenfolge zusammen:

cat COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt ComodoSSL.ca-bundle > mydomain.bundle

DIese Bundle Datei kommt zur Direktive SSLCertificateChainFile:

SSLEngine On
SSLCertificateKeyFile /etc/apache2/ssl/mydomain/mydomain.key
SSLCertificateFile /etc/apache2/ssl/mydomain/certificate.crt
SSLCertificateChainFile /etc/apache2/ssl/mydomain/mydomain.bundle

Dann den Apachen neu starten, mit Firefox probieren und zur Sicherheit auch noch hiermit überprüfen: http://www.sslshopper.com/ssl-checker.html

Jetzt fehlt noch der Austausch meiner StartSSL Zertifikate, dann die große Passwortänderungsaktion und das Herzbluten wäre überstanden.

Alteschbühl

Wir haben uns die Füße wund gelaufen und jede blöde Zecke eingesammelt, die er Wald und der Waldrand hergaben, aber gefunden haben wir den nach Binder „mit Stangen“ abgedeckten Eingang zur Alteschbühl (in anderen Quellen: Alleschbühlhöhle) nicht.

Der gesamte Hügel ist eine Ansammlung an kleinen und kleinsten Dolinen. Da ist es schwer, die richtige zu finden, in der man mal mit dem Fuß das Laub wegschieben könnte, um besagte Stangen zu finden. Dazu kommen die wie immer nur groben Angaben in der Geotop-Datenbank des Landes, die unserer Erfahrung nach dazu noch nie auf den Meter genau sind, sondern nur eine grobe Orientierung bieten.

Frustrierend.

Aber wir kommen trotzdem wieder. Andere machen Geocaching – wir machen eben Geosearching.

Dobelhaldenschacht

Der Binder macht es einem mal wieder schwer mit der Angabe „250m WSW des Westendes des Parkplatzes Lichtenstein“ befände sich der Dobelhaldenschacht. Einfacher wäre eine Angabe, dass sich dieser 200m östlich des Ausweichparkplatzes Lichtenstein befindet.

https://www.openstreetmap.org/#map=19/48.40385/9.25170

Die umgebende Doline ist riesig, aber flach und an der Westseite auch noch geöffnet. So flach, dass man diese kaum als Sinkhole in OSM eintragen mag.

Der Dobelhaldenschacht selbst ist inzwischen doppelt gesichert. Einmal mit einem Gitter, das das Hineinfallen von Blättern verhindern soll und mit einem zweiten Gitter, das den Einstieg behindert.

So oder so – ohne Seil / Strickleiter kommt man nicht weiter, weil man zuerst rund 4m in die Tiefe muss. An der Oberfläche lässt sich ein vermutlich eingestürzter Seitengang noch in einer kleinen Karstwanne ein paar Meter Richtung Westen weiter verfolgen.

Wir sind die nähere Umgebung noch auf der Suche nach weiteren Karsterscheinungen abgelaufen. Aufgefallen ist uns heute nichts. Aber man könnte (sollte) einerseits in dieser Doline mal ein paar Steine umdrehen und andererseits die Felsenreihe an der Straße nach Lichtenstein richtig untersuchen. Denn: Der Dobelhaldenschacht scheint sich in diese Richtung fortzusetzen.

Ruine Holstein

Auf dem Weg zurück von Biberach mussten wir bei dem schönen Wetter einen kleinen Abstecher zu den Kleinhöhlen unterhalb der Ruine Holstein bei Stetten unter Holstein machen – ein wenig GPS und danach die üblichen Arbeiten bei OSM.

Schön ist es dort. Das nächste mal bringen wir Würstchen mit zum Grillen im Burghof.

2 zu 179

baloo

Ich geb KDE ja immer wieder eine Chance, seine eingebaute Suchfunktion unter Beweis zu stellen (siehe die Tags an diesem Artikel), aber ich lande immer wieder beim gleichen Ergebnis.

Baloo findet auf einem Kubuntu 14.04 nach zwei kompletten Tagen Zeit zur Indexerstellung zwei Dokumente mit „didacta“ als Text …

recoll

… und recoll findet nach ein paar Stunden Indexerstellung 179 Stück.

Ich weiß, was ich nutze und ich weiß auch warum.

Mailman spricht kein Deutsch

mailman_de

Wer auch immer die Pakete für mailman für Ubuntu packt – die deutschen Sprachdateien blieben außen vor. Man kann sich aber behelfen. Erst einmal schaut man nach, welche Mailman-Version sich das eigene Ubuntu gezogen hat:

dpkg -l | grep mailman

Auf einem 12.04 LTS sollte die Antwort sein:

ii mailman 1:2.1.14-3ubuntu0.1

Also holt man sich das entsprechende Sprachpaket hierzu direkt vom Mailman Server:

wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.14-1.tgz

entpackt dieses (hier als root im Verzeichnis /root) und schiebt es an den richtigen Ort:

tar xfz mailman-2.1.14-1.tgz

cd /etc/mailman/

mv /root/mailman-2.1.14-1/templates/de .

Hiernach kann man die Sprache im Backend auswählen.