Von Null auf Witness, Teil 2: Seed Node installieren und starten
So, weiter geht's! Nachdem wir die Vorbereitungen abgeschlossen haben, kommen wir jetzt zum interessanteren Teil.
Kleine Warnung vorher, wir brauchen jetzt vor allem eins: Geduld! Der Download brauchte bei mir ca. 5 Stunden, entpacken kann ich nicht so genau sagen, nach 3 Stunden war es jedenfalls erledigt, Synchronisieren brauchte etwa 12 Stunden. Das erscheint mir ziemlich viel, evtl. ist der Standort Düsseldorf nicht optimal oder der VPS hat zu wenig auf dem Kasten. Vielleicht kann mir jemand sagen, wie lange der Sync normalerweise dauert?
Wichtiger Hinweis zur Schreibweise:
Leider zerstören breitere Codeblöcke die Formatierung einer Seite am Smartphone, Text wird abgeschnitten und Kommentare sind ebenfalls nur noch schwer lesbar. Daher werde ich in diesem Beitrag Befehle als Zitat formatieren. Wichtig dabei ist, ein Zitat ist immer ein Befehl auch wenn dieser auf mehrere Zeilen umgebrochen wird:
command 1 long long long long long long long long long long long long long long long long very long command 1
command 2
Ich halte mich bis auf ein paar Abwandlungen an die Anweisungen von Part 5, Part6 und Part 7 von @rexthetech. Er hat seinen Server witnessnode genannt, ich spare mir gleich sagenhafte 4 Buchstaben und nenne meinen schlicht witness. Dazu am VPS einloggen und dort:
sudo hostnamectl set-hostname witness
Kurz ausloggen und wieder einloggen, dann wird die Änderung sichtbar:
Jetzt heißt unser VPS witness, am PC in der Host-Tabelle und bei den SSH-Schlüsseln ebenfalls, so behält man einen besseren Überblick falls es mal a bissal mehr sein darf. Das sind so Kleinigkeiten an denen ich zu erkennen glaube, @rexthetech macht das nicht zum ersten Mal :-)
So, jetzt packen wir aber an und starten den Download. Ups, halt. Docker und Screen sind noch nicht auf unserem System, die installieren wir noch vorher.
Docker und Screen installieren
sudo apt update
sudo apt install docker.io screen
Damit User steem Docker verwenden kann:
sudo usermod -aG docker steem
Screen basic's
Dank Screen ist es möglich, sich vom VPS abzumelden ohne einen laufenden Prozess zu beenden. Sehr nützlich, denn so können wir während Download, Entpacken, Sync die Verbindung zum VPS trennen und unseren PC ausschalten.
Wichtige Befehle:
screenneuen Screen erzeugenscreen -rvorhandenen Screen aufrufen- Strg+A danach Strg+D vom Screen zum vorigen Terminal wechseln ohne diesen zu beenden. Ein Screen bleibt so lange aktiv, bis man diesen mit
exitbeendet. screen -lsListe der aktiven Screensscreen -helpHilfe
Diese Grafik soll die Funktionsweise verdeutlichen:
Für alle die Screen nicht kennen, ein kurzer Probelauf:
Mit screen und 2x Enter einen Screen öffnen. Hmm, sieht aus, als ob nichts passiert wäre. Tippen wir jetzt screen -X caption always ein - und siehe da...
...am unteren Fensterrand erscheint 0 bash - wir befinden uns also in einer aktiven Screen-Sitzung. Fügen wir mit ls -la noch etwas mehr Text hinzu.
Mit Strg-A und Strg-D wechseln wir zurück in unser "normales" Terminal.
Jetzt loggen wir uns aus und wieder ein. Mit screen -r gelangen wir wieder zu unserer vorigen Screen-Sitzung.
Wer öfter mit Screen arbeitet, möchte vielleicht auf den ersten Blick sehen ob er sich in einer Sitzung befindet. Um nicht immer wieder screen -X caption always eintippen zu müssen, kann dies dauerhaft eingerichtet werden. Dies ist mittels der Datei~/.screenrc möglich, wer mag kann folgende Einträge vornehmen:
sudo nano ~/.screenrc
Darin fügen wir diese drei Zeilen ein:
# Konfiguration fuer screen
startup_message off # Keine Willkommensnachricht
caption always "%{rw} [%n %t] %{bw} %= | $LOGNAME@%H | %d.%m.%y %c "
So, jetzt wird es aber Zeit! Genug mit screen, legen wir endlich los...
Download der Chain
Zuerst mit screen -ls nachsehen ob Screens aktiv sind, falls ja, diese schließen und mit screen eine neue Sitzung starten. Vielleicht hast du, so wie ich gerade, eine Sitzung aktiv, dann passt das natürlich auch.
Beim Steem Backup Data Server nachsehen, welcher Download aktuell ist.
Mit Rechtsklick auf den Dateinamen die Link-Adresse kopieren und beim wget-Befehl einsetzen:
wget https://files.steem.fans/s3/steem_witness_20220805.tar.lz4
Dann heißt es däumchendrehen oder ein Nickerchen machen, bei mir dauerte der Download knapp 5 Stunden. Keine Sorge, der Download läuft sicher in Screen, wir können mit Strg+A und Strg-D ins SSH-Terminal wechseln und die SSH-Verbindung schließen.
Chain entpacken
Jetzt wird es spannend, nach Login wechseln wir wieder mit screen -r zur Screen-Sitzung. Wenn alles geklappt hat, sieht es hoffentlich so aus:
Jetzt können wir die Ordner für die Blockchaindaten anlegen:
sudo mkdir /steemdata
sudo mkdir /steemdata/blockchain
User steem als Eigentümer von /steemdata festlegen:
sudo chown steem:steem -R /steemdata
Um einen Fortschrittsbalken beim Entpacken zu sehen, installieren wir pv:
sudo apt install pv
Zum Entpacken brauchen wir den Dateinamen des Archivs, bei mir war es die Datei steem_witness_20220805.tar.lz4. Mit ls -lh kannst du nachsehen, welche Datei bei dir gelandet ist und den Befehl unten entsprechend anpassen:
sudo pv steem_witness_20220805.tar.lz4 | lz4 -dc - | tar -xv -C /steemdata
Wie eingangs erwähnt, der Befehl oben ist ein Befehl, so sieht es im Terminal aus:
So, Zeit für eine 2te lange Pause! Bei mir wurden zuerst 5 Stunden angezeigt, so habe ich nach 3 Stunden einen Blick gewagt - und ja, alles paletti.
So sieht es nach dem Download und mit entpackter Chain aus:
Nachdem das Archiv erfolgreich entpackt wurde, schicken wir es ins Nirvana:
rm steem_witness_20220805.tar.lz4
Sieht schon besser aus:
Node starten
Jetzt holen wir uns die config_witness.ini
wget https://gist.githubusercontent.com/ety001/42aee2d6f32be4baaf55a6f45efd87a9/raw/dce400d1626ed6097ef1646256b4c7f7ed69f3c6/config_witness.ini
Und verschieben diese nach /steemdata:
mv config_witness.ini /steemdata/config.ini
Puh, lang hat's gedauert, aber jetzt ist es soweit, wir können unserem Baby endlich das Laufen lernen. Also los...
Halt - eine letzte kurze und wichtige Sache: Snapshoot! Sicherheitshalber solltest du jetzt einen Snapshoot anlegen. Falls der Sync nicht durchläuft, kannst du ratz fatz den jetzigen Zustand wieder herstellen.
Nun aber wirklich, los... Mit dem folgenden Befehl starten wir die Synchronisierung:
docker run -itd --name witness -p 2001:2001 -v /steemdata:/steem ety001/steem-mira:0.23.1 steemd --data-dir=/steem
So sollte es aussehen:
Steem läuft jetzt im Hintergrund in einem Docker Container. Um zu sehen was passiert:
docker logs -f witness
Der Befehl zeigt uns das komplette Logbuch an, um z.B. nur die letzen 50 Einträge zu sehen nimmt man: docker logs -f --tail 50 witness. Am Beginn steht: STARTING STEEM NETWORK - das ist schon mal ein gutes Zeichen.
Oh, ziemlich viel rot? Keine Sorge, lass den VPS jetzt ungestört seine Arbeit machen. Solange zwischendurch in weißer Schrift die Meldung "Syncing Blockchain --- Got block" kommt, ist alles in Ordnung. Den aktuellen Block findest du hier, so kannst du sehen, wie weit der Weg noch ist.
Mit etwas Glück siehst du in 12 Stunden (je nach Stand des Archivs und Leistung des VPS) diese Ausgabe:
Alle 3 Sekunden kommt ein neuer Block...
Du bist mit der Chain jetzt sychron!
Die Ausgabe des Logbuchs lässt sich jederzeit mit Strg+C stoppen. Dies stoppt nur die Anzeige des Logbuchs, die Chain läuft im Docker Container gemütlich weiter.
Mit top kann die Auslastung angezeigt werden:
CPU liegt zwischen 3-20%, die Chain schnurrt schön brav vor sich hin.
Snapshoot
Diesen Stand wollen wir in einem Snapshoot (Kundenaccount bei Contabo) festhalten. Ich bin hier vielleicht zu vorsichtig, vor einem Snapshoot stoppe ich immer die Chain und mache dann den Snapshoot. Bei der Gelegenheit evtl. nachher noch ein Systemupdate inkl. Neustart.
Node stoppen
docker network disconnect bridge witness
docker stop -t 600 witness
Node wieder starten
docker network connect bridge witness
docker start witness
Geschafft!
Dies waren Part 5, Part 6 und Part 7 aus @rexthetech's Anleitung. Das eigentliche Einrichten, auch wenn es vielleicht nicht so aussieht, war nicht so wild, im Vergleich zum Aufwand für diesen Post ein Klacks ;-)
Von hier aus zum Witness ist es nur noch ein Katzensprung! Ich gönne euch und mir jetzt erstmal eine Pause...
Ja in der Tat etwas Geduld sollte Mann haben aber wie ich angefangen habe zu experimentieren hatte ich keins habe mich sinnlos selber verrückt gemacht :)
Ohjee ganze Woche mit block_log Data, habe es ausprobiert, mit steem-docker-ex.
Steem-Docker von someguy mit dem eigenen Image< der hört auf ab 2019 zu synchronisieren und macht nur Fehlermeldungen
Danke für diese großartige Anleitung, es ist mühsam und zeitraubend gleich. Diese Anleitung von dir werde ich 1:1 aus interessehalber nach machen, weil ich bis jetzt meistens mit steem-docker experimentiert habe und screen habe ich nur bei jussi benutzt.
Kleiner Tipp: Habe gerade festgestellt, in der config.ini stehen Seednodes drin die nicht funktionieren. Ich empfehle dir, bevor du
docker runausführst, die config (/steemdata/config.ini) zu editieren und nur noch Seednodes die funktionieren und gute Zeiten liefern stehen zu lassen - den Rest auskommentieren.Weniger ist oft mehr, habe gerade einen Testsync laufen bei dem nur noch diese 4 eingetragen sind:
p2p-seed-node = seed.justyy.com:2001
p2p-seed-node = seed.steem.fans:2001
p2p-seed-node = seed.symbionts.io:2001
p2p-seed-node = seed.steemworld.org:2001
läuft viel "geschmeidiger" als beim ersten Sync mit unveränderter config.
EDIT: Sync läuft jetzt eine Stunde und steht bei Block 66900000, das sind rund 350k Blöcke pro Stunde. Wenn "das Baby" so weitermacht, braucht der Sync diesmal insgesamt nur 4 statt 12 Stunden.
Vielen Dank @weisser-rabe :))
Oh, da bin ich gespannt, vielleicht sagst mir dann kurz wie es dir ergangen ist?
Ganz genau! Deswegen noch einmal dicken Dank für diese Anleitung, und dass du dir die Zeit dafür genommen hast! Ich weiß, wie viel Aufwand es ist, die Screenshots zu machen und für einen Post aufzubereiten.
Sehr gut gefallen hat mir auch der Ausflug zu screen. Das praktische Tool kannte ich bisher nicht. Aber jetzt.... :-))
Fängt dann nach dem Restart der Knoten mit der Sync der "fehlenden" Blöcke an? Irgendwie muss er die ja wieder aufholen..
Ich war jetzt bei rex's Anleitung noch nicht so weit mit dem Durchackern, aber die Zeugenanmeldung zur eigenen Produktion von Blöcken ist damit noch nicht erfolgt, oder? Dafür sind noch weitere Aktivitäten erforderlich.
Genau! Und das geht auch schnell, weil nur die während der Auszeit verpassten Blöcke fehlen.
Wenn der Server als Witness läuft sieht es etwas anders aus, da würde man die zu signierenden Blöcke während der Downtime verpassen. Drum haben Top20 Witness normalerweise auch 2 Server laufen.
Richtig, das "Ding" nennt sich jetzt Seed Node.
Und ich grübelte bis vor Kurzem noch was eine Seed Node ist :-) Herrlich, da hab ich so ein Ding und wusste gar nicht wie es heißt und ob es Weiblein oder Männlein ist. Erste Frage hat sich geklärt, aber ob es ein Seed Node oder eine Seed Node ist steht noch offen.
Dafür kann man doch den Nullkey eintragen. Dann wird der Witness nicht mehr "beteiligt" und verpasst auch nichts.
das spielt ja glücklicherweise selbst im virtuellen Leben keine Rolle... :-)
Irgendwie hatte ich mit Seed Node immer einen "Verteilknoten" verstanden. Ist das so? Und wenn ja, was wird verteilt... und wozu ist der Port 2001 offen? Man kann ja die Geschwindigkeit mit steemworld prüfen, aber wann und wofür ist das von Bedeutung? Fragen über Fragen... zu gegebener Zeit werde ich dazu mehr recherchieren...
Hmm, ja stimmt. Außerhalb der Top20 sind die zeitlichen Abstände aber groß genug. Wenn z.B. alle 30 Min. ein Block für dich kommt, wäre genug Zeit für ein Systemupdate oder so... Würd wg. vielleicht 10 Min. keinen Nullkey senden.
Ja, seh ich auch so. Meiner Theorie nach verteilt und empfängt jeder Seed- und auch Witness-Server die Daten der Blöcke. Einziger Unterschied zwischen beiden, der Witness signiert, der Seed nicht.
Port 2001 muss offen sein weil die sich die Nodes über diesen Port verbinden.
Schnelle Nodes sorgen wohl unter anderem für einen schnelleren Sync oder bei den Fullnodes (RPC-Node ist das Gleiche?) für schnelle Antworten auf API-Anfragen.
Nebenbei, manchmal ist Steem ne echte Schlaftablette obwohl unter ecosynthesizer.com/steem/nodes gute Reaktionszeiten angezeigt werden, aktuell wäre z.B. der von Justyy oder von Chiller optimal. Ich vermute daher, beim Frontend gibt es keinen automatischen Wechsel zum schnellsten RPC, sondern es läuft standardmäßig über den von Steemit Inc.
Stimmt schon... wenn alles glatt läuft ;-)
Irgendwo hatte ich dazu mal einen killswitch gesehen, mit dem könnte man dann ganz schnell "abschalten".
Ich habe mir das nicht angeschaut, aber ich denke auch, dass steemit.com nur über die eigenen Server läuft. Ich könnte mir aber vorstellen, dass der Jussi-Server Anfragen auf verschiedene Nodes verteilt (harmloses Halbwissen ;-) ).
Now...you are on the road to a great achievement.
I am glad the toturial from rexthetech, is serving you right on this Journey.
I believe with your knowladge on programming , you will get this right and we can wait to see a another New witness from Geemany 😊.
I can't promise i will try this.., because i do not have all it takes to reach that last part ,i guess..., but i can promise you.., i will also follow this your setting steps.
Success...!
Spannend. Weitgehend böhmische Dörfer, aber spannend: Das scheint mir der Endspurt zu sein - ich lauere auf den Zieleinlauf ;-))
:-))
Danke @weisser-rabe, für dich einen guten Endspurt mit SC09.
This post has been featured in the latest edition of Witness Weekly...
Great job again. I can confirm that download and sync times are similar to what I've seen; probably the limiting factor on the download is the bandwidth at @ety001's file server.
Huge thanks for the tip about using quotes instead of code blocks when showing commands!
How long did the sync take for you? For me the first sync with the unchanged config.ini took 12 hours, and with reduced seednode entries only 4 hours.