Hab nun schon seit einiger Zeit eine Mastodon Instanz auf einem VPS 200 G10s am laufen. Das läuft wunderbar und die Kosten halten sich dadurch auch in Grenzen.
Das längste Thema
- fLoo
- Thread is Unresolved
-
-
Hab ich das richtig verstanden? Die zusätzlichen Hops sind irgendwo in der Mitte des Traces? Nicht am Anfang? Also ich meine, an dem "Ende" des Traces, wo der Server ist?
ja hast Du
und so sieht es aus, einmal Standard
Code
Display More[root@transalpin ~]# traceroute6 -I 6in4gate.tunnel traceroute to 6in4gate.tunnel (2a0d:f302:101:x::1), 30 hops max, 80 byte packets 1 2a03:4000:f::3 (2a03:4000:f::3) 0.374 ms 0.468 ms 0.463 ms 2 2a00:11c0:47:3::20 (2a00:11c0:47:3::20) 3.123 ms 3.291 ms 3.283 ms 3 2a00:11c0:47:1:47::138 (2a00:11c0:47:1:47::138) 0.287 ms 0.329 ms 0.322 ms 4 2a00:11c0:47:1:47::136 (2a00:11c0:47:1:47::136) 9.178 ms 9.204 ms 9.198 ms 5 2a00:11c0:47:1:47::133 (2a00:11c0:47:1:47::133) 9.134 ms 9.296 ms 9.287 ms 6 vix.alwyzon.net (2001:7f8:30:0:2:1:4:994) 10.557 ms 9.197 ms 9.181 ms 7 2a0d:f302:8:11:: (2a0d:f302:8:11::) 15.730 ms 15.735 ms 15.728 ms 8 6in4gate.tunnel (2a0d:f302:101:x::1) 9.101 ms 9.074 ms 9.021 ms [root@transalpin ~]#
und einmal nachdem die 3 zusätlichen IPv6-Adresse des /64 mit /sbin/ip addr change prefix::... dev eth0 preferred_lft 0 geändert wurden
Code
Display More[root@transalpin ~]# traceroute6 -I 6in4gate.tunnel traceroute to 6in4gate.tunnel (2a0d:f302:101:x::1), 30 hops max, 80 byte packets 1 2a03:4000:f::3 (2a03:4000:f::3) 0.348 ms 0.251 ms 0.237 ms 2 2a00:11c0:47:3::20 (2a00:11c0:47:3::20) 0.376 ms 0.403 ms 0.393 ms 3 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141) 3.514 ms 3.510 ms 3.498 ms 4 2a00:11c0:47:1:47::148 (2a00:11c0:47:1:47::148) 3.821 ms 3.812 ms 3.825 ms 5 2a00:11c0:47:1:47::146 (2a00:11c0:47:1:47::146) 3.719 ms 3.755 ms 3.783 ms 6 2a00:11c0:47:1:47::151 (2a00:11c0:47:1:47::151) 14.709 ms 14.987 ms 14.936 ms 7 2a00:11c0:47:1:47::134 (2a00:11c0:47:1:47::134) 11.961 ms 12.144 ms 12.116 ms 8 vix.alwyzon.net (2001:7f8:30:0:2:1:4:994) 11.954 ms 12.048 ms 11.978 ms 9 2a0d:f302:8:11:: (2a0d:f302:8:11::) 18.381 ms 18.367 ms 18.349 ms 10 6in4gate.tunnel (2a0d:f302:101:x::1) 11.898 ms 11.858 ms 11.836 ms [root@transalpin ~]#
diese Änderung findet auf [transalpin] statt, der steht hier bei netcup ...
und sieht die andere Richtung aus ... (unabhängig von der erwähnten Änderung)
Code[root@6in4gate ~]# traceroute6 -I transalpin.host traceroute to transalpin.host (2a03:4000:f:x::1), 30 hops max, 80 byte packets 1 gw101.core1.vie.alwyzon.net (2a0d:f302:101::1) 11.202 ms 11.195 ms 11.190 ms 2 ae0.edge1.vie.alwyzon.net (2a0d:f302:8:11::1) 1.082 ms 1.103 ms 1.147 ms 3 et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (2001:7f8:30:0:1:1:4:7147) 0.462 ms 0.465 ms 0.462 ms 4 2a00:11c0:47:1:47::132 (2a00:11c0:47:1:47::132) 0.750 ms 0.749 ms 0.794 ms 5 2a00:11c0:47:1:47::137 (2a00:11c0:47:1:47::137) 9.170 ms 9.176 ms 9.174 ms 6 2a00:11c0:47:3::33 (2a00:11c0:47:3::33) 12.877 ms 12.506 ms 12.492 ms 7 transalpin.host (2a03:4000:f:x::1) 12.139 ms 11.969 ms 11.962 ms [root@6in4gate ~]#
-
@mainziman: Die Traces sehne mir eher danach aus, als würde da eine Lastverteilung an Hand verschiedener IP-Adressen vorgenommen werden.
Die Hops kannst du meines Wissens nicht wirklich beeinflussen. Es sei denn, du baust dir ein eigenes vLAN vom Netcup-Server zu einem Server bei einem Mitbewerber oder auch nach Hause auf. Denn dann hast du es selber in der Hand, über wie viele Hops dein Netcup-Server hoppeln muß, bis er in deinem vLAN auch das Ziel erreichen kann.
-
Hab nun schon seit einiger Zeit eine Mastodon Instanz auf einem VPS 200 G10s am laufen. Das läuft wunderbar und die Kosten halten sich dadurch auch in Grenzen.
Dir wird früher oder später garantiert der Speicherplatz (und womöglich RAM) ausgehen. Been there, done that…
Meine Mini-Instanz läuft auf einem VPS Karneval 2020 (2C/4G/160G) nun deutlich entspannter.
-
andreas. dem widerspricht folgendes:
habe ich nur eine IPv6-Adresse prefix::1, dann ist es das selbe wie wenn ich diese 4 IPv6-Adressen prefix::<1-4> hätte und bei den
zusätzlichen (2ndaries) folgende Änderung mache: /sbin/ip addr change prefix::... dev eth0 preferred_lft 0;
ausgehend wird immer prefix::1 verwendet, aber in einem Fall das traceroute6 mit den 8 Hops oben und im anderen Fall aber der mit 10 Hops;
-
Dir wird früher oder später garantiert der Speicherplatz (und womöglich RAM) ausgehen. Been there, done that…
Ich speichere auf Backblazien daher macht Speicher kein Problem (Kostenalarme hab ich an).
Traffic geht über Cloudflare, daher spar ich mir wertvolle Requests.
Ob RAM Probleme macht kann ich noch nicht beurteilen, aber die Instanz ist privat, daher sollte das klappen.
-
Ich speichere auf Backblazien daher macht Speicher kein Problem (Kostenalarme hab ich an).
Wird der lokale Mediencache dann auch dort abgelegt?
Ob RAM Probleme macht kann ich noch nicht beurteilen, aber die Instanz ist privat, daher sollte das klappen.
Verwendest Du Elasticsearch/OpenSearch oder nicht?
-
Wird der lokale Mediencache dann auch dort abgelegt?
yessir
Verwendest
Aktuell nein, werde ich mir aber nach dem Urlaub in Ruhe angucken
-
Aktuell nein, werde ich mir aber nach dem Urlaub in Ruhe angucken
Sind irgendwie (fast) noch größere Schmerzen als beim restlichen Stack, den Mastodon verlangt.
-
Ja, hab die Dokumentation mal kurz überflogen. Im Moment vermisse ich die Vorteile von ElasticSearch zumindest nicht, also Mal gucken.
-
Ich nutze seit Jahren zur key-Generierung auf den Servern (aus Gewohnheit ) immer schlicht: ssh-keygen -t rsa
Jetzt habe ich den Eindruck, dass es bei mir in letzter Zeit Probleme gibt, wenn Server mit sehr neuer openssh-Version mit älteren Verbindung aufnehmen wollen. (Nur in der Richtung Neu->Alt)
Welchen Algorithmus nutzt ihr, bzw. welcher ist empfehlenswert?
EDIT:
Allerdings habe ich diese Probleme (Server mit neuerer openssh-Version -> Älterer) bei scp mit Passwort-Anmeldung.
Liegt also evtl. an den Host-Keys...
Hmmm. Aber ssh geht problemlos. Nur scp und sftp machen Probleme
... werde ich wohl mal eingrenzen müssen ....
-
Für RSA und ECDSA gab es doch mal sicherheitstechnische Bedenken - allerdings kann ich das nicht genau beschreiben. Meine Keys mache ich seit Jahren mit Ed25519.
-
Hatte jemand von euch schonmal Probleme mit den Gmail Client auf Android, dass von einen auf den anderen Tag keine Mails mehr ankommen?
Im Webmail kommen sie aber weiterhin an. Auch in meinem Thunderbird ClientEdit: Änderung und/oder Updates an der Gmail App wurden nicht vorgenommen.
-
Hatte jemand von euch schonmal Probleme mit den Gmail Client auf Android, dass von einen auf den anderen Tag keine Mails mehr ankommen?
Im Webmail kommen sie aber weiterhin an. Auch in meinem Thunderbird ClientLeider ja, manchmal hilft ein Löschen des Caches und Neustart des Telefons.
Das Problem plagt mich leider auch ab und zu. -
Danke, das werde ich mal testen. Fliegen beim löschen des Caches nicht auch die Zugangsdaten der Accounts raus?
-
Danke, das werde ich mal testen. Fliegen beim löschen des Caches nicht auch die Zugangsdaten der Accounts raus?
Eigentlich nicht - zumindest meine Google Konten sind nicht rausgeflogen.
-
Leider ja, manchmal hilft ein Löschen des Caches und Neustart des Telefons.
Das Problem plagt mich leider auch ab und zu.Hat leider nicht geholfen. Des Rätsels Lösung war am Ende den betroffenen Account einmal vom Handy zu schmeißen und neu hinzufügen..
-
Welchen Algorithmus nutzt ihr, bzw. welcher ist empfehlenswert?
ed25519, aber ich habe (leider) für viele Zwecke auch noch einige RSA-Keys im Einsatz. Immerhin alle mit 4096 Bit…
-
Ist RSA so schlimm?
-
Ist RSA so schlimm?
Wenn die Schlüssellänge gut genug ist und nirgends veraltete Signaturen wie SHA1 verwendet werden: Nein, (afaik) alles gut.
Bei ed25519 kommt man aber mit weit niedrigeren Schlüssellängen aus und es ist in vielen Punkten moderner/besser.