Das längste Thema

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.

Zitat von frank_m

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

[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

[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)

[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.

Zitat von RAD750

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;

Zitat von KB19

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.

Zitat von RAD750

Ich speichere auf Backblazien daher macht Speicher kein Problem (Kostenalarme hab ich an).

Wird der lokale Mediencache dann auch dort abgelegt?

Zitat von RAD750

Ob RAM Probleme macht kann ich noch nicht beurteilen, aber die Instanz ist privat, daher sollte das klappen.

Verwendest Du Elasticsearch/OpenSearch oder nicht?

Zitat von KB19

Wird der lokale Mediencache dann auch dort abgelegt?

yessir

Zitat von KB19

Verwendest

Aktuell nein, werde ich mir aber nach dem Urlaub in Ruhe angucken

Zitat von RAD750

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 Client

Edit: Änderung und/oder Updates an der Gmail App wurden nicht vorgenommen.

Zitat von iKameo

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 Client

Leider 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?

Zitat von iKameo

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.

Zitat von H6G

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..

Zitat von aRaphael

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?

Zitat von RAD750

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.