seeseekey.net - Invictus Deus Ex Machina

Nach einem Update aller Ports unter MacPorts funktioniert EncFS nicht mehr. Auf der Konsole wird dies auch ausführlich dokumentiert:

dyld: lazy symbol binding failed: Symbol not found: __ZN5boost7archive6detail17shared_ptr_helperC2Ev
  Referenced from: /opt/local/lib/libencfs.6.dylib
  Expected in: /opt/local/lib/libboost_serialization-mt.dylib

dyld: Symbol not found: __ZN5boost7archive6detail17shared_ptr_helperC2Ev
  Referenced from: /opt/local/lib/libencfs.6.dylib
  Expected in: /opt/local/lib/libboost_serialization-mt.dylib

Die Lösung für das Problem ist dabei simpel. Der Port EncFS muss noch einmal neu gebaut werden. Dafür gibt man auf der Konsole:

sudo port -ns upgrade --force encfs

ein. Anschließend kann EncFS wieder wie gewohnt genutzt werden.

Gestern hatte wolle ich eine Projektvorlage in Scrivener importieren. Dazu öffnete ich die scrivtemplate–Datei mittels Scrivener. Anschließend teilte Mac OS X mir mit das die Scrivener-App keine Dateien vom Typ scrivtemplate verarbeiten kann. Das verwundert im ersten Moment natürlich, da die Dateien speziell für Scrivener erstellt wurden.

Der „Neues Projekt“-Dialog unter Scrivener

Statt der intuitiven Variante muss man leider anders vorgehen. Im ersten Schritt wird Scrivener gestartet. Anschließend wird der Neues Projekt–Dialog aufgerufen. In dem Dialog gibt es links unten einen Button mit dem Titel Optionen. In dem sich öffnenden Submenü gibt es dann den Punkt Vorlagen importieren. Mit dieser Funktion kann die scrivtemplate–Datei importiert werden und danach im Neues Projekt–Dialog genutzt werden.

Als ich meinen Nginx-Server neustarten wollte, wurde dies vom System mit einem Fehler quittiert. In der entsprechenden Logdatei (/var/log/nginx/error.log) fand sich folgende Meldung:

could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

Die Größe die im Parameter server_names_hash_bucket_size definiert ist, beträgt im Standardfall 32 oder 64. Um den Fehler zu beseitigen muss die Konfigurationsdatei von Nginx geöffnet werden:

nano /etc/nginx/nginx.conf

Dort sollte man den Wert auf 64 oder 128 stellen und Nginx anschließend neustarten. Damit ist der Fehler behoben. Benötigt wird diese Option für die Größe der Hashtabellen in welchen die Servernamen gespeichert werden.

Weitere Informationen gibt es unter:
http://nginx.org/en/docs/http/server_names.html
http://nginx.org/en/docs/http/ngx_http_core_module.html#server_names_hash_bucket_size

Bei Firefox 31 hat sich an der Oberfläche nicht viel geändert. Stattdessen wurden eine Änderungen am Kern vorgenommen. Eine diese Änderungen betrifft den Konfigurationschlüssel:

browser.tabs.closeButtons

Dieser Schlüssel wird in der der neuen Version nicht mehr ausgewertet. Dies führt dazu das jeder Tab nun standardmäßig seinen eigenen Button zum Schließen des Tabs besitzt. Früher könnte der Nutzer über diese Option den Button zum Schließen von Tabs auch nach rechts oben legen. Dies ist nun ohne weitere Hilfmittel nicht mehr möglich.

Hier kommt das Add-On Classic Theme Restorer zum Einsatz. Mit diesem ist es möglich, wieder einen Button zum Schließen aller Tabs an das Ende der Tableiste zu legen. Ein anderes Problem in der neuen Version behebt das Add-On leider nicht. So merkt sich der neue Firefox nicht mehr seine Position, wenn er geschlossen wird. Dies ist besonders auf Multi-Monitor-Systemen ärgerlich, da der Firefox beim Öffnen auf dem falschen Bildschirm aufgeht.

Bei Enigmail handelt es sich um ein Add-On für den freien Mailclient Mozilla Thunderbird. Mit Hilfe dieses Add-Ons ist es möglich verschlüsselte Mails über GPG zu versenden. Unter Umständen kann es bei Enigmail passieren, das man mit folgender Fehlermeldung begrüßt wird.

Enigmail bekommt Probleme

Das Problem liegt daran das Enigmail die GPG-Installation (im Falle von Mac OS X, die GPG Tools) nicht finden kann. Dies scheint ein bekanntes Problem mit Enigmail zu sein. Abhilfe schafft hier unter Mac OS X ein sehr simpler Vorgang — der Neustart des Systems. Danach sollte Enigmail die GPG Tools wieder ohne Probleme erkennen.

Wenn man unter Mac OS X ein sh-Skript ausführen möchte und dabei die Meldung:

/bin/sh^M: bad interpreter: No such file or directory

bekommt, kann das Skript nicht ausgeführt werden. Das Problem liegt daran das versucht wird den Interpreter „bin/sh^M“ anstatt „bin/sh“ zu starten. Bei dem ^M handelt es sich um das dreizehnte ASCII-Zeichen, das Carriage Return (im deutschen auch Wagenrücklauf genannt). Um das Problem zu beheben muss das entsprechende Skript einfach um das Carriage Return Zeichen bereinigt werden. Dies kann im Terminal einfach mittels:

perl -i -pe 'y|\r||d' script.sh

bewerkstelligt werden. Anschließend sollte das Skript ohne weitere Probleme durchlaufen.

Alle die ab letzten Donnerstag, dem 12. Juni 2014 das „Glasfaser Hypernetz“ der Stadtwerke in Neubrandenburg nutzen wollten, schauten wahrscheinlich erst einmal in die Röhre. Bestimmte Netzbereiche, wie die von Google oder Hetzner, ließen sich nicht mehr erreichen. Das führte zu interessanten Effekten, so konnte man z.B. Bing nutzen, Google aber nicht. Die Störung erstreckte sich dabei von Donnerstag über Freitag, bis Samstag. Im Moment scheint das Netz wieder zu funktionieren, allerdings mit deutlich reduzierter Geschwindigkeit — wer seine zugesicherte Bandbreite ausschöpfen möchte hat Pech. Wer in diesen Tagen auf das Internet angewiesen war, der musste sich nach einer Alternative umschauen. An ein ordentliches Arbeiten war bei diesem Störungbild nicht zu denken. Netze waren über den Zeitraum der Störung mal erreichbar und kurz darauf wieder verschwunden.

Den Kunden informieren? Nicht bei der neu.sw (Bild: Malte Penndorf unter CC-BY-SA)

Das Management der Stadtwerke ließ auch zu wünschen übrig. Das einzige was man bestätigen könnte war, das es eine Störung gab. Wie lange sie andauert und wodurch sie verursacht wurde? Die Antwort der Stadtwerke lautete zusammengefasst: „Wir wissen nicht wie lange die Störung dauert, noch warum sie da ist?“. Fairerweise muss man sagen, das der Ausfall als solches nicht in den Bereich der Stadtwerke, sondern in das „vorgelagerte Netz“ fiel. So lag der Ausfall bei der e.discom, welche auf ihrer Webseite mit folgendem Text werben:

Die Verfügbarkeit des e.discom-Netzes wird durch den Einsatz modernster Übertragungstechnik, eine hohe Redundanz und ein leistungsfähiges Netzmanagement garantiert. Einzelverbindungen bieten wir standardmäßig mit einer Verfügbarkeit von 99,5% im Jahresdurchschnitt an. Sollten Sie eine höhere Ausfallsicherheit benötigen, reden Sie mit uns. Gerne entwickeln wir mit Ihnen zusammen ein passendes Servicekonzept und unterbreiten Ihnen ein individuelles Angebot.

Bei einer zugesicherten Verfügbarkeit von 99,5% (was knapp zwei Tage wären), ist ein Ausfall welcher sich über mehr als besagte zwei Tage erstreckt natürlich bedenklich. Auch bei der e.discom konnte man den Fehler nicht genau eingrenzen, hier wurde sich mit der Holzhammermethode beholfen — einfach neu aufsetzen.

Ganz gleich wer am Ende auch verantwortlich ist, die Informationspolitik der Stadtwerke ist nicht hinnehmbar. Auf den Webseiten finden sich keine Statusmeldungen zur Störung. Stattdessen wird der Kunde im Dunkeln gelassen, er hat ja schon bezahlt. Auch scheinen sich die Stadtwerke keine redundante Leitungen für einen solchen Fall vorzuhalten. Alles in allem hinterlässt das alles einen sehr faden Beigeschmack.

Da sitzt man vor seinem Ubuntu-Upgrade und eine unbedachte Handbewegung später hat man das Upgrade abgebrochen. In einem solchen Fall sollte man das Upgrade natürlich fortsetzen, wer möchte schon gerne ein halbfertiges System. Wurde die SSH Verbindung unterbrochen, muss sich im ersten Schritt mit dem Server verbunden werden. Anschließend gibt man im Terminal folgendes ein:

dpkg --configure -a
apt-get dist-upgrade
apt-get autoremove
apt-get autoclean
reboot

Danach sollte der Server auf dem aktuellsten Stand sein und das Upgrade durchgeführt sein. Sollte man das Upgrade vor dem Umstellen der Paketlisten abgebrochen haben, dürfte ein einfaches „do-release-upgrade“ genügenum den Upgrade-Vorgang erneut zu starten.

Wenn man Mac OS X als Host für einen VirtualBox-Gast nutzt, kann dies zu Problemen mit dem Vollbildmodus führen. Möchte man den VirtualBox Gast auf dem zweiten Monitor betreiben, so ist dies ohne Probleme möglich. Aktiviert man allerdings den Vollbildmodus von VirtualBox auf dem sekundären Monitor, wird das Vollbild stattdessen auf dem Hauptschirm aktiviert.

In der Mini-Toolbar kann der entsprechende Monitor eingestellt werden

Als Lösung bietet sich hier die Mini-Toolbar an welche im Vollbild-Modus angezeigt wird. Über das Menü kann der Bildschirm, welcher im Vollbild zum Zuge kommen soll, ausgewählt werden. VirtualBox merkt sich diese Einstellung auch für die Zukunft, so das sie nur einmal nötig ist. Ist die Mini-Toolbar im Vollbild-Modus nicht zu sehen, so muss sie in den Einstellungen der entsprechenden virtuellen Maschine aktiviert werden.

Wenn man beim Zugriff mittels SSH unter Mac OS X folgende Meldung bekommt:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/seeseekey/.ssh/id_rsa' are too open.

weißt das auf ein Problem mit den Zugriffsrechten hin. In diesem Fall sind die Rechte für den privaten Schlüssel zu großzügig vergeben. Dies kann unter anderem dann passieren wenn man ein Backup einspielt. Um dieses Problem zu beheben, gibt man im Terminal folgendes ein:

sudo chmod 600 ~/.ssh/id_rsa
sudo chmod 600 ~/.ssh/id_rsa.pub

Damit sind die Zugriffsrechte für diese Dateien restriktiv gesetzt, so das SSH an dieser Stelle wieder problemlos funktioniert.