seeseekey.net - Invictus Deus Ex Machina

Möchte man Testen ob man vom Shellshock-Fehler betroffen ist, gibt man auf der Konsole folgendes ein:

env x="() { :;} ; echo Anfällig für Shellshock" /bin/sh -c "echo Shellshock-Test"

Wenn man betroffen ist gibt diese Kommandozeile:

Anfällig für Shellshock
Shellshock-Test

aus. Ist man nicht betroffen erhält man folgende Ausgabe:

Shellshock-Test

Versuche Shellshock von Außen zu nutzen kann man feststellen indem man seine Logdateien nach diesem Beispiel:

cat logfile.log | grep };

abgrast. Bei einem Webserver Log könnte das ganze dann z.B. so aussehen:

192.168.1.15 - - [27/Sep/2014:19:32:19 +0200] "GET / HTTP/1.1" 200 18804 "-" "() { foo;};echo;/bin/cat /etc/passwd"

Alternativ kann man ein Skript nutzen, welches von einem Golem Autor erstellt wurde. Der Quelltext für das Skript ist dabei auf GitHub zu finden.

Unter neu-sw.de/Haltestellenkarte betreiben die Neubrandenburger Stadtwerke eine Haltestellenkarte. Diese Karte basiert dabei auf OpenStreetMap-Inhalten und es ist schön zu sehen das die von der Community erstellte Karte angenommen wird. Allerdings gibt es ein Problem — die Stadtwerke geben keinen Hinweis auf die Lizenz an.

Die Karte ohne Lizenzhinweis

Auf der OpenstreetMap Seite gibt es zu diesem Punkt eine klare Ansage:

OpenStreetMap sind „Open Data“, die gemäß der Open Data Commons Open Database Lizenz (ODbL) verfügbar sind.

Es steht dir frei unsere Daten zu kopieren, weiterzugeben, zu übermitteln sowie anzupassen, sofern du OpenStreetMap und die Mitwirkenden als Quelle angibst. Für den Fall, dass du auf Basis unserer Daten Anpassungen vornimmst, oder sie als Grundlage für weitere Bearbeitungen verwendest, kannst du das Ergebnis auch nur gemäß der selben Lizenz weitergeben. Der vollständige Lizenztext ist unter Lizenz einsehbar und erläutert deine Rechte und Pflichten.

Die Kartografie in unseren Kartenkacheln und unsere Dokumentation sind unter der “Creative-Commons“-Lizenz „Namensnennung – Weitergabe unter gleichen Bedingungen“ 2.0 (CC BY-SA) verfügbar.

Auch die Form der Namensnennung ist auf der Seite definiert:

Wir verlangen die Verwendung des Hinweises „© OpenStreetMap-Mitwirkende“.

Du musst auch klarstellen, dass die Daten unter der Open-Database-Lizenz verfügbar sind, und sofern du unsere Kartenkacheln verwendest, dass die Kartografie gemäß CC BY-SA lizenziert ist. Du kannst dies tun, indem du auf www.openstretmap.org/copyright verlinkst. Ersatzweise, und als Erfordernis, falls du OSM in Datenform weitergibst, kannst du die Lizenz(en) direkt verlinken und benennen. In Medien, in denen keine Links möglich sind (z. B. gedruckten Werken), empfehlen wir dir, deine Leser direkt auf openstreetmap.org zu verweisen (möglicherweise mit dem Erweitern von „OpenStreetMap“ zur vollen Adresse), auf opendatacommons.org, und, sofern zutreffend, auf creativecommons.org.

Die Stadtwerke wurden von diesem Problem am Donnerstag dem 18.09.2014 von der Community informiert, haben aber bisher nicht reagiert. Und so erfreuen wir uns weiterhin an der Haltestellenkarte ohne korrekte Lizenzierung.

Wenn man seine Windows-Installation über das Telefon aktivieren möchte bzw. aktivieren muss werden einem zwei Telefonnummern für Deutschland angeboten. Eine Nummer ist kostenlos die andere ist es nicht:

0800/2848283 (kostenlos)
069/22225494 (kostenpflichtig)

Wenn man nun versucht die kostenlose Nummer von einem Mobiltelefon aus anzurufen, wird man abgewiesen. Das gleiche passiert bei der Wahl der kostenpflichtigen Nummer. Ohne einen Festnetzanschluss kann man seine Windows-Kopie somit nicht aktivieren. Das hat Microsoft natürlich sehr gut durchdacht… Allerdings gibt es einen Workarround wie man die Aktivierung doch nutzen kann. Dazu muss das Senden der Rufnummer auf dem Gerät deaktiviert werden. Anschließend kann die Aktivierung normal durchgeführt werden.

Möchte man MacPorts auf einer höheren Betriebssystemversion installieren, so wird im Normalfall der Installer für die passende Version heruntergeladen und ausgeführt. Leider gibt es noch keinen fertigen Installer für Mac OS X 10.10 alias Yosemite. In diesem Fall wird MacPorts manuell kompiliert werden. Dazu muss das Terminal geöffnet werden und folgendes eingegeben werden:

curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.3.1.tar.bz2
tar xf MacPorts-2.3.1.tar.bz2
cd MacPorts-2.3.1/
./configure
make
sudo make install

Anschließend können die Ports mittels:

sudo port -v selfupdate
sudo port upgrade outdated
sudo port uninstall inactive

auf den aktuellen Stand gebracht werden. Zu beachten ist, das es durch den Beta-Status der Mac OS X Version natürlich zu Problemen kommen kann.

Ich hatte in den letzten Tagen ein seltsames Verhalten auf meinem Mac. Wenn ich eine Datei löschte wurde kein Speicher freigegeben. Im Gegenteil, der freie Speicher wurde immer weniger. Verantwortlich dafür waren die Mobile Backups. Diese TimeMachine Funktion sorgt dafür das auch dann Backups erstellt werden, wenn das Backup-Laufwerk nicht verfügbar ist. Möchte man diese Funktionalität abschalten, so muss man im Terminal:

sudo tmutil disablelocal

eingeben. Damit wird das lokale Backup deaktiviert und der vom Backup belegte Speicherplatz freigegeben. Beim Löschen von Dateien wird damit wieder Speicher freigegeben.

Bei einer Aktualisierung eines Ubuntusystems mittels des Paketmanagers wurde der Vorgang am Ende mit der Zeile:

The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old 
 you may need to re-run your boot loader[grub]

abgeschlossen. Die Lösung für das Problem ist dabei relativ unkompliziert. Es reicht auf der Konsole:

update-grub

einzugeben. Damit wird die menu.lst erneut geschrieben.

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.