Probleme mit dem cryptsetup-Workarround

Vor einigen Monaten veröffentlichte ich eine Anleitung zur Verschlüsselung eines Ubuntu-Servers. Da es einen Bug im cryptsetup gab, wurde in dem Artikel ein Workarround beschrieben. Mittlerweile wurde das cryptsetup-Paket aktualisiert und der entsprechende Bug gefixt. Allerdings führt dies zu Problemen mit dem Workarround. Möchte man den Server nun entsperren, erhält man folgende Meldung:

$ cryptroot-unlock
/bin/cryptroot-unlock: line 192: 2: parameter not set
/bin/cryptroot-unlock: line 192: 2: parameter not set
/bin/cryptroot-unlock: line 192: 2: parameter not set

Gelöst werden kann dieses Problem in dem folgendes Kommando genutzt wird:

sed 's/print $1, $5/print $1, $3/' /bin/cryptroot-unlock > /tmp/cryptroot-unlock; ash /tmp/cryptroot-unlock

Damit lässt sich der Server entsperren. Im zweiten Schritt kann nun der Workarround entfernt werden und das initramfs aktualisiert werden:

rm /etc/initramfs-tools/hooks/cryptsetup-fix.sh 
update-initramfs -u

Nach einem Neustart des Systems, kann dieses nun wie folgt entsperrt werden:

BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cryptroot-unlock 
Please unlock disk cryptroot (/dev/md1): 
cryptsetup: cryptroot set up successfully
# exit

Anschließend wird das System hochgefahren und der Server steht zur Verfügung.

Workaround für Episoden Seiten im Podlove Publisher

Im Podlove Publisher gibt es in den Experteneinstellungen die Möglichkeit Episoden Seiten zu aktivieren. Gemeint ist damit nicht anders als alle Podcastbeiträge auf einer zusätzlichen Seite anzeigen zu lassen. Seit der Version 2.7.0 des Podlove Publisher funktionierte dieses Feature bei mir nicht mehr.

Die Episoden Seite für alle veröffentlichenden Podcasts

Hintergrund war der Commit b4d9f14; hier gab es unter anderem eine Änderung in der Datei permalinks.php. Wenn nun die URL für die Episoden Seiten eingestellt wurde funktionierte diese nicht mehr. Stattdessen gab es nur die Meldung das die Seite nicht existiert. Als Workaround habe ich die permalinks.php-Datei wieder um folgenden Quellcode aus dem Commit erweitert:

// Add archive pages
if ( 'on' == \Podlove\get_setting( 'website', 'episode_archive' ) ) {
	$archive_slug = trim( \Podlove\get_setting( 'website', 'episode_archive_slug' ), '/' );

	$blog_prefix = \Podlove\get_blog_prefix();
	$blog_prefix = $blog_prefix ? trim( $blog_prefix, '/' ) . '/' : '';

	$wp_rewrite->add_rule( "{$blog_prefix}{$archive_slug}/?$", "index.php?post_type=podcast", 'top' );
	$wp_rewrite->add_rule( "{$blog_prefix}{$archive_slug}/{$wp_rewrite->pagination_base}/([0-9]{1,})/?$", 'index.php?post_type=podcast&paged=$matches[1]', 'top' );
}

Der Quellcode muss an das Ende der Funktion podlove_add_podcast_rewrite_rules angetragen werden. Damit funktioniert das Episoden Seiten-Feature bei mir wieder ohne Probleme. Natürlich muss dieses Prozess bei jedem Update des Podlove Publisher wiederholt werden.

ownCloud cron.lock Probleme abmildern

ownCloud aktualisiert regelmäßig Daten im Hintergrund mittels eines Cronjobs. So werden z.B. neue Artikel aus RSS-Feeds bezogen, wenn die App News installiert ist. Während der Cronjob durchgeführt wird, legt ownCloud eine Datei mit dem Namen cron.lock im data-Verzeichnis der ownCloud Installation an. Unter Umständen kann es passieren das der Cronjob nicht zu einem ordentliche Abschluss kommt und die cron.lock-Datei damit bestehen bleibt. Dies führt dazu das ownCloud keine Aktualisierungen mehr vornehmen kann. Als Workaround kann die Sperrdatei mit einem Cronjob regelmäßig entfernt werden. Dazu muss die Crontab bearbeitet werden:

crontab -e

In die sich öffnende Crontab-Datei wird nun folgendes eingetragen:

4    0    * * *   rm /var/www/example/owncloud/data/cron.lock

Damit wird die cron.lock-Datei jeden Tag um 0:04 Uhr gelöscht, falls sie vorhanden sein sollte. Wichtig ist es dabei die Crontab-Datei mit einer Leerzeile abzuschließen und den Pfad an die eigene Installation anzupassen.

Probleme mit schwarzem Hintergrund im Watch-Fenster des Visual Studios

Beim Debuggen mit dem Visual Studio 2013 fiel mir ein Problem mit dem Watch-Fenster auf. Die Anzeige des Watch-Fensters bestand nur noch aus schwarzen Balken. Damit lässt sich natürlich schlecht debuggen, so das Abhilfe geschaffen werden musste.

Das Watch-Fenster zeigt nur noch schwarze Balken

Das Watch-Fenster zeigt nur noch schwarze Balken

Eine Umstellung der Farbschemas von Blue auf Dark oder Light brachte Besserung, allerdings betreibe ich mein Visual Studio lieber im Farbschema Blue. Doch nach dem Zurückschalten sind die schwarzen Balken im Watch-Fenster wieder da.

Nach der Umstellung funktioniert das Watch-Fenster wieder

Nach der Umstellung funktioniert das Watch-Fenster wieder

Bei diesem Problem scheint es sich um einen Fehler im Visual Studio zu handeln, welcher mit einem etwas kruden Workarround behoben werden kann. Dazu sucht man in den Optionen den Punkt Fonts and Colors und ändert dort die Farbe für den Punkt Merge – Block selection box auf White. Anschließend ist das Watch-Fenster wieder nutzbar.

Probleme mit VirtualBox und der Alt-Gr-Taste

Wenn man die aktuelle VirtualBox-Version 4.3.14 nutzt, wird man im Gastsystem feststellen das die Alt-Gr-Taste nicht korrekt funktioniert. Das äußert sich z.B. darin das At-Zeichen nicht mehr geschrieben werden kann. Der Fehler tritt dabei augenscheinlich nur in Verbindung mit der deutschen Tastaturbelegung auf. Mittlerweile gibt es einen entsprechenden Bugreport bei VirtualBox.

Der Tastatureinstellungen unter Kubuntu

Der Tastatureinstellungen unter Kubuntu

Unter Kubuntu ist es als Workarround möglich eine andere Taste für die dritte Tastaturebene zu definieren. Auch scheint es im neusten Test-Build der VirtualBox einen Bugfix für dieses Problem zu geben. Solange diese Version noch noch nicht offiziell veröffentlicht wurde, muss man sich mit einem Workarround behelfen.