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.

Commander One

Wenn ich ein neues System nutze, suche ich relativ schnell nach einem passenden Dateimanager für das System. Infrage kommen hierbei nur 2-Panel-Dateimanager, aka Norton Commander-Clones. Unter Windows nutze ich den Altap Salamander, welcher vor kurzem Freeware geworden ist. Unter macOS habe ich ein paar Jahre den muCommander genutzt. Mittlerweile nutze ich unter macOS den Dateimanager Commander One von Eltima Software.

Der Dateimanager Commander One

Die Grundfunktionen des Dateimanagers sind kostenlos und reichen für die meisten Anwender wahrscheinlich aus. Daneben existiert eine Pro-Version, welche per In-App-Kauf freigeschaltet werden kann. In dieser Version ist die Unterstützung für FTP, SFTP, MTP, WebDAV, die erweiterte Unterstützung für Archive und vieles andere enthalten.

Commander One wurde komplett in Swift geschrieben und nativ für macOS entwickelt; er kann über den Appstore bezogen werden.

Maven-Repository in Eigenregie hosten

Wenn mittels Maven eine Abhängigkeit zur pom.xml-Datei, wie in folgendem Beispiel, hinzugefügt wird:

<dependency>
	<groupId>org.slf4j</groupId>
	<artifactId>slf4j-api</artifactId>
	<version>1.7.26</version>
</dependency>

versucht Maven diese Abhängigkeit von Maven Central, dem zentralen Repository, zu beziehen. Es ist allerdings möglich Abhängigkeiten aus anderen Repositories zu beziehen. Dazu muss der repositories-Block zur pom.xml hinzugefügt werden.

<repositories>
	<repository>
		<id>example</id>
		<url>https://repository.example.org</url>
	</repository>
</repositories>

Aus Nutzersicht ist die Konfiguration von Maven damit erledigt. Soll ein solches Maven-Reposity aufgesetzt werden, ist dies relativ einfach möglich. Dazu wird ein Verzeichnis per HTTP über den Webserver Nginx ausgeliefert. Innerhalb dieses Verzeichnisses wird ein gesicherter Ordner erstellt, welcher über WebDAV erreicht werden kann. Die entsprechende Nginx-Konfiguration sieht für diesen Fall wie folgt aus:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/repository.example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/repository.example.org/privkey.pem;

        root /var/www/example/repository;

        server_name repository.example.org;

        location / {
                autoindex     on;
        }

        location /upload {
                dav_methods     PUT DELETE MKCOL COPY MOVE;
                dav_ext_methods   PROPFIND OPTIONS;

                dav_access    user:rw group:rw all:rw;

                create_full_put_path  on;

                autoindex     on;

                auth_basic "restricted";
                auth_basic_user_file /var/www/example/repository/upload/.htpasswd;
        }
}

Die .htpasswd-Datei, welche für die Authentifizierung benötigt wird, kann mit dem Tool htpasswd erstellt werden:

htpasswd -c .htpasswd nutzer1

Bei der Nutzung wird das gewünschte Passwort erfragt. Soll ein weiterer Nutzer hinzugefügt werden, so muss der Parameter -c entfernt werden:

htpasswd .htpasswd nutzer2

Anschließend wird die Konfiguration von Nginx mittels:

service nginx reload

aktualisiert. Danach kann WebDAV für die Ressource verwendet werden. In der pom.xml-Datei für das Projekt, welches ein Artefakt für das Repository erzeugt, wird der build-Bereich erweitert und der distributionManagment-Bereich hinzugefügt:

            </plugin>
        </plugins>
        <extensions>
            <extension>
                <groupId>org.apache.maven.wagon</groupId>
                <artifactId>wagon-webdav-jackrabbit</artifactId>
                <version>3.2.0</version>
            </extension>
        </extensions>
    </build>
    <distributionManagement>
        <repository>
            <id>example</id>
            <url>dav:https://repository.example.org/upload/</url>
            <layout>default</layout>
        </repository>
    </distributionManagement>
</project>

Im Extension-Bereich wird das Wagon-Plugin für WebDAV aktiviert. Dieses sorgt dafür das die Artefakte per WebDAV zum Repository hochgeladen werden. In dem distributionManagment-Bereich wird die WebDAV-URL definiert. Wenn nun ein:

mvn deploy

durchgeführt wird, wird dies allerdings nicht funktionieren. Hintergrund ist das der upload-Ordner per Basic authentication geschützt ist. Die Zugangsdaten für diese Authentifikation müssen noch hinterlegt werden. Natürlich werden diese nicht in der pom.xml hinterlegt, da dies aus Gründen der Sicherheit keine gute Idee wäre. Stattdessen werden die Daten in der settings.xml hinterlegt. Diese befindet sich im Pfad:

~/.m2/settings.xml

In dieser Datei wird eine server-Sektion mit den Zugangsdaten hinzugefügt:

<settings>
	<servers>
		<server>
			<id>example</id>
			<username>example</username>
			<password>password</password>
		</server>
	</servers>
</settings>

Anschließend kann das Artefakt erfolgreich mittels:

mvn deploy

in das Repository hochgeladen werden. Problematisch ist das sich die Daten nur im upload-Verzeichnis und nicht im eigentlichen Verzeichnis des Repository liegen. Zur Lösung hierfür wird ein Cronjob, im Kontext des Nutzers www-data, angelegt:

sudo -u www-data crontab -e

Ziel des Cronjobs ist es die Daten aus dem upload-Verzeichnis regelmäßig in das eigentliche Verzeichnis des Repository zu kopieren:

*/5  *    * * *   cp /var/www/example/repository/upload/* /var/www/example/repository/ -r

Damit wird alle 5 Minuten der Inhalt des uploadVerzeichnisses in das Repository kopiert. Ein Verschieben kann leider nicht durchgeführt werden, da die Metadaten beim jeden Deployment von Maven eingelesen werden und erweitert werden. Hier könnten Optimierungen durchgeführt werden, so das alle Dateien bis auf die Metadaten verschoben werden. Soll ein nicht öffentliches Repository erstellt werden, kann auf den zusätzlichen upload-Ordner verzeichnet werden und das Hauptverzeichnis selber per WebDAV befüllt werden. So lange die Zugangsdaten für den Server in der settings.xml-Datei hinterlegt sind, können seitens Maven die entsprechenden Artefakte bezogen werden.

WebDAV unter Nginx einrichten

Der freie Webserver Nginx beherrscht nicht nur das gewöhnliche Ausliefern von Daten über HTTP und HTTPS, sondern verfügt daneben über weitere Module. Mit einem dieser Module kann WebDAV für eine Ressource bereitgestellt werden.

WebDAV steht dabei für Web-based Distributed Authoring and Versioning und basiert auf HTTP. Über WebDAV können Dateien im Internet bereitgestellt werden. Unter anderem ist WebDAV deshalb so interessant weil es die gleichen Ports wie HTTP nutzt und somit in den seltensten Fällen blockiert wird.

Zur Nutzung des Modules für WebDAV muss die Konfiguration der jeweiligen Seite unter /etc/nginx/sites-available/ angepasst werden. In diesem Beispiel wäre dies:

nano /etc/nginx/sites-available/example

Zur dieser Konfigurationsdatei wird folgende Konfiguration hinzugefügt:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;

        root /var/www/example;

        server_name example.org;

        location / {
                dav_methods     PUT DELETE MKCOL COPY MOVE;
                dav_ext_methods   PROPFIND OPTIONS;
                dav_access    user:rw group:rw all:rw;

                autoindex     on;
        }
}

In diesem Fall wird für die Domain example.org die WebDAV-Unterstützung aktiviert. Dateien können hierbei ohne weitere Authentifizierung herunter- und hochgeladen werden. Soll WebDAV abgesichert werden, so geschieht das über den Basic authentication. Dazu wird dem location-Part folgendes hinzugefügt:

auth_basic "restricted";
auth_basic_user_file /var/www/example/.htpasswd;

Die .htpasswd-Datei kann mit dem Tool htpasswd erstellt werden:

htpasswd -c .htpasswd nutzer1

Bei der Nutzung wird das gewünschte Passwort erfragt. Soll ein weiterer Nutzer hinzugefügt werden, so muss der Parameter -c entfernt werden:

htpasswd .htpasswd nutzer2

Anschließend wird die Konfiguration von Nginx mittels:

service nginx reload

aktualisiert. Danach kann WebDAV für die Ressource verwendet werden.

Probleme mit der Synchronisation unter Enpass 6

Vor knapp einem halben Jahr bin ich vom Passwort-Manager 1Passwort in Richtung Enpass umgestiegen. Vor ein paar Tagen ist die neue Version Enpass 6 erschienen, welche eine neue Oberfläche, die Unterstützung für mehrere Tresore und einige andere Dinge mitbringt. Bedingt durch die Änderungen funktioniert die Synchronisation leider nicht mehr; so das diese neu konfiguriert werden muss.

Einige Neuerungen führen zu Problemen bei der Synchronisation

Hintergrund hierfür ist das Zurücksetzen der Einstellungen nach dem Upgrade auf Enpass 6. Unter Enpass nutzte ich WebDAV (in diesem Fall eine Nextcloud-Instanz) zur Synchronisation mit einer URL nach dem Schema:

https://example.com/remote.php/webdav/Apps/Enpass

Wird die bestehende URL genutzt führt dies zu einem Fehler in der Synchronisation. Bedingt ist durch die Änderung des Formates, welches von Enpass im WebDAV-Ordner abgelegt wird. Dieser muss vor einer erneuten Synchronisation gelöscht werden. Daneben muss die URL angepasst werden:

https://example.com/remote.php/webdav/Apps

Der Ordner Enpass muss nicht mehr explizit angegeben werden, da dieser unter Enpass 6 automatisch angelegt wird. Mit diesen Änderungen synchronisiert Enpass wieder ohne Probleme mit einem WebDAV-Ziel.