Neuer Firefox-Syncserver (Rust) in Docker mit MariaDB-Datenbank

[Adama]

Naja, das ist ja das Original...

Und das Syncserver-Team sagt ja sogar selber, die Images sind nur zum Testen, nicht für die Produktion.

Den Weg zu Spanner gehen die wohl, weil SQL-DBs nicht leistungsfähig genug sind, soweit ich das verstanden hab.

Wie gesagt, ich würds noch mal nur mit dem Container testen. Ich vermute mal, der 404 kommt daher, dass im Image in der Config-Datei natürlich noch die URL steht.

Edit: Wobei ich grad bei einem Test feststellen konnte, bei mir geht es auch mit der IP und dem Port des Containers.

 

[mabox]

Naja, das ist ja das Original...

Hi, ja ich weiß schon meinte zurück halt zur Original Sync URL bzw. wieder weg vom selfhosting.
Also ich habs jetzt mal auch direkt getestet mit IP und Port. Heartbeat funktioniert und auch die Sync URL. Die Synchronisation klappt am Ende aber weiterhin nicht mit dem gleichen Ergebnis:

1721151100898    Sync.ErrorHandler    ERROR    Sync encountered a login error

Muss irgendwas in der DB sein demnach. Versteh ich halt nicht weil beim docker compose up -d klappt der Zugriff ja auch, die Tabellen in der da noch leeren Datenbank z.B. werden angelegt usw. Das ist dann halt erst mal so..... denke ich teste ein andermal wieder, vielleicht bei der 17.2 dann....

 

[Adama]

Hast du mal die Einträge in der tokenserver-DB kontrolliert? Nicht dass sich da irgendwo ein Fehler eingeschlichen hat...

Hast du die DBs eigentlich neu angelegt oder nutzt du die von der 0.13.7 weiter?

 

[mabox]

Also ich hab sowohl als auch, als erstes hatte ich die gleichen DBs genommen. Am Ende aber dann alles komplett neu wie von Dir beschrieben gemacht. In der Token DB hatte ich dann aber als Unterschied zur 13.7 diese beiden extra Einträge , wie von Dir beschrieben, nicht gemacht.

 

[Adama]

Mit der Selbst-Compile-Methode ist das auch nicht nötig, das werden die von dem entrypoint.sh-Skript angelegt. Aber das sind an sich die selben wie vorher. Das hat sich nicht geändert.

Das passiert natürlich nur, wenn diese nicht existieren...

 

[Prince_LG]

Hallo zusammen,

ich habe in Portainer einen Stack mit syncstorage-rs:0.13.7 erstellt. Das Serverlog sieht gut aus :
Nov 04 21:39:18.344 INFO Starting 2 workers
Nov 04 21:39:18.344 INFO Starting "actix-web-service-0.0.0.0:8000" service on 0.0.0.0:8000
Nov 04 21:39:18.344 INFO Server running on http://0.0.0.0:8000 (mysql) No quota

Firefox-Konto habe ich auch eingerichtet.

http://192.168.178.150:5000/__heartbeat__ sieht auch gut aus
{"quota":{"enabled":false,"size":0},"version":"0.13.7","database":"Ok","status":"Ok"}

Leider funktioniert der sync nicht:

1730758657050 Sync.LogManager DEBUG Flushing file log
1730758657054 FirefoxAccounts TRACE not checking freshness of profile as it remains recent
1730758657054 FirefoxAccounts TRACE not checking freshness of profile as it remains recent
1730758657056 Sync.LogManager DEBUG Log cleanup threshold time: 1729894657056
1730758657063 Sync.LogManager DEBUG Done deleting files.
1730758718838 FirefoxAccounts TRACE not checking freshness of profile as it remains recent
1730758920573 FirefoxAccounts INFO Polling device commands.
1730758920573 Sync.Service DEBUG User-Agent: Firefox/132.0 (Windows NT 10.0) FxSync/1.134.0.20241021175835.desktop
1730758920573 Sync.Service INFO Starting sync at 2024-11-04 23:22:00 in browser session P4OfkHREzhatyo
1730758920573 Sync.Service DEBUG In sync: should login.
1730758920574 Sync.Service INFO User logged in successfully - verifying login.
1730758920574 FirefoxAccounts DEBUG FxAccountsProfileClient: Requested profile
1730758920574 FirefoxAccounts DEBUG getOAuthToken enter
1730758920574 FirefoxAccounts TRACE getCachedToken returning cached token
1730758920574 FirefoxAccounts DEBUG getOAuthToken returning a cached token
1730758920574 Sync.SyncAuthManager DEBUG unlockAndVerifyAuthState already has (or can fetch) sync keys
1730758920575 Services.Common.RESTRequest DEBUG GET request to https://profile.accounts.firefox.com/v1/profile
1730758920575 Sync.Status DEBUG Status.login: error.login.reason.network => success.status_ok
1730758920575 Sync.Status DEBUG Status.service: error.login.failed => error.login.failed
1730758920575 Sync.Service DEBUG Fetching unlocked auth state returned success.status_ok
1730758920577 Services.Common.RESTRequest DEBUG GET request to https://api.accounts.firefox.com/v1/account/device/commands?index=0
1730758920763 Services.Common.RESTRequest DEBUG GET https://profile.accounts.firefox.com/v1/profile 304
1730758920773 Services.Common.RESTRequest DEBUG GET https://api.accounts.firefox.com/v1/account/device/commands?index=0 200
1730758920773 Hawk DEBUG (Response) /account/device/commands?index=0: code: 200 - Status text:
1730758920773 Hawk DEBUG Clock offset vs https://api.accounts.firefox.com/v1: -2773
1730758922622 Sync.Resource WARN GET request to http://192.168.178.150/1.5/4/info/collections failed: [Exception... "The connection was refused" nsresult: "0x804b000d (NS_ERROR_CONNECTION_REFUSED)" location: "<unknown>" data: no] No traceback available
1730758922623 Sync.Service DEBUG verifyLogin failed: [Exception... "The connection was refused" nsresult: "0x804b000d (NS_ERROR_CONNECTION_REFUSED)" location: "<unknown>" data: no] No traceback available
1730758922623 Sync.Status DEBUG Status.login: success.status_ok => error.login.reason.network
1730758922623 Sync.Status DEBUG Status.service: error.login.failed => error.login.failed
1730758922623 Sync.Status DEBUG Status.login: error.login.reason.network => error.login.reason.network
1730758922623 Sync.Status DEBUG Status.service: error.login.failed => error.login.failed
1730758922623 Sync.ErrorHandler ERROR Sync encountered a login error
1730758922623 Sync.SyncScheduler DEBUG Clearing sync triggers and the global score.
1730758922625 Sync.SyncScheduler DEBUG Next sync in 3600000 ms. (why=schedule)
1730758922626 Sync.Service DEBUG Exception calling WrappedLock: Error: Login failed: error.login.reason.network(resource://services-sync/service.sys.mjs:1041:15) JS Stack trace: onNotify@service.sys.mjs:1041:15
1730758922626 Sync.Service DEBUG Not syncing: login returned false.
1730758922626 FirefoxAccounts TRACE not checking freshness of profile as it remains recent

Suche händeringend nach einer Fehlerlösung

 

[Adama]

1730758922622 Sync.Resource WARN GET request to http://192.168.178.150/1.5/4/info/collections failed: [Exception... "The connection was refused" nsresult: "0x804b000d (NS_ERROR_CONNECTION_REFUSED)" location: "<unknown>" data: no] No traceback available
1730758922623 Sync.Service DEBUG verifyLogin failed: [Exception... "The connection was refused" nsresult: "0x804b000d (NS_ERROR_CONNECTION_REFUSED)" location: "<unknown>" data: no] No traceback available

Was mir auffällt, sind diese beiden Zeilen.

Du sprichst das im Moment nur aus deinem lokalen Netz an?

Die beiden Einträge in der DB hast du erzeugt?

Den Server hast du in der Firefox-Konfiguration richtig eingetragen?

 

[Prince_LG]

Ja, nach diversen mißlungenen Versuchen mit Zugriff über eine Domain möchte ich es zuerst über die lokale IP versuchen.
In Firefox habe ich unter identity.sync.tokenserver.uri den URL-Link http://192.168.178.150:5000/1.0/sync/1.5 eingetragen.

Die Einträge in die Datenbank tokenserver habe ich gemacht:

USE tokenserver;
INSERT INTO `services` (`id`, `service`, `pattern`) VALUES ('1', 'sync-1.5', '{node}/1.5/{uid}');
INSERT INTO `nodes` (`id`, `service`, `node`, `available`, `current_load`, `capacity`, `downed`, `backoff`) VALUES ('1', '1', 'http://192.168.178.150', '1', '0', '1', '0', '0');

Hatte schon überlegt mein Firefox-konto zu löschen und neu anzulegen.Scheinbar kann Firefox nicht auf http://192.168.178.150/1.5/4/info/collections zugreifen

Mir ist aufgefallen dass beim Auruf des Links http://192.168.178.150/1.5/4/info/collections dieser sich automatisch auf https ändert was natürlich nicht funktionieren kann.

 

[Adama]

Also wenn dein nodes-Eintrag so aussieht, dann hast du den Port vergessen. Der muss natürlich auch http://192.168.178.150:5000 lauten...

Das würde vermutlich auch den Sprung nach https erklären.

 

[Prince_LG]

an der Stelle hatte ich tatsächlich gepfuscht, die Portnummer fehlte !!! Hurra, jetzt funktioniert der Sync

1730846400032 Sync.Status DEBUG Status.service: success.status_ok => success.status_ok

Jetzt suche ich vergeblich in den Datenbanken das Ergebnis des Synclaufs.

 

[Adama]

Einen Verlauf findest du in der Datenbank nicht, nicht im Sinne eines Protokolls.

Es müsste sich aber in der syncstorage_rs größerer Inhalt in der Tabelle BSO finden. Dort liegen die synchronisierten Daten. Die kannst du aber nicht lesen, der Inhalt der Datenbank ist verschlüsselt...

Auch in den anderen Tabellen müsste sich jetzt Inhalt zeigen.

 

[Prince_LG]

Vielen Dank !
dachte mir dass die Daten in dieser Tabelle liegen.

Heute habe ich das Firefox-Add-on About Sync getestet.

https://github.com/mozilla-extensions/aboutsync

Dieses Add-on zeigt Informationen zum Sync-Konto an, einschließlich aller Serverdaten für das Konto. Es richtet sich in erster Linie an Sync-Entwickler oder fortgeschrittene Benutzer, die Einblicke in ihre Sync-Daten wünschen.
Nach der Installation gibt man about:sync in die Adressleiste ein und erhält eine Komplettübersicht der Daten.

Damit konnte ich zumindest die Anzahl der Datensätze in der Tabelle BSO erfolgreich überprüfen. Ich plane auch, die Daten von den Mozilla-Servern zu entfernen.

Im nächsten Schritt werde ich weiterhin versuchen, den Sync-Server auf https umzustellen. Als Proxy nutze ich den HAPROXY auf einer OPNSense. Bin mir noch nicht im Klaren wie ich den virtuellen Host auf dem Sync-Server anlege.

 

[Adama]

Das kannte ich noch gar nicht...

Ich lass meinen Sync-Server über einen nginx-Reverse-Proxy mit SSL laufen. Einen virtuellen Host braucht es da nicht.

Das müsste eigentlich auch mit HAProxy gehen, jedenfalls mache ich ähnliches darüber mit LDAPS.

Hab es grad mal mit haproxy getestet, geht ohne Virtual Host. Die schnell zusammen geschusterte Konfiguration:

frontend sync-frontend
    bind *:55555 ssl crt <path to certificate>
    mode tcp
    default_backend sync-backend

backend sync-backend
    mode tcp
    server sync <docker container ip>:<docker container port> check fall 1 rise 2 inter 5s

 

[Prince_LG]

Danke für Deine Mühe, funktioniert so leider nicht. Meine Konfiguration des HAPROXY ist folgende:

# Frontend: service_https ( Öffentlichen Dienst / Server der alle externen Anfragen auf Port 443 entgegenimmt)
frontend service_https
http-response set-header Strict-Transport-Security "max-age=15768000; includeSubDomains"
bind 0.0.0.0:443 name 0.0.0.0:443 ssl prefer-client-ciphers ssl-min-ver TLSv1.2 ciphers

# Backend: pool_FFSync (FFSync Backend-Pool)
backend pool_FFSync
# health checking is DISABLED
mode http
balance source
# stickiness
stick-table type ip size 50k expire 30m
stick on src
http-reuse safe
server FFSync 192.168.178.150:5000


Normalerweise nimmt der jeweilige Webserver (Apache/nginx oder ähnliches) diese Anfragen an. Wo dast Du den nginx-Reverse-Proxy installiert, auf dem Host des Sync-Servers?

Wenn ich bei dieser Konfiguration den Link https://mein.server.de anklicke lande ich auf folgender Seite:

https://mozilla-services.readthedocs.io/en/latest/storage/apis-1.5.html

Der Sync schlägt fehl weil er den Tokenserver nicht findet.

 

[eddie irvine]

@Prince_LG
Diese Weiterleitung habe ich auch, wenn ich die Root (Sub-)Domain angebe.
Du musst https://mein.server.de/1.0/token/1.5 eingeben.

Da sollte dann eine JSON Response mit 'Unauthorized' kommen.

 

[Adama]

@Prince_LG Das ist normal, nur wenn du den Heartbeat nutzt, bekommst du Rückmeldung, ob es richtig arbeitet...

Der Reverse-Proxy läuft auf einem Raspi. Es sollte aber genauso über den von der Syno gehen...

 

[eddie irvine]

Was ist denn jetzt eigentlich die aktuellste Version, auf die man updaten kann?
Bin noch bei 0.13.7 und die läuft ja weiterhin stabil.

 

[Adama]

0.13.7 ist die letzte mit einem MySQL/MariaDB-fähigen Image, alle Versionen danach setzen standardmässig auf Spanner.

Aktuell ist der Sync-Server bei 0.17.13.

Für diese Versionen musst du das Image selber erstellen, siehe Start-Post.

 

[eddie irvine]

Ok, danke!
Das bedeutet dann aber, dass ich die alten Daten nicht weiter verwenden kann, oder?

 

[Adama]

Doch, das sollte gehen, die Daten sind ja in der Datenbank...

Aber selbst das wäre egal, du synchronisierst einfach deinen Firefox wieder in die DB.