seeseekey.net - Invictus Deus Ex Machina

Bei Fire­fox 31 hat sich an der Ober­flä­che nicht viel geän­dert. Statt­des­sen wur­den eine Ände­run­gen am Kern vor­ge­nom­men. Eine diese Ände­run­gen betrifft den Konfigurationschlüssel:

browser.tabs.closeButtons

Die­ser Schlüs­sel wird in der der neuen Ver­sion nicht mehr aus­ge­wer­tet. Dies führt dazu das jeder Tab nun stan­dard­mä­ßig sei­nen eige­nen But­ton zum Schlie­ßen des Tabs besitzt. Frü­her könnte der Nut­zer über diese Option den But­ton zum Schlie­ßen von Tabs auch nach rechts oben legen. Dies ist nun ohne wei­tere Hilf­mit­tel nicht mehr möglich.

Hier kommt das Add-On Clas­sic Theme Res­to­rer zum Ein­satz. Mit die­sem ist es mög­lich, wie­der einen But­ton zum Schlie­ßen aller Tabs an das Ende der Tableiste zu legen. Ein ande­res Pro­blem in der neuen Ver­sion behebt das Add-On lei­der nicht. So merkt sich der neue Fire­fox nicht mehr seine Posi­tion, wenn er geschlos­sen wird. Dies ist beson­ders auf Multi-Monitor-Systemen ärger­lich, da der Fire­fox beim Öff­nen auf dem fal­schen Bild­schirm aufgeht.

Bei Enig­mail han­delt es sich um ein Add-On für den freien Mail­cli­ent Mozilla Thun­der­bird. Mit Hilfe die­ses Add-Ons ist es mög­lich ver­schlüs­selte Mails über GPG zu ver­sen­den. Unter Umstän­den kann es bei Enig­mail pas­sie­ren, das man mit fol­gen­der Feh­ler­mel­dung begrüßt wird.

Enig­mail bekommt Probleme

Das Pro­blem liegt daran das Enig­mail die GPG-Installation (im Falle von Mac OS X, die GPG Tools) nicht fin­den kann. Dies scheint ein bekann­tes Pro­blem mit Enig­mail zu sein. Abhilfe schafft hier unter Mac OS X ein sehr sim­pler Vor­gang — der Neu­start des Sys­tems. Danach sollte Enig­mail die GPG Tools wie­der ohne Pro­bleme erkennen.

Wenn man unter Mac OS X ein sh-Skript aus­füh­ren möchte und dabei die Meldung:

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

bekommt, kann das Skript nicht aus­ge­führt wer­den. Das Pro­blem liegt daran das ver­sucht wird den Inter­pre­ter „bin/sh^M“ anstatt „bin/sh“ zu star­ten. Bei dem ^M han­delt es sich um das drei­zehnte ASCII-Zeichen, das Car­riage Return (im deut­schen auch Wagen­rück­lauf genannt). Um das Pro­blem zu behe­ben muss das ent­spre­chende Skript ein­fach um das Car­riage Return Zei­chen berei­nigt wer­den. Dies kann im Ter­mi­nal ein­fach mittels:

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

bewerk­stel­ligt wer­den. Anschlie­ßend sollte das Skript ohne wei­tere Pro­bleme durchlaufen.

Alle die ab letz­ten Don­ners­tag, dem 12. Juni 2014 das „Glas­fa­ser Hyper­netz“ der Stadt­werke in Neu­bran­den­burg nut­zen woll­ten, schau­ten wahr­schein­lich erst ein­mal in die Röhre. Bestimmte Netz­be­rei­che, wie die von Google oder Hetz­ner, lie­ßen sich nicht mehr errei­chen. Das führte zu inter­es­san­ten Effek­ten, so konnte man z.B. Bing nut­zen, Google aber nicht. Die Stö­rung erstreckte sich dabei von Don­ners­tag über Frei­tag, bis Sams­tag. Im Moment scheint das Netz wie­der zu funk­tio­nie­ren, aller­dings mit deut­lich redu­zier­ter Geschwin­dig­keit — wer seine zuge­si­cherte Band­breite aus­schöp­fen möchte hat Pech. Wer in die­sen Tagen auf das Inter­net ange­wie­sen war, der musste sich nach einer Alter­na­tive umschauen. An ein ordent­li­ches Arbei­ten war bei die­sem Stö­rung­bild nicht zu den­ken. Netze waren über den Zeit­raum der Stö­rung mal erreich­bar und kurz dar­auf wie­der verschwunden.

Den Kun­den infor­mie­ren? Nicht bei der neu.sw (Bild: Malte Penn­dorf unter CC-BY-SA)

Das Manage­ment der Stadt­werke ließ auch zu wün­schen übrig. Das ein­zige was man bestä­ti­gen könnte war, das es eine Stö­rung gab. Wie lange sie andau­ert und wodurch sie ver­ur­sacht wurde? Die Ant­wort der Stadt­werke lau­tete zusam­men­ge­fasst: „Wir wis­sen nicht wie lange die Stö­rung dau­ert, noch warum sie da ist?“. Fai­rer­weise muss man sagen, das der Aus­fall als sol­ches nicht in den Bereich der Stadt­werke, son­dern in das „vor­ge­la­gerte Netz“ fiel. So lag der Aus­fall bei der e.discom, wel­che auf ihrer Web­seite mit fol­gen­dem Text werben:

Die Ver­füg­bar­keit des e.discom-Netzes wird durch den Ein­satz moderns­ter Über­tra­gungs­tech­nik, eine hohe Redun­danz und ein leis­tungs­fä­hi­ges Netz­ma­nage­ment garan­tiert. Ein­zel­ver­bin­dun­gen bie­ten wir stan­dard­mä­ßig mit einer Ver­füg­bar­keit von 99,5% im Jah­res­durch­schnitt an. Soll­ten Sie eine höhere Aus­fall­si­cher­heit benö­ti­gen, reden Sie mit uns. Gerne ent­wi­ckeln wir mit Ihnen zusam­men ein pas­sen­des Ser­vice­kon­zept und unter­brei­ten Ihnen ein indi­vi­du­el­les Angebot.

Bei einer zuge­si­cher­ten Ver­füg­bar­keit von 99,5% (was knapp zwei Tage wären), ist ein Aus­fall wel­cher sich über mehr als besagte zwei Tage erstreckt natür­lich bedenk­lich. Auch bei der e.discom konnte man den Feh­ler nicht genau ein­gren­zen, hier wurde sich mit der Holz­ham­mer­me­thode behol­fen — ein­fach neu aufsetzen.

Ganz gleich wer am Ende auch ver­ant­wort­lich ist, die Infor­ma­ti­ons­po­li­tik der Stadt­werke ist nicht hin­nehm­bar. Auf den Web­sei­ten fin­den sich keine Sta­tus­mel­dun­gen zur Stö­rung. Statt­des­sen wird der Kunde im Dun­keln gelas­sen, er hat ja schon bezahlt. Auch schei­nen sich die Stadt­werke keine redun­dante Lei­tun­gen für einen sol­chen Fall vor­zu­hal­ten. Alles in allem hin­ter­lässt das alles einen sehr faden Beigeschmack.

Da sitzt man vor sei­nem Ubuntu-Upgrade und eine unbe­dachte Hand­be­we­gung spä­ter hat man das Upgrade abge­bro­chen. In einem sol­chen Fall sollte man das Upgrade natür­lich fort­set­zen, wer möchte schon gerne ein halb­fer­ti­ges Sys­tem. Wurde die SSH Ver­bin­dung unter­bro­chen, muss sich im ers­ten Schritt mit dem Ser­ver ver­bun­den wer­den. Anschlie­ßend gibt man im Ter­mi­nal fol­gen­des ein:

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

Danach sollte der Ser­ver auf dem aktu­ells­ten Stand sein und das Upgrade durch­ge­führt sein. Sollte man das Upgrade vor dem Umstel­len der Paket­lis­ten abge­bro­chen haben, dürfte ein ein­fa­ches „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 Pro­ble­men mit dem Voll­bild­mo­dus füh­ren. Möchte man den Vir­tual­Box Gast auf dem zwei­ten Moni­tor betrei­ben, so ist dies ohne Pro­bleme mög­lich. Akti­viert man aller­dings den Voll­bild­mo­dus von Vir­tual­Box auf dem sekun­dä­ren Moni­tor, wird das Voll­bild statt­des­sen auf dem Haupt­schirm aktiviert.

In der Mini-Toolbar kann der ent­spre­chende Moni­tor ein­ge­stellt werden

Als Lösung bie­tet sich hier die Mini-Toolbar an wel­che im Vollbild-Modus ange­zeigt wird. Über das Menü kann der Bild­schirm, wel­cher im Voll­bild zum Zuge kom­men soll, aus­ge­wählt wer­den. Vir­tual­Box merkt sich diese Ein­stel­lung auch für die Zukunft, so das sie nur ein­mal nötig ist. Ist die Mini-Toolbar im Vollbild-Modus nicht zu sehen, so muss sie in den Ein­stel­lun­gen der ent­spre­chen­den vir­tu­el­len Maschine akti­viert werden.

Wenn man beim Zugriff mit­tels SSH unter Mac OS X fol­gende Mel­dung bekommt:

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

weißt das auf ein Pro­blem mit den Zugriffs­rech­ten hin. In die­sem Fall sind die Rechte für den pri­va­ten Schlüs­sel zu groß­zü­gig ver­ge­ben. Dies kann unter ande­rem dann pas­sie­ren wenn man ein Backup ein­spielt. Um die­ses Pro­blem zu behe­ben, gibt man im Ter­mi­nal fol­gen­des ein:

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

Damit sind die Zugriffs­rechte für diese Dateien restrik­tiv gesetzt, so das SSH an die­ser Stelle wie­der pro­blem­los funktioniert.

Bei einer ownCloud-Instanz wel­che schon einige Betriebs­stun­den auf dem Buckel hat, kann es zu einem unschö­nen Effekt kom­men. Beim Ver­such den Papier­korb über die Funk­tion „Gelöschte Dateien“ zu lee­ren, ver­sucht own­Cloud alle Dateien auf­zu­lis­ten, was aller­dings nicht gelingt. Der Brow­ser friert ein und das Lee­ren des Papier­kor­bes ist nicht möglich.

Der But­ton um die gelösch­ten Dateien aufzurufen

Auch wenn das Lee­ren des Papier­kor­ber nach Mei­nung der ownCloud-Entwickler nicht not­wen­dig ist, da die Dateien nach einer Weile weg­ge­wor­fen wer­den, sollte es trotz­dem eine Lösung geben um den Papier­korb manu­ell zu lee­ren. Ein Work­ar­round ist es den Papier­korb direkt zu löschen in dem man das Ver­zeich­nis „owncloud/data/username/files_trashbin/ löscht. Anschlie­ßend müs­sen noch zwei Tabel­len in der Daten­bank berei­nigt werden:

TRUNCATE TABLE oc_files_trashsize;
TRUNCATE TABLE oc_files_trash;

Eine wei­tere Mög­lich­keit diese Pro­ble­ma­tik zu ent­schär­fen, ist es die Vor­hal­te­zeit von gelösch­ten Dateien von 180 Tagen auf 30 Tage zu redu­zie­ren. Dazu öff­net man die config.php Datei wel­che im config-Ordner zu fin­den ist und trägt fol­gen­den Wert ein:

'trashbin_retention_obligation' => 30,

Damit wird ver­hin­dert das sich zu viele Dateien im Papier­korb ansam­meln und das Pro­blem deut­lich entschärft.

Mit­tels OSX­Fuse und dem mit­ge­lie­fer­ten Paket für SSHFS ist es unter Mac OS X mög­lich sich mit­tels SSH zu einem Ser­ver zu ver­bin­den und sein Datei­sys­tem ein­zu­bin­den. In mei­nem Fall sah das auf dem Ter­mi­nal so aus:

sshfs root@example.com:/ /Volumes/example

So weit funk­tio­nierte auch alles, nur bei machen Dateien wurde ich von einem „Per­mis­sion denied“ begrüßt. Lösen lässt sich die­ser Feh­ler durch die Angabe des Para­me­ters „-o defer_permissions“:

sshfs -o defer_permissions root@example.com:/ /Volumes/example

Damit kön­nen alle Dateien und Ord­ner auf dem ent­spre­chend ein­ge­bun­de­nen ent­fern­ten Rech­ner genutzt werden.

Wenn man eine Anwen­dung mit­tels „screen“ aus­führt, kann es pas­sie­ren das man den Fehler:

Cannot open your terminal '/dev/pts/0' - please check.

zu Gesicht bekommt. Viel­fach wird emp­foh­len bei die­sem Feh­ler die Rechte des Gerä­tes zu ändern:

chmod 777 /dev/pts/0

Anstatt diese Lösung zu nut­zen sollte man vor der Aus­füh­rung von „screen“ den Befehl:

script /dev/null

aus­zu­füh­ren. Damit kann „screen“ anschlie­ßend ohne Feh­ler­mel­dung genutzt werden.