Ungerhaldenhöhle

IMG_20150406_171631

Janis wurstelt an einer GFS, Lewin an einem Bericht über seine Frankreichfahrt und Britta lernt mit Bela Erdkäs. Das fünfte Rad am Wagen ging also Höhlen suchen auf der Alb. Und fündig wurde ich sofort: Die Ungerhaldenhöhle (oder auch Ungernhaldenhöhle) bei Melchingen ist nicht schwer zu finden und beeindruckt mit einem hübschen, zwei geteilten Einstiegsschlitz.

IMG_20150406_171648

Gleich am Anfang geht es im Schacht geschätzte 4m nach Unten und danach dann noch rund 37m in den Berg.

https://www.openstreetmap.org/#map=19/48.34235/9.17502

Irgendwelche Pappnasen haben in das obere Loch im Eingangsschlitz einen Baumstumpf geworfen und nehmen dem Gang unter dem Schlitz so viel Licht.

IMG_20150406_171346

Der Heimatforscher Johannes Dorn habe hier 1883 (und 1881 im Muetesloch, das ich noch besuchen und auf OSM benennen muss) menschliche Skelette und vorgeschichtliche Scherben gefunden für die sich die Wissenschaften auf Grund mangelnder Attraktivität als Ausstellungsstücke nicht interessiert haben sollen, berichten die Heimatkundlichen Blätter 2/2001 auf S. 1254.

IMG_20150406_171602

Vor diesem Hintergrund war mein heutiger Fund eines Oberschenkelgelenk-Knochens direkt am Höhleneingang ganz spannend und macht auch Lust auf einen Besuch im Inneren. Mal schauen ob die Kinder auf „Zombiehöhle“ oder „Menschenfresser-Höhle“ anspringen 😉

Firefox 37 und Thunderbird 31.6.0 zicken wegen OCSP Fehlern

Heute Morgen waren einige meiner Seiten nicht mehr mit Firefox über HTTPS zu erreichen und auch Thunderbird meinte, dass er das Zertifikat nicht schlucken wolle – allerdings drückte er sich anders aus: Der Mailserver unterstütze die gewählte Authentifizierungsmethode nicht.

Als ich auf dem Mailserver direkt nachsah, meldete Dovecot beim Verbindungsaufbau mit Thunderbird:

dovecot: imap-login: Disconnected (no auth attempts in 2 secs): user=<>, rip=123.123.123.123, lip=12.12.12.12, TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, session=<TNfVw/XCDwBP+hWC>

In beiden Fällen handelte es sich um Zertifikate von StartSSL die von den Vorgängerversionen von Thunderbird und Firefox noch klaglos geschluckt wurden. Die Zertifikate sind gültig und andere Browser (Chrome, Rekonq) wie auch andere MUAs (KMail) haben das Problem auch nicht bzw. provozieren beim Dovecot keine derartigen Fehlermeldungen.

Für’s Erste habe ich nun in beiden Mozilla-Programmen die Überprüfung der Zertifikate über OCSP abgeschaltet, bis ich mehr über diesen Fehler herausgefunden habe … oder bis Mozillaprodukte die Zertifikate wieder fressen.

In Thunderbird geht das unter /Bearbeiten /Einstellungen /Erweitert /Zertifikate /Validierung und in Firefox findet man diese Funktion unter /Bearbeiten /Einstellungen /Erweitert /Zertifikate. In beiden Fällen jeweils den Haken bei der OCSP-Option rausnehmen. Schön ist das nicht.

Hanneshöhle II

CIMG4975

Mal wieder ein Fall von binderschem Beschreibungsrätsel gepaart mit falschen Angaben in der Geotop-Datenbank des Landes. Heute sind wir endlich fündig geworden [1, 2] und können das Projekt Pfullinger Höhle oder Hanneshöhle vorläufig beenden.

Wie immer, wenn wir ungenaue Angaben im Binder und in der Geotop-DB vermuten, arbeiteten wir den gesamten Hang zu zweit im Abstand von 20m durch. In diesem Fall fast vom Ruoffseck aus – mit dem Ziel, bis zum Sattel am Ende des Won keinen Stein unumgedreht zu lassen. So weit mussten wir jedoch gar nicht gehen: Die Hanneshöhle hat mit den von uns schon bei der ersten Tour gefundenen Dolinen und Felsen am Sattel genau so wenig zu tun wie mit den vielen Felsen im Wald. Sie liegt friedlich mitten drin.

https://www.openstreetmap.org/#map=19/48.42554/9.21749

Ein Blick durch das Gitter zeigt die in den Quellen erwähnte Leiter in die rund 4m tiefer liegende erste Halle.

CIMG4980

Ich fürchte, ohne Vereinsbindung kommen wir hier nicht weiter. Schade.

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.

https://www.openstreetmap.org/#map=16/48.2213/9.4442

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.

https://www.openstreetmap.org/#map=18/48.43202/9.21878

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.

apt-get install redmine redmine-sqlite libapache2-mod-passenger

Dann die Konfigurationsdateien anpassen:

# /etc/apache2/mods-available/passenger.conf
PassengerDefaultUser www-data

und

# /etc/apache2/sites-available/default-ssl.conf
<Directory /var/www/pfad/zu/redmine>
    RailsBaseURI /redmine
    PassengerResolveSymlinksInDocumentRoot on
</Directory>

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:

DocumentRoot /var/www/pfad/zu

Redmine versymlinken:

ln -s /usr/share/redmine/public /var/www/pfad/zu/redmine

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

cp /usr/share/redmine/config/configuration.yml.example /etc/redmine/default/configuration.yml

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

# default configuration options for all environments
default:
  email_delivery:
    delivery_method: :sendmail

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

/var/lib/redmine/default/files

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:

# attachments_storage_path: /var/www/pfad/zu/redmine_files
  attachments_storage_path:

Das Apache Modul aktivieren und die Konfiguration neu laden:

sudo a2enmod passenger
sudo service apache2 restart

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:

gem install bundler sqlite3

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

touch /usr/share/redmine/Gemfile.lock
chown www-data.www-data /usr/share/redmine/Gemfile.lock
service apache2 restart

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:

Name: Anbindung_LD-Server
Host: ip.adresse.des.servers
Port: 636 
BaseDN: dc=schule,dc=ort,dc=schule-bw,dc=de

On the fly Benutzererstellung: True

Login = uid
Firstname = givenName
Lastname = sn
Email = mailPrimaryAddress

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:

$ /usr/sbin/tw_cli /c0 show all

Fragt man genauer nach mit

$ /usr/sbin/tw_cli /c0 show diag

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

Error, Unit 0: Invalid command opcode
(EC:0x101, SK=0x05, ASC=0x20, ASCQ=0x00, SEV=01, Type=0x70)
opcode=0x85

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:

BBU comm error 0x241 while writing packet : I2C transaction aborted

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

$ tw_cli /c1/u0 set cache=on

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:

Pad-Server nicht erreichbar.
Es konnte keine Verbindung zum Pad-Server hergestellt werden.
Dies könnte an Ihrem Browser oder Ihrer Internet-Verbindung liegen.

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.

# Listen HTTPS
Ciphers "ALL:!ADH:!EXPORT56:RC4+RSA:HIGH:MEDIUM:!LOW:!SSLv2:+EXP:!eNUL:!EXP-DES-CBC-SHA:!EXP-RC2-CBC-MD5:!EXP-RC4-MD5:!EXP-DES-CBC-SHA:!EXP-RC2-CBC-MD5:!EXP"

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

pear upgrade -a -B -c horde

brachte Fehlermeldungen nach dem folgenden Schema

downloading Horde_ActiveSync-2.25.0.tgz ...
Starting to download Horde_ActiveSync-2.25.0.tgz (345,324 bytes)
......................................................................done: 345,324 bytes
could not extract the package.xml file from "/build/buildd/php5-5.5.9+dfsg/pear-build-download/Horde_ActiveSync-2.25.0.tgz"
Download of "horde/horde_activesync" succeeded, but it is not a valid package archive
Error: cannot download "horde/Horde_ActiveSync"
downloading Horde_Compress-2.1.0.tgz ...
Starting to download Horde_Compress-2.1.0.tgz (2,187,446 bytes)
...done: 2,187,446 bytes
could not extract the package.xml file from "/build/buildd/php5-5.5.9+dfsg/pear-build-download/Horde_Compress-2.1.0.tgz"
Download of "horde/horde_compress" succeeded, but it is not a valid package archive
Error: cannot download "horde/Horde_Compress"
Download failed
upgrade failed

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

/usr/share/php/Archive/Tar.php

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:

679:  if ($this->_compress_type == 'gz' && function_exists('gzopen64'))
680:  $this->_file = @gzopen64($this->_tarname, "wb9");
734:  if ($this->_compress_type == 'gz' && function_exists('gzopen64'))
735:  $this->_file = @gzopen64($v_filename, "rb");
759:  $this->_file = @gzopen64($this->_tarname, "r+b");
1782: $v_temp_tar = @gzopen64($this->_tarname.".tmp", "rb");
889:  @gzseek64($this->_file, gztell64($this->_file)+($p_len*512));

Dann läuft das Upgrade von Horde brav durch:

downloading Horde_ActiveSync-2.25.0.tgz ...
Starting to download Horde_ActiveSync-2.25.0.tgz (345,324 bytes)
......................................................................done: 345,324 bytes
downloading Horde_Compress-2.1.0.tgz ...
Starting to download Horde_Compress-2.1.0.tgz (2,187,446 bytes)
...done: 2,187,446 bytes
upgrade ok: channel://pear.horde.org/Horde_Compress-2.1.0
upgrade ok: channel://pear.horde.org/Horde_ActiveSync-2.25.0

Bis zum nächsten Mal.