Storj - Speicher vermieten

[Frieseba]

Also gerade in den letzten 24 Std hat sich der Wert fast verdoppelt. Aber mei...Bei den Beträgen, die ich nun nach 2 Monaten dort angesammelt habe, reicht es gerade für eine Kugel Eis. Immerhin.

 

[luddi]

Du hast aber schon das neue v0.34.6?

Wo kann man denn die verwendete Version einsehen?

--luddi

 

[Frieseba]

Auf deiner Seite dyndns:14002

 

[luddi]

Okay danke.

Ich bin eben noch nicht soweit. D.h. mein node läuft noch nicht. Ich warte immer noch auf den auth token.
Ich dachte man kann die version infos auch aus dem docker image einsehen.

Weil der TAG lautet ja aktuell nur beta.

root@myDS:~# docker images -a
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
storjlabs/storagenode   beta                a409accd7f0c        2 weeks ago         29.8MB

--luddi

 

[Frieseba]

Wenn es läuft, dann siehst du es über den angegebenen Port. Ja seltsam, warte auch nun 3 Wochen auf nen weiteren Token und es kommt nix.

 

[luddi]

Das verstehe ich ja dass man die Versionsinfo auf dem Web Dashboard des nodes sehen kann. Aber dazu muss der node zunächst einmal laufen.
Und ich suche nach einer Möglichkeit die Information des docker images auszulesen ohne einen laufenden container des images.

Okay dann wird´s wohl noch etwas dauern. Bei mir ist es jetzt gerade einmal 2 Wochen her als ich den auth token beantragt hatte.

--luddi

 

[Frieseba]

sudo docker stop -t 300 storagenode
sudo docker rm storagenode
sudo docker pull storjlabs/storagenode:beta

Beim letzten Befehl siehst du ja, ob er ein neues Image zieht.

 

[luddi]

Beim letzten Befehl siehst du ja, ob er ein neues Image zieht.

Das verstehe ich ja soweit. Nur war mein Ansatz eben die Version herauszufinden. Und selbst bei einem pull befehl sieht man keinerlei Informationen diesbezüglich in der Konsole.

Dann stelle ich die Frage noch einmal präziser:
Gibt es eine Möglichkeit die Version eines vorhandenen docker images, in diesem speziellen Fall eines storj images herauszufinden ohne dass der node jemals gestartet wurde?
Der TAG des storjnode images trägt nur den Namen "beta".

--luddi

 

[Frieseba]

Da das Thema im Storj-Forum gerade besprochen wurde: deaktivier mal alle Werbeblocker. Bei mir war es tatsächlich pi-hole. Nachdem ich das deaktiviert hatte und mich für ein weiteres Node angemeldet hatte, erhielt ich innerhalb von ca 10 Min meine Mail

 

[luddi]

Besten Dank für die Info @Frieseba

Ich habe Firefox verwendet wobei ich an diesem nicht explizit ein Ad-blocker am laufen habe. Auch kein Pi-hole im Netzwerk. Nachdem ich den Request nochmals mit dem Chrome Browser gestartet hatte war der auth token auch bei mir innerhalb von 10 min da.

Jetzt habe ich noch ein kleines Problem. Wenn ich die Firewall an der Syno deaktiviere bekomme ich es zum laufen.
Das einzige Problem welches ich mit aktiver Firewall habe ist folgendes:

a.) WARN trust Failed to fetch URLs from source
b.) ERROR preflight:localtime unable to get satellite system time

Siehe log...

Wobei die IP Adresse 10.88.66.1 mein Gateway und auch DNS Server ist welcher die DNS Anfrage an den DNS vom ISP weiterreicht.
Firewall sind incomming Ports für 28967 TCP erlaubt.

WARN	trust	Failed to fetch URLs from source; used cache	{"source": "https://tardigrade.io/trusted-satellites", "error": "HTTP source: Get https://tardigrade.io/trusted-satellites: dial tcp: lookup tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:52775->10.88.66.1:53: i/o timeout", "errorVerbose": "HTTP source: Get https://tardigrade.io/trusted-satellites: dial tcp: lookup tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:52775->10.88.66.1:53: i/o timeout\n\tstorj.io/storj/storagenode/trust.(*HTTPSource).FetchEntries:63\n\tstorj.io/storj/storagenode/trust.(*List).fetchEntries:90\n\tstorj.io/storj/storagenode/trust.(*List).FetchURLs:49\n\tstorj.io/storj/storagenode/trust.(*Pool).fetchURLs:240\n\tstorj.io/storj/storagenode/trust.(*Pool).Refresh:177\n\tstorj.io/storj/storagenode.(*Peer).Run:619\n\tmain.cmdRun:208\n\tstorj.io/storj/pkg/process.cleanup.func1.2:312\n\tstorj.io/storj/pkg/process.cleanup.func1:330\n\tgithub.com/spf13/cobra.(*Command).execute:826\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:914\n\tgithub.com/spf13/cobra.(*Command).Execute:864\n\tstorj.io/storj/pkg/process.ExecWithCustomConfig:84\n\tstorj.io/storj/pkg/process.ExecCustomDebug:66\n\tmain.main:328\n\truntime.main:203"}

INFO	preflight:localtime	start checking local system clock with trusted satellites' system clock.

ERROR	preflight:localtime	unable to get satellite system time	{"Satellite ID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE", "error": "rpccompat: dial tcp: lookup saltlake.tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:40479->10.88.66.1:53: i/o timeout", "errorVerbose": "rpccompat: dial tcp: lookup saltlake.tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:40479->10.88.66.1:53: i/o timeout\n\tstorj.io/common/rpc.Dialer.dialTransport:256\n\tstorj.io/common/rpc.Dialer.dial:233\n\tstorj.io/common/rpc.Dialer.DialAddressID:152\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).getSatelliteTime:110\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).Check.func1:67\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}

ERROR	preflight:localtime	unable to get satellite system time	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "error": "rpccompat: dial tcp: lookup europe-west-1.tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:41927->10.88.66.1:53: i/o timeout", "errorVerbose": "rpccompat: dial tcp: lookup europe-west-1.tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:41927->10.88.66.1:53: i/o timeout\n\tstorj.io/common/rpc.Dialer.dialTransport:256\n\tstorj.io/common/rpc.Dialer.dial:233\n\tstorj.io/common/rpc.Dialer.DialAddressID:152\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).getSatelliteTime:110\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).Check.func1:67\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}

ERROR	preflight:localtime	unable to get satellite system time	{"Satellite ID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6", "error": "rpccompat: dial tcp: lookup asia-east-1.tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:36808->10.88.66.1:53: i/o timeout", "errorVerbose": "rpccompat: dial tcp: lookup asia-east-1.tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:36808->10.88.66.1:53: i/o timeout\n\tstorj.io/common/rpc.Dialer.dialTransport:256\n\tstorj.io/common/rpc.Dialer.dial:233\n\tstorj.io/common/rpc.Dialer.DialAddressID:152\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).getSatelliteTime:110\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).Check.func1:67\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}

ERROR	preflight:localtime	unable to get satellite system time	{"Satellite ID": "118UWpMCHzs6CvSgWd9BfFVjw5K9pZbJjkfZJexMtSkmKxvvAW", "error": "rpccompat: dial tcp: lookup satellite.stefan-benten.de on 10.88.66.1:53: read udp 172.17.0.2:58546->10.88.66.1:53: i/o timeout", "errorVerbose": "rpccompat: dial tcp: lookup satellite.stefan-benten.de on 10.88.66.1:53: read udp 172.17.0.2:58546->10.88.66.1:53: i/o timeout\n\tstorj.io/common/rpc.Dialer.dialTransport:256\n\tstorj.io/common/rpc.Dialer.dial:233\n\tstorj.io/common/rpc.Dialer.DialAddressID:152\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).getSatelliteTime:110\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).Check.func1:67\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}

ERROR	preflight:localtime	unable to get satellite system time	{"Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "error": "rpccompat: dial tcp: lookup us-central-1.tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:52268->10.88.66.1:53: i/o timeout", "errorVerbose": "rpccompat: dial tcp: lookup us-central-1.tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:52268->10.88.66.1:53: i/o timeout\n\tstorj.io/common/rpc.Dialer.dialTransport:256\n\tstorj.io/common/rpc.Dialer.dial:233\n\tstorj.io/common/rpc.Dialer.DialAddressID:152\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).getSatelliteTime:110\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).Check.func1:67\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}

FATAL	failed preflight check	{"error": "system clock is out of sync: system clock is out of sync with all trusted satellites", "errorVerbose": "system clock is out of sync: system clock is out of sync with all trusted satellites\n\tstorj.io/storj/storagenode/preflight.(*LocalTime).Check:96\n\tstorj.io/storj/storagenode.(*Peer).Run:623\n\tmain.cmdRun:208\n\tstorj.io/storj/pkg/process.cleanup.func1.2:312\n\tstorj.io/storj/pkg/process.cleanup.func1:330\n\tgithub.com/spf13/cobra.(*Command).execute:826\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:914\n\tgithub.com/spf13/cobra.(*Command).Execute:864\n\tstorj.io/storj/pkg/process.ExecWithCustomConfig:84\n\tstorj.io/storj/pkg/process.ExecCustomDebug:66\n\tmain.main:328\n\truntime.main:203"}

--luddi

 

[luddi]

Nach ein wenig "Trial and error" bin ich dem Ganzen nun auf die Schliche gekommen.

Ich habe von allen verfügbaren Satelliten die IP Adresse in der Firewall für das Protokol UDP und jeweils den Portbereich 1024-65535 erlaubt.

Die IP-Adressen lauten wie folgt...

Domain                            IP-Address        \
------------------------------+---------------------+
tardigrade.io                 |   104.198.14.52     |
saltlake.tardigrade.io        |   35.236.124.230    |
europe-west-1.tardigrade.io   |   35.205.31.184     |
asia-east-1.tardigrade.io     |   34.80.94.151      |
satellite.stefan-benten.de    |   78.94.240.189     |
us-central-1.tardigrade.io    |   35.184.17.243     |
------------------------------+---------------------+

In der Firewall sieht das ganze dann entsprechend so aus...



Damit startet der docker Container sauber und läuft brav ohne warnings und ohne errors.



Wie aus dem Protokoll zu entnehmen ist, gehe ich davon aus, dass der Docker eine Anfrage startet und der Server auf einem random Port, welcher zwischen beiden ausgehandelt wurde, kommunizieren möchte. In diesem Beispiel wäre das der Port 52775.
{"source": "https://tardigrade.io/trusted-satellites", "error": "HTTP source: Get https://tardigrade.io/trusted-satellites: dial tcp: lookup tardigrade.io on 10.88.66.1:53: read udp 172.17.0.2:52775->10.88.66.1:53: i/o timeout"

So ganz bis ins Detail verstehe ich die Kommunikation zwar noch nicht weil mir das Protokoll nicht eindeutig erscheint. Leider habe ich in der Firewall der Diskstation auch keinen log gefunden.
Weiß evtl. jemand von euch ob es einen trace log der Firewall gibt die exakt zeigt welche Regel was blockiert hat?

--luddi

 

[kev.lin]

Hallo zusammen,

ich bin daran gescheitert, storj auf eine andere DiskStation zu verschieben. Vielleicht könnt ihr mir helfen und mir sagen, was ich falsch gemacht habe.
Was ich gemacht habe:

• storj-Docker-Container angehalten
• storj-Docker-Container-Verzeichnis auf neue DiskStation kopiert - liegt auf beiden DiskStations unter "/volume1/docker/storj-docker" und beinhaltet neben dem docker-compose-file auch den Ordner mit den "identity-Dateien"
• Daten-Verzeichnis auf neue DiskStation kopiert (sind viele kleine Dateien - bei 1TB dauert das etwas...) - auf der alten DiskStation liegen diese unter "/volume2/temp/storj" auf der neuen DiskStation liegen diese unter "/volume2/storj"
• das "docker-compose.yml" angepasst auf den neuen Datenpfad der neuen DiskStation
• in der FritzBox die Portfreigabe für storj auf die neue DiskStation umgelenkt
• den Docker-Container mittel docker-compose gestartet (image: storjlabs/storagenode:beta)

Dann passiert folgendes: Der Container startet, wird aber nach kurzer Zeit wieder beendet. Da das docker-compose.yml den Zusatz restart: unless-stopped enthält, wiederholt sich dies nun immer wieder.
Im Log des Containers kann ich folgende Fehlermeldung finden:

Error: Error creating tables for master database on storagenode: migrate: no such table: satellites

Auf der alten DiskStation gibt es unter "/volume2/temp/storj/storage" eine "satellites.db-shm", die scheinbar aber nur zur Laufzeit existiert. Dem entsprechend habe ich diese nicht mit auf die neue DiskStation kopiert.

Nun ist meine Frage: Was hat es sich mit der Datenbank auf sich? Muss man die irgendwie zur Laufzeit sichern und auf die neue DiskStation kopieren?

 

[maalik]

@luddi: Sehe ich das richtig, dass du den gesamten Portbereich 1024 bis 65535 freigegeben hast? 1024 + 65535 müsste doch reichen?

 

[luddi]

@maalik: Ja genau, ich habe den gesamten Portbereich von 1024 bis 65535 freigegeben. Warum sollte aus deiner Sicht nur 1024 & 65535 ausreichen?
Ich denke dass die Kommunikationsports zwischen Client und Server per random gewählt bzw. ausgehandelt werden.
Wenn du einen Blick in meinen Auszug aus dem Protokoll wirfst siehst du, dass versucht wird auf den unterschiedlichesten Ports zu kommunizieren.
Die da wären: 52775, 41927, 36808, 58546, 52268.

Diese liegen in dem Bereich der registrierten als auch in dem dynamischen Bereich des Standards. Ich glaube nicht dass es aureichen würde die Kommunikation auf nur 2 Ports zu beschränken.
Wie siehst du das?

--luddi

 

[maalik]

Äh ja, du hast recht. Ich war gedanklich woanders.

 

[kev.lin]

Hat keiner eine Idee, wie ich mein Problem beim Umziehen von einer DiskStation zur anderen lösen könnte?

 

[faxxe]

Vielleicht wissen die Schöpfer der Software näheres

https://documentation.storj.io/resources/faq

https://documentation.storj.io/resources/faq/migrate-my-node



-faxxe

 

[Heidi]

@ Kev.lin: Ich hatte meinen mal verschobe und es wie du gemacht. Du musst drauf achten, dass alle Pfadzuweisungen wieder passen (selbstverständlich). Ich habe aber nicht mit docker Compose gearbeitet und auch die yml datei ist bei mir irgendwie ohne funktion.. bei mir hatte das damals funktioniert.....

 

[Heidi]

Was ist denn da die letzten Tage los??

Knoten 1




Knoten 2 an völlig anderer Hardware und IP

 

[maalik]

Bei mir sieht es so aus. Habe es allerdings auf die (jetzt) volle Platte geschoben.