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

[Esel08]

@Adama

Hast Du im Passwort Sonderzeichen ? bzw. ein längeres Passwort glaube die setzen bei Mariadb10 eine bestimmte Länge vorraus.

 

[Adama]

Beides, Sonderzeichen und 60 Zeichwen lang...

 

[Adama]

Version 0.15.8 ist rausgekommen:
https://github.com/mozilla-services/syncstorage-rs/releases/tag/0.15.8

 

[Adama]

Version 0.16.0 ist verfügbar:
https://github.com/mozilla-services/syncstorage-rs/releases/tag/0.16.0

Also einfach die Version in der .env ändern und einen neuen Build anstossen...

 

[mabox]

Hi @Adama
so dann bich jetzt auch mal dran umzustellen auf die neue Version über das Image.... wieder mal Danke für Deine Vorarbeit.
Ich hänge jetzt aber gerade an der .env
Was muss den genau hier rein?

SYNC_URL=<URL of Sync Server>
PROXY_PORT=<Port of Sync Server>

Weil diese beiden Punkte gab es doch bei unserer alten Version, bis 13.7, nicht oder hab ich Tomaten auf den Augen?

 

[Adama]

@mabox SYNC_URL kommt aus dem compose-File, was die Basis für die Build-Geschichte bildet. Ich hab es nur in die .env verschoben und den Port extra gesetzt.

Bei "SYNC_URL" muss die URL rein, über die du den Syncserver ansprechen willst.
Bei "PROXY_PORT" der Port, den du dort nutzen willst.

Es ist übrigens inzwischen die 0.17.0 rausgekommen, also im .env-File die Versions-Nummer anpassen.
https://github.com/mozilla-services/syncstorage-rs/releases/tag/0.17.0

 

[mabox]

Ich tue mich schwer, ich hatte SYNC_URL bisher nicht und der Port hies bei mir "EXTERNAL_PORT".
Siehe Bild wie ich es bisher hatte, über Portainer..... ...

 

[Adama]

Wie gesagt, SYNC_URL muss die Adresse sein, mit der du den Syncserver ansprichst.

Das kann der Name oder die IP deiner Syno sein. Wenn du aber z.B. einen Reverse-Proxy nutzt, muss das die Adresse von dem sein.

EXTERNAL_PORT gibt es weiterhin, das ist der externe Port des Containers.

PROXY_PORT ist der Port des Reverse-Proxy, wenn due inen benutzt. Wenn nicht, muss das der selbe sein, wie EXTERNAL_PORT.

 

[mabox]

Ich würde es noch ein klein wenig besser verstehen was hier genau passiert. Hatte bisher noch nie ein image selber bauen müssen.
- Für den " compose build" Befehl ist es wichtig das die .env gepflegt ist richtig? Die Daten werden dann ins Image mit eingebaut? Die docker-compose.yml ist an dem Punkt noch nicht mit ihm Spiel oder?
- Die docker-compose.yml kommt ins Spiel wenn man dann den "compose up" Befehl ausführt? Dies könnte ggfl. auch über Portainer Stack erledigt werden.... Bräuchte es für den Befehl an der Stelle dann noch die .env Datei? Die Angaben sind ja schon ins Image verdrahtet oder?

 

[Adama]

Doch, die docker-compose.yml spielt eine Rolle beim Build. Die .env füllt nur die Variablen darin. Man könnte das alles auch direkt in der docker-compose.yml einpflegen.

Für das Image werden die Variablen nur für die entrypoint.sh und die Dockerfile gebraucht.

Das selbe gilt für das Starten des Containers. Ob du ein docker-compose up -d oder das über Portainer machst, es werden immer beide gebraucht.

Ich mach das über den Stack in Portainer:

 

[mabox]

OK also Du baust das Image in der Shell aber deployen wäre dann einfach ganz normal wie zuvor über Portainer möglich hab ich verstanden..... Sobald sich aber irgendeine Variable ändert muss man gleich das komplette Image neu bauen dann richtig?

Ich find mittlerweile die Abhängigkeit zu dem mariadb Container nicht mehr so schön. Macht es für mich einfach noch komplizierter glaub.....
Ganz ganz am Anfang hatten wir es ja Mal noch ohne MariaDB, Du erinnerst dich? Weiß nicht mehr welche DB das war aber war ja dann nur ein Datenbankfile. Hast Du in dem Konstrukt hier auch weitere DB Varianten gesehen gefunden im GitHub?

 

[Adama]

Ich denke, das kommt ein wenig auf die Variablen an. Grundsätzlich haben sich die bei mir bisher nicht geändert, nur die Version.

Und dem Fall muss das Image natürlich neu erzeugt werden.

Du meinst bei der alten Version (vor Rust) die sqlite-Datenbank. Letztlich ist das ja auch eine Datenbank, halt nur als Flatfile. Ich weiß nicht, ob das bei der Rust-Variante noch unterstützt wird. Sicher bin ich mir nur bei MySQL/MariaDB und Spanner.

Edit: Die Build-Umgebung des Images ist aber auch gechached in Docker, so dass nicht alles komplett neu erstellt werden muss.

 

[Adama]

Mozilla hat die Version 0.17.1 veröffentlicht:

Chore

    Updates for Jun-2024 (#1576) (1713962c)

Doc

    clarify the handling of existing expired bsos in writes (#1581) (250ac943, closes #619)

Bug Fixes

    don't hide TokenserverPool initialization errors on startup (#1584) (1edce041)

https://github.com/mozilla-services/syncstorage-rs/releases/tag/0.17.1

Der von mir beschriebene Weg über den Build des Images hat auch hier problemlos funktioniert. Also wie immer, Version in der ".env" anpassen und neu erstellen.

 

[mabox]

Hi @Adama
ich bin jetzt endlich mal dazugekommen und hab versucht auf die neue Version 17.1 umzustellen. Bin bisher immer noch auf der 13.7 gewesen.
Also soweit so gut hat erstmal alles geklappt. Image gebaut und dann auch über Portainer deployed usw.
Ein Test auf über https://url/__heartbeat__ passt erstmal:


Es gibt aber jetzt das Problem noch: https://url/1.0/sync/1.5


An was lag das den nochmal? Ich glaub ich hatte das mal aber weiß nicht mehr wie ich es gelöst hatte? Passt das Datenbankkennwort nicht?

 

[Adama]

@mabox Die zweite Meldung beruht darauf, dass da die Seite ohne Authentifizierung aufgerufen wird. Die Meldung ist also völlig ok.

Erst wenn du den Server in Firefox nutzt, erfolgt ja die Anmeldung übers Mozilla-Konto. Und dann sollte das auch funktionieren. Das kannst du dann mit den den beiden "Logon"-Parametern in "about:config" testen (siehe Anleitung unter 3a)

 

[mabox]

Ja stimmt ich erinnere mich aber ich denke dieses mal ist es ein anderes Problem. Denke ich mach es nochmal komplett von Null neu, auch Datenbank nochmal frisch...... bekomme keinen erfolgreichen Sync hin.
Hab es schon zigfach mit einer neuen Anmeldung versucht.

1720896019543    Sync.LogManager    DEBUG    Flushing file log
1720896019545    Sync.LogManager    DEBUG    Log cleanup threshold time: 1720032019545
1720896019547    Sync.LogManager    DEBUG    Done deleting files.
1720896020379    FirefoxAccounts    INFO    Polling device commands.
1720896020380    Sync.Service    DEBUG    User-Agent: Firefox/127.0.2-2 (Linux x86_64) FxSync/1.129.0.20240626231124.desktop
1720896020380    Sync.Service    INFO    Starting sync at 2024-07-13 20:40:20 in browser session UtfagY4nTwtJ
1720896020380    Sync.Service    DEBUG    In sync: should login.
1720896020380    Sync.Service    INFO    User logged in successfully - verifying login.
1720896020380    FirefoxAccounts    TRACE    not checking freshness of profile as it remains recent
1720896020381    Sync.SyncAuthManager    DEBUG    unlockAndVerifyAuthState already has (or can fetch) sync keys
1720896020381    Sync.Status    DEBUG    Status.login: error.login.reason.network => success.status_ok
1720896020381    Sync.Status    DEBUG    Status.service: error.login.failed => error.login.failed
1720896020381    Sync.Service    DEBUG    Fetching unlocked auth state returned success.status_ok
1720896020381    FirefoxAccounts    TRACE    not checking freshness of profile as it remains recent
1720896020381    Sync.Service    DEBUG    verifyLogin failed: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.port]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://services-crypto/utils.sys.mjs :: computeHAWK :: line 437"  data: no] Stack trace: computeHAWK()@resource://services-crypto/utils.sys.mjs:437
_getAuthenticationHeader()@resource://services-sync/sync_auth.sys.mjs:581
1720896020381    Sync.Status    DEBUG    Status.login: success.status_ok => error.login.reason.network
1720896020381    Sync.Status    DEBUG    Status.service: error.login.failed => error.login.failed
1720896020381    Sync.ErrorHandler    ERROR    Sync encountered a login error
1720896020381    Sync.SyncScheduler    DEBUG    Clearing sync triggers and the global score.
1720896020382    Sync.SyncScheduler    DEBUG    Next sync in 3600000 ms. (why=schedule)
1720896020382    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
1720896020382    Sync.Service    DEBUG    Not syncing: login returned false.
1720896020382    FirefoxAccounts    TRACE    not checking freshness of profile as it remains recent

 

[mabox]

Keine Chance, hab alles neu gemacht.
Meine Konstellation ist, ich hab einen Proxy Server der auf eine VM mit Docker weiterleitet.

Das hat sich nicht geändert, war auch bei der 13.7 schon so und hat einwandfrei funktioniert.
Für die 17.1 habe ich nun alle Parameter analog zur 13.7 übernommen, das Image gebaut und per Portainer gestartet.
Sieht erstmal alles gut aus, Heartbeat, siehe oben passt.

Die Datenbank läuft auch in einem Docker.
Bisher hatte ich als Datenbankserver IP die IP Adresse von der VM angegeben und den externen Port des syncstorage_rs Containers.
Das hab ich jetzt für die 17.1 übernommen. Im Log des Docker Containers kommt dann nichts an. Die Heartbeatseite passt zwar aber ich bekomme keine erfolgreiche Syncs hin.

Zum Test habe ich mal die Datenbank IP auf die 172 IP Adresse des Datenbank Containers gestellt, dann bekomme ich zumindest im syncstorage_rs Container Logeinträge, aber mit Fehler:

  11: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:284:13

      std::panicking::try::do_call

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40

      std::panicking::try

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19

      std::panic::catch_unwind

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14

      std::rt::lang_start_internal::{{closure}}

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:141:48

      std::panicking::try::do_call

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40

      std::panicking::try

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19

      std::panic::catch_unwind

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14

      std::rt::lang_start_internal

             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:141:20

  12: main

  13: <unknown>

  14: __libc_start_main

Auf der "Heartbeat" Testseite bekomme ich dann einen 502er Bad Gateway Fehler.
Ich hab jetzt mal wieder die IP geändert. Heartbeat passt wieder aber Sync klappen nicht. Im Log vom syncstorage_rs Container kommt nichts an und beim Sync gibts den Error wie in meinem vorigen Beitrag beschrieben.
Überlege gerade ob ich wieder zur 13.7. zurück gehe oder einfach den Standard Firefox Sync beim Mozilla benutze :-(

 

[Adama]

Keine Ahnung, warum das bei dir nicht geht...

Meine Konfiguration ist ja genauso aufgebaut:
MariaDB in Docker
FFSync in Docker
Reverse Proxy über nginx

Beide Container sind im selben Docker-Netz

Wenn der Heartbeat klappt, ist der Container eigentlich korrekt am arbeiten...

Wenn du im compose-File den Loglevel auf "info" stellst, dann solltest du auch Meldungen im Container-Log bekommen. Vielleicht taucht da noch was auf. Aber wenn der bei "warn" nichts zeigt, ist an sich alles in Ordnung.

 

[Adama]

@mabox Was mir noch so eingefallen ist: Du testest ja immer den ganzen Verbund, wenn ich das richtig sehe? Also Syncserver + Reverse Proxy?

Teste doch nur mal den Syncserver alleine. Nur um sicher zu gehen, dass dir da nichts anderes reingrützt.

 

[mabox]

Hi, ja ich teste immer komplett, also über die Proxy URL die ich ja auch in der .env angegeben habe. Wenn ich den URL Namen mit der IP tausche bekomme ich eine 404 Meldung. Ich habe gerade nochmal alles neu gemacht und auch mal ohne Portainer, also alles in der Shell. Hilft nichts, Heartbeat ist ok und auch wenn ich den Container starte werden die beiden Datenbanken gefüllt aber es bleibt am Ende wenn ich synce immer beim Login Error......
Na gut, ich versuche es die Tage nochmal komplett von Anfang an, Stück für Stück durchzugehen, falls es nicht klapp geh ich halt wieder zurück zum Original :-(