Tobeltal

Die Straße K6745 von Zweifalten nach Mörsingen führt durch’s Tobeltal. Man muss fast sagen: leider! Denn dieses hübsche Tal mit vielen Klein- und Kleinsthöhlen wäre ohne die Straße urromantisch.


Größere Karte anzeigen

Binder nennt neben den Tobeltalhöhlen 1 bis 7 (Sandbreitehöhle) auch noch eine Tobeltalklufthöhle, die Steinschlagkluft sowie mehrere Hungerbrunnen. Welche Höhle hier nun welche Nummer bekommen soll … bei den meisten Löchern hab ich da schlicht keine Ahnung.

Auch gelang es mir auf die Schnelle nicht, die längste der Höhlen zu erreichen, weil der Bach zwischen mir und dem Eingang lag.

In der Tobeltalhöhle 2 war ich wohl. Weiter Hinten waren jedoch mehr Spinnen als mir lieb war – also drehte ich, das Ende schon in Sicht, wieder um und kletterte zur Straße zurück.

Im Sommer komm ich wieder. Da kann man sich im Bachbett die Füße kühlen auf dem Weg zu den Höhlen jenseits.

Wackerstein

Auf der Suche nach der Hanneshöhle kommen wir einfach nicht weiter. Also sind wir vor zum Wackerstein, in dem sich nach Binder ebenfalls zwei Höhlen befinden sollen.


Größere Karte anzeigen

Zumindest die im Fuß des Wackerstein war einfach zu finden. Man geht zuerst auf den Wackerstein hinauf und folgt dann den etwas verrotteten Treppenstufen nach Unten, um unter den Wackerstein zu kommen. Sobald man den Felsen mit dem Fenster sieht befindet sich links in der Wand der Eingang. Dieser ist ca. 1,5m breit und 50cm hoch, der Gang selbst ist Linsenförmig, wie man beim Blick zurück gut sehen kann. Da nach der ersten kleinen Biegung der Boden in der Höhle ziemlich dreckig wurde und ich in Alltagskleidung unterwegs war, brach ich ab. 15m dürfte der Schluff aber auf jeden Fall haben und mir schien es so, als könnte ich tropfendes Wasser hören.

Die zweite im Binder erwähnte Höhle fand ich nicht – oder es handelt sich um die oben im Fels, die auf einem der Bilder oben zu erkennen ist.

Redmine

Der Projektmanager und Bugtracker Redmine hatte es Daniel und mir angetan. Also kam dieser auf einen unserer Ubuntu 14.04 Server.

Dann die Konfigurationsdateien anpassen:

und

Wichtig ist hier, dass der Eintrag für den DocumentRoot des bearbeiteten VirtualHost nicht ganz woanders hinzeigt, sonst fliegt PassengerResolveSymlinksInDocumentRoot auf die Nase (weitere Infos hier). Also im zugehörigen VirtualHost Eintrag prüfen, ob er stimmt:

Redmine versymlinken:

Die Konfigurationsdatei für Redmine an Ort und Stelle kopieren:

Dort Sendmail für den Default Mode freischalten (funktioniert selbstverständlich auch mit Postfix):

Bei Bedarf ebenda den Pfad für die Attachments überarbeiten. Der Default Pfad ist

wo dann Unterordner nach Datum des Uploads angelegt werden. Wer das anders haben will kann sich z.B. unter /var/www/pfad/zu/redmin_files anlegen, dem Apachen daran alle Rechte geben und den veränderten Pfad dann in configuration.yml eintragen:

Das Apache Modul aktivieren und die Konfiguration neu laden:

Leider enden hier viele Installationsanleitungen. Ich musste wie folgt weiter bauen:

Zuerst schien es mir so, als ob Ruby ohne bundler und sqlite3 Fähigkeiten nichts mit Redmine anzufangen wusste. Ich sah beim Aufruf nur eine leere Seite. Das hier half weiter:

Jetzt bekam ich wenigstens eine Fehlermeldung über eine fehlende und nicht beschreibbare Gemfile.lock Datei zu sehen. Ein

setze die Datei an die gewünschte Stelle und machte Redmine läuffähig. Mit admin admin kann man sich anmelden und aus Redmine heraus die restliche Konfiguration anpassen.

Was dann noch fehlt war die Anbindung über LDAPs an den hausinternen Server. Redmine bringt ein LDAP Modul schon mit, also muss man nur die richtigen Einträge für einen LD-Server herausfinden. Geklappt hat es hiermit:

Geholfen haben mir bei der Arbeit die folgenden Anleitungen: [1] [2] [3]

3ware opcode=0x85

Schweißperlen können einem RAID Statusmeldungen schon mal schnell auf die Stirn treiben. Fragt man den Status eines 3ware RAIDs so ab, dann sieht alles gut aus:

Fragt man genauer nach mit

dann bekommt man Dinge zu sehen, die erst einmal erschrecken lassen. Ich fand heute unter anderem Folgendes:

Thomas Krenn listet den Fehler nicht auf seiner sonst sehr guten Übersichtsseite zu 3ware Meldungen. Man kommt aber schon dort auf die Idee, dass es sich um ein Kommunikationsproblem handeln könnte, weil der Controller SMART Werte nicht von der Platte, sondern vom Array holen will. Das ist nicht ganz zutreffend.

Sucht man weiter, findet man noch diese Quelle bei Launchpad und das hier im IPFire Forum. Am Ende scheint es darauf hinaus zu laufen, dass SMART versucht von den Platten Temperaturwerte zu erhalten, damit aber nicht durchkommt. Man darf den Fehler wohl tatsächlich ignorieren.

Anders sieht es hiermit aus:

Hierzu klärt der folgende Beitrag bei Serverfault auf, dass 3ware in den default Einstellungen den Schreibcache der Platten im RAID ausschaltet. Das erklärt für mich auch gleich, warum unser RAID so schnarch langsam ist – aber ich trau mich an

etc. ohne ein aktuelles Backup und Ferien im Hintergrund, um Katastrophen reparieren zu können, schlicht nicht ran. Eine BBU würde unabhängig von den Geschwindigkeitsproblemen für uns wirklich Sinn machen.

Etherpad Canvas

Verbinde ich mich mit meinem Firefox auf das schulische Etherpad-Lite erhalte ich zuerst eine schnell vorüberziehende Fehlermeldung, dann erscheint der Inhalt des Pads und will ich dann einen Eintrag vornehmen, meldet mir dieses:

Mit Chromium oder Rekonq funktioniert es jedoch.

Bei mir lag das an einem Firefox Addon zum Blockieren von Canvas Skripts:

https://addons.mozilla.org/de/firefox/addon/canvasblocker/?src=api

Trage ich in diesem Addon die schulische Etherpad-Installation in die Whitelist ein, dann läuft das Ganze auch wieder in Firefox.

LD-Server und HTTPS

Webseiten und Dienste auf einem LD-Server laufen intern in LXC Containern oder auf einem Apache, sind jedoch nach Außen über Pound angebunden – und da ist die mitgelieferte Version ein Stück Softwaregeschichte. “Aktuell” auf LD-Servern ist Version 2.5-1, der in der Default-Konfiguration eine ganze Reihe von Sicherheitsproblemen mit sich bringt. Nicht umsonst erhält man bei SSLLabs für eine nicht-angepasste LD-Server-Installation ein schlichtes F-Rating.

Man muss sich selbst helfen. Support oder Hilfe über die Foren darf man bei einem “Hauptsacheestutsystem” nicht erwarten.

Mit dem folgenden Eintrag in die /etc/pound/pound.cfg stellt man sich zumindest bezogen auf das SSLLabs-Rating schon einmal viel besser auf und erhält ein C.

Der Weisheit letzter Schluss ist das nicht: Die Konfiguration wird nach Systemupdates immer mal wieder überschrieben, so dass man hier gelegentlich vorbei schauen sollte. Außerdem hinterlässt auch die Zeile oben noch das eine oder andere Leck.

Aber es ist besser als vorher.

PS: Ein aktuelles Ubuntu Trusty hätte einen Pound 2.6-3 an Bord. Siehe http://packages.ubuntu.com/trusty/pound Der 2.5-1er Pound auf dem LD-Server scheint aus Oneiric zu stammen. Das war im Jahr 2011.

Wiedergänger

Direkt nach dem Umstieg von Ubuntu 12.04 auf 14.04 wollte sich die Horde-Installation meiner Schule nicht auf den neuesten Stand bringen lassen. Das übliche und sonst erfolgreiche

brachte Fehlermeldungen nach dem folgenden Schema

Damals half mir der folgende Bugreport bei launchpad weiter, der mich im Beitrag #9 auf die richtige Spur brachte. Der Fehler sitzt in der Datei

Hier muss gzopen durch gzopen64 ersetzt werden und gztell durch gztell64 und gzseek durch gzseek64.

Irgendwann im Laufe der letzten Woche muss ein Update gekommen sein, das die Tar.php ersetzte. Aktuell befinden sich die zu ändernden Zeilen samt angepasstem Inhalt in der Tar.php hier:

Dann läuft das Upgrade von Horde brav durch:

Bis zum nächsten Mal.

Alteschbühl II

Der zweite Versuch die Alteschbühlhöhle zu finden. Ich dachte, dass der Schnee an der Stelle geschmolzen sein könnte, an der nur Stangen den Eingang abdecken. Gefunden habe ich nichts – weder in den Dolinenfeldern im Wald noch um das Wäldchen herum. Der Schnee lag wohl zu dick – oder über den Stangen liegt schon so viel Humus, dass dieser isolierend wirkt und so das Schmelzen verhindert.

OSM mit Routenplaner

osmroute

Openstreetmap enthält seit kurzem einen Routenplaner, der zumindest bei meinen ersten Tests, keinen totalen Blödsinn plant: OSM würde mich auf meine Standardstrecke nach Biberach ebenso schicken wie auf meine liebste Strecke nach Esslingen-Zell. Auch im näheren Umfeld scheint auf den ersten Blick alles zu passen.

km

Etwas wild scheint mir die Planung innerhalb von Stuttgart auf dem Weg zum KM zu sein: Einfacher wäre es hier, in die Kronenstraße einzubiegen und dann über die Lautenschlägerstraße zur Thouretstraße zu fahren. Ich muss mir die Daten einmal vor Ort ansehen – evtl. fehlen da ein paar Knoten auf der Karte.

offroad

Etwas verwunderlich für mich: Will man zu Fuß z.B. vom Öschinger Freibad zur Öschinger Klufthöhle, dann endet die Wegbeschreibung zusammen mit dem Weg. Man kommt also in die Nähe, aber nicht ans Ziel :-) Ein Phänomen, das mir gerade im Fall dieses Lochs wohl vertraut ist.

Im Moment ist die Routenplanung auf Start und Ziel beschränkt – Zwischenstops werden noch nicht unterstützt.

Mehr Infos bei OSM im Blog schon am 16/02.

Locale Probleme mit Dudle auf 14.04

Sollten sich bei einer Dudle Installation auf 14.04 die Apache error.logs mit Meldungen in der folgenden Art füllen

und Dudle einen bei der Eingabe von Worten mit Umlauten und / oder Ligaturen wieder auf seine Startseite werfen, dann hilft das Folgende: Zuerst ausschließen, dass man auf dem Server ein generelles Problem mit seinem locales hat. Es hilft ein

Ein kontrollierender Blick in die folgenden Systemdateien sollte auch nicht schaden. Hier werden die Defaults gesetzt:

und

Ist hier alles in Ordnung, dann kann der  folgende Eintrag in die dudle.rb helfen:

Nach einigem Hin und Her haben mir vor allem diese Einträge bei stackoverflow geholfen auf die richtige Spur zu kommen.

Wer unter CentOS und damit ruby 1.8 arbeitet hat noch Glück: Der Fehler geht an einem vorbei, scheint demnach ein Ubuntu Server und ruby 1.9.x Problemchen zu sein.