[–] in Manpages

Manpages sind eine der praktischen Dinge auf einem Linux und Mac OS X System. Mit Hilfe des Kommandos man ist es möglich für ein Shellkommando sich die entsprechende Handbuchseite anzuzeigen. In einer solchen Manpage werden unter anderem die Parameter für ein Kommando erklärt. Dies kann dann z.B. so aussehen:

git submodule [--quiet] status [--cached] [--recursive] [--] [<path>…]

Eine Kleinigkeit irritierte mich bis vor kurzem immer an der Syntax zur Beschreibung der Parameter. Es taucht immer der Parameter:

[--]

auf. Wenn man sich in einem entsprechenden Dokument der IEEE zu dieser Syntax umschaut, so wird diese Unklarheit beseitigt. Dort wird unter Guideline 10 erklärt:

The argument — should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the ‚-‚ character. The — argument should not be used as an option or as an operand.

Damit wird klar das die Syntax zur Trennung der Option von den folgenden Operanden dient. Sie findet bei der Nutzung eines Kommandos keine Anwendung, sondern ist nur für den Leser der Beschreibung gedacht.

Wartungsmodus einer ownCloud-Installation aufheben

Wenn man ein Upgrade bei einer ownCloud-Installation durchführt, so wird die entsprechende Installation in den Wartungsmodus versetzt.

ownCloud im Wartungsmodus

ownCloud im Wartungsmodus

Unter Umständen kann es passieren, das der Wartungsmodus nach dem Upgrade nicht mehr deaktiviert wird. In diesem Fall muss der Wartungsmodus manuell deaktiviert werden. Dazu muss die Datei config.php, welche sich im Verzeichnis config befinden geöffnet werden. In dieser Datei findet sich der Eintrag:

'maintenance' => true,

Der Wert von maintenance muss dabei auf false gesetzt werden und die Datei gespeichert werden. Danach ist der Wartungsmodus wieder deaktiviert.

Fehlersuche mit „git bisect“

In größeren Projekten arbeiten meist mehrere Entwickler an einem Git-Repository. Und wie es bei der Software-Entwicklung nun einmal ist kommt es ab und an zu Fehlern. Bei einer komplexen Versionshistorie ist es allerdings schwierig den Ursprungscommit eines Fehlers zu finden. An dieser Stelle hilft das Git-Kommando bisect weiter. Zum Start muss Git mitgeteilt werden welcher der letzte (aus Sicht des Entwicklers) korrekt funktionierende und der erste fehlerhafte Commit ist. Dies geschieht im Terminal auf dem Repository mittels:

git bisect start
git bisect good <hash>
git bisect bad <hash>

Danach checkt bisect einen Commit aus. Dieser Commit muss nun auf den gesuchten Fehler überprüft werden. Ist der Fehler weiterhin vorhanden, so teilen wir dies Git mittels:

git bisect bad

mit. Ist der Fehler nicht mehr vorhanden, so teilen wir Git dies ebenfalls mit:

git bisect good

Dieser Prozess wird dabei so lange durchlaufen bis Git uns am Ende des Prozesses mitteilt, in welchem Commit der Fehler seinen Ursprung hat. Danach können wir uns den Commit notieren und bisect mittels:

git bisect reset

mitteilen das der Prozess zu einem Ergebnis geführt hat. Dadurch wird das Repository in seinen Ursprungszustand versetzt.

Spam-Blacklists abfragen

Manchmal kommt es vor das ein Server welchen man betreut oder betreibt auf einer DNS-based Blackhole List landet. In einem solchen Fall gilt es zu überprüfen ob man nur auf einer oder zwei dieser Listen steht, oder ob man global aufgeführt ist.

Der Dienst am Beispiel von seeseekey.net

Der Dienst am Beispiel von seeseekey.net

Mit dem Dienst MultiRBL welcher unter multirbl.valli.org/lookup/ zu finden ist, lässt sich schnell herausfinden auf welchen Listen der entsprechende Server aufgeführt ist – was der erste Schritt ist um das Problem einzugrenzen und abzustellen.