Ulysses und Probleme mit der Synchronisation unter iOS

Das Schreibprogramm Ulysses erschien vor einigen Wochen in der Version 18. Neben der macOS-Version erschien zeitgleich die entsprechende iOS-Version. Die beiden Versionen können über iCloud oder per Dropbox synchronisiert werden.

‎Ulysses
Preis: Kostenlos+
‎Ulysses
Preis: Kostenlos+

Bei der Dropbox-Variante wurden bis zur Version 18 ausschließlich Markdown-Dateien synchronisiert, welche allerdings nicht alle Features von Ulysses abdecken. Mit der neuen Version können nun auch die internen von Ulysses genutzten Dateien zur Synchronisierung genutzt werden.

Im ersten Schritt müssen die Einstellungen für den Ordner geöffnet werden

Allerdings werden, nachdem der Ordner aus der Dropbox unter iOS hinzugefügt wurde, nur die Ordner und nicht die Texte synchronisiert. Verantwortlich hierfür ist ein Bug, welcher in einer der nächsten Versionen behoben werden soll. Zum Glück kann sich mit einem Workaround beholfen werden.

Anschließend kann auf das interne Format umgestellt werden

Dazu müssen die Einstellungen des Dropbox-Ordners unter iOS geöffnet werden. Anschließend sollte dort das Feld Markdowndateien lesen und schreiben deaktiviert werden. Danach beginnt die Synchronisierung der internen Ulysses-Dateien. Der Fortschritt lässt sich am besten über das Statistikfenster beobachten. Manchmal scheint die Synchronisation erst zu starten, wenn ein Ordner geöffnet wurde, in welchem das Cloud-Symbol angezeigt wird.

Was leider auch mit der neuen Ulysses-Version immer noch nicht funktioniert, ist die Einbindung über WebDAV, sodass der Nutzer im Moment immer noch gezwungen ist fremde Cloud-Dienste zu nutzen. Eine Anbindung an eine eigene Nextcloud-Instanz (über WebDAV) ist somit immer noch Zukunftsmusik und wird vom Ulysses-Team gefühlt sehr stiefmütterlich behandelt. Stattdessen wird der Nutzer immer wieder auf unbestimmte Zeit vertröstet. Bei einer Software die vom Nutzer abonniert werden muss und somit dauerhaft zur Finanzierung der Firma beiträgt, darf der Nutzer erwarten, dass solche Anwendungsszenarien Beachtung finden.

Kalenderdateien mit webcal-Schema herunterladen

Manche Dienste und Webseiten bieten Kalenderdateien über das inoffizielle URL-Schema webcal:// an. Wird nun versucht eine solche URL herunterzuladen:

wget webcal://example.org

erhält der Nutzer in den meisten Fällen die Meldung:

Nicht unterstütztes Schema »webcal«

Abhilfe schafft es in diesem Fall das Schema webcal durch http bzw. https zu ersetzen. Anschließend kann die Datei mit den Kalendereinträgen problemlos heruntergeladen werden.

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.