Man denkt ja immer: Account-Umzug im Fediverse, das ist heute doch Standard. Knopf drücken, neues Konto auswählen, fertig. In der Praxis ist es leider oft nicht so romantisch. Gerade bei Sharkey, also einem Misskey-Fork, kann es passieren, dass eine Migration zu Mastodon hängen bleibt oder halb durchläuft. Der alte Account steht dann auf „umgezogen“, der neue übernimmt aber keine Follower oder bricht einfach ab. Ergebnis: Man hängt zwischen zwei Instanzen fest und kommt über die Oberfläche nicht mehr zurück.
Genau das ist mir passiert. Der Umzug von Sharkey zu Mastodon wollte einfach nicht mehr sauber starten. Sharkey selbst bietet aber keine Möglichkeit, einen angefangenen Umzug wieder rückgängig zu machen. In der Weboberfläche gibt es dafür keinen Knopf. Also bleibt nur der Blick unter die Haube, direkt in die Datenbank.
Wichtig vorweg: Sharkey speichert den Migrationsstatus direkt im Benutzerkonto in der Datenbank. Dort gibt es zwei Felder, die sagen: Dieser Account wurde verschoben. Das eine heißt movedToUri, also wohin der Account umgezogen ist, und das andere movedAt, also wann. Solange diese Felder gesetzt sind, denkt Sharkey: Der Account ist weggezogen und darf nicht nochmal umziehen oder normal benutzt werden.
Um das Problem zu lösen, muss man genau diesen Status zurücksetzen. Dazu verbindet man sich zuerst mit der PostgreSQL-Datenbank des Sharkey-Containers. In meinem Fall heißt der Container sharkey-db-1, der Benutzer sharkey-db und die Datenbank misskey. Der Zugang sieht dann so aus:
Man geht per Docker in den Container und startet psql:
docker exec -it sharkey-db-1 psql -U sharkey-db -d misskeyIst man drin, prüft man zuerst, ob der eigene Benutzer wirklich als „moved“ markiert ist. Wichtig: In Misskey und Sharkey kann es mehrere Datensätze mit gleichem Nutzernamen geben, zum Beispiel für Remote-Accounts. Deshalb arbeitet man nicht mit dem Namen, sondern mit der eindeutigen ID.
Redirect URL löschen
Man sucht sich also den richtigen Eintrag und schaut nach:
SELECT id, username, "movedToUri", "movedAt" FROM "user" WHERE username = 'lars';
In meinem Fall war klar zu sehen: Eine ID hatte als Ziel https://fulda.social/users/lars eingetragen und ein Datum dazu. Das ist genau der Datensatz, der den Umzug blockiert. Den Screenshot habe ich leider erst später gemacht, da war der Abbruch schon Geschichte.
Um den Umzug abzubrechen, setzt man diese beiden Felder einfach wieder auf leer. Das macht man sauber in einer Transaktion:
BEGIN; UPDATE "user" SET "movedToUri" = NULL, "movedAt" = NULL WHERE id = 'HIER-DIE-RICHTIGE-ID-EINSETZEN'; COMMIT;Code-Sprache: PHP (php)Danach kontrolliert man nochmal mit einem SELECT, ob beide Felder wirklich NULL sind. Wenn das passt, ist Sharkey aus Datenbanksicht wieder der Meinung: Dieser Account ist nie umgezogen.
Zum Schluss muss man nur noch den Sharkey-App-Container neu starten, damit keine alten Cache- oder Worker-Zustände im Speicher bleiben. Die Datenbank selbst muss man nicht neu starten, nur die Anwendung.
Nach diesem Schritt ist der Account wieder ganz normal nutzbar und man kann den Migrationsversuch erneut starten oder sich erst einmal sammeln, bevor man es nochmal probiert.
Fazit:
Unterm Strich zeigt das Ganze ziemlich gut: Föderation ist cool, aber Migration zwischen Plattformen ist noch nicht überall sauber gelöst. Gerade zwischen Misskey-Forks wie Sharkey und Mastodon kann es holpern. Gut zu wissen ist aber: Man ist nicht verloren, wenn so etwas passiert. Solange man Zugriff auf die Datenbank hat, kann man den Umzug abbrechen und seinen Account wieder „entfesseln“.
Das ist kein Trick für den Alltag, sondern eher der Notausgang. Aber es ist beruhigend zu wissen, dass es ihn gibt, wenn der Umzug mal wieder meint, er müsste auf halbem Weg stehen bleiben.