Bei deinen oben geposteten mtr's sehe ich kein Problem?
Das Ziel (letzte Zeile) ist bei allen 4 Messungen mit 0% loss.
Hast du mal auch die Gegenrichttung gemessen ? Oben ist nur
netcup arm --> extern
Was ist mit:
extern --> netcup arm ?
Beiträge von ulf8000
-
-
Aktuell ist es teilweise so, dass selbst ohne Repeater und in direkter Nähe = 2m vor der Fritz!Box der Durchsatz zeitweise gegen 0 geht ...
-->Fritzbox defekt oder Funkstörung.
Hast du mal mit einer App auf dem Handy (z.B. FRITZ!App WLAN) das Haus vermessen? Wie viele andere WLAN's sind da auch noch ?
Und noch ein Tipp: bei Routern mit beweglichen/ausrichtbaren Antennen kann man "etwas" mehr an WLAN Abdeckung/Durchsatz rausholen. -
Schreib mal den netcup Support an, ich habe mal gelesen, sie versuchen die Kunden schon zu verteilen, vermutlich aber ohne 100% Garantie.
Ggf. kannst du mit einer konkreten Anfrage zu deinem Projekt (mit konkreten geplanten Produkt Details: Anzahl / ARM / vserver / root server) etwas konkreteres raus bekommen. Oder wenigsten Abschätzen in welche Richtung die Antwort führt.
Und: ARM und x86 sollte schon mal getrennte HW sein = 2,
plus * Wien /Nürnberg = 4
-
Es geht auch ohne, z.B. mit Bitwarden.
Und da mache ich mich von der Firma "Bitwarden Inc." abhängig.
Statt bei google, apple oder ms ist mein Passkey dann bei Bitwarden unter Kontrolle.
-
Passkey != YubiKey
Und KeePassXC benötigt einen PC mit sauberem (!) OS, und mobil geht da gar nichts.
Zum Testen wurde mir "https://passkey.org/" genannt, Aber mit Firefox oder Chromium komme ich mit KeePassXC auf der Seite nicht weiter. Nutze Linux.
Ich würde mich gerne überzeugen lassen, aber aktuell sind Passkey aus meiner Sicht nicht praxistauglich, ausser man ist bereit sich 100% in die Arme von google, apple, oder ms zu legen.
-
Ich bin gegen Passkeys, weil man damit aktuell die Kontrolle an Google Apple und MS abgibt.
Und nicht nur die Kontrolle für einen Zugang, sondern für alle seine Passkeys.
Mit Kontrolle meine ich nicht, dass die genannten 3 Zugriff erlangen könnten, sondern das ich den Passkey DIENST nur nutzen kann wenn die genannten möchten, oder können...
-
Hier ein Rsync Beispiel, Quelle oder Ziel kann dann ein ssh Ziel sein:
https://wiki.archlinux.org/title/Rsync#Full_system_backup
Und hier noch ein paar Anmerkungen zu den Nacharbeiten:
https://wiki.archlinux.org/title/System_backup
plus "meine" Liste:sudoedit /etc/fstab
sudoedit /etc/hostname
sudoedit /etc/hosts
sudo rm /etc/machine-id && sudo systemd-machine-id-setup
reinstall # kernel + bootloader + initramfs
# network
# ssh server config
-
GParted --> Parted im Terminal
Ist bei Debian dabei, ich vermute auch im grml Rescue System.
Ich hebe mir die Kommandos in einer Text Datei auf - ist 3x schneller als im GUI und besser reproduzierbar.
-
Bisher entdeckt:
.ch-Domain mit 74% Rabatt
.com-Domain mit 20% Rabatt
.de-Domain mit 69% Rabatt
.eu-Domain mit 46% Rabatt
.net-Domain mit 35% Rabatt
.org-Domain mit 20% Rabatt
Cloud vLAN 2,5 Gbit/s mit 45% Rabatt
Die EGGspert Ostereiersuche
Failover IPv4 Adresse mit 36% Rabatt
netcup Coffee2Go Becher
Reseller Level B mit 45% Rabatt
RS 1000 G9.5 SE VIE
RS 2000 G9.5 SE NUE
RS 2000 G9.5 SE VIE
RS 3000 G9.5 SE VIE
RS 4000 G9.5 SE VIE
RS Easter Duck VIE
VPS 1000 G10 SE NUE
VPS 1000 G10 SE VIE
VPS 2000 G10 SE NUE
VPS 3000 ARM G11 SE NUE
VPS 500 G10s
VPS 8000 ARM G11 SE NUE
VPS 8000 ARM G11 SE VIE
VPS Schoko Bunny VIE
VPS Schoko Bunny VIE OST24
Webhosting 1000 SE mit 50% Rabatt
Webhosting 2000 SE mit 20% Rabatt
Webhosting 4000 SE mit 42% Rabatt
Webhosting Eggcellent mit 42% Rabatt
Zusätzliche IPv4 mit 20% Rabatt
-
Es wird empfohlen sofort upzudaten,
bis jetzt sieht es nicht ganz so dramatisch aus, das ggf. anvisierte sshd Paket unter Arch scheint nicht betroffen zu sein.
https://archlinux.org/news/the-xz-package-has-been-backdoored/
-
Ich hatte die Sorge, dass diese "Fehlkonfig" vom SCP dann doch irgendwo/irgendwann durchschlägt, z.B. im Rescue Mode oder wenn ich irgendwann mit einem anderen Netzwerkproblem den Service kontaktiere und dann am diskutieren bin, warum ich nicht die Daten aus dem SCP verwende...
Ein saubere Netzwerk Konfig ist das wichtigste bei einem vserver - daher ja, falsches Gateway im SCP ist für mich ein nogo.
Ich habe die Kündigung von einem anderem/ähnlichen Server zurückgenommen und bin da wieder eingezogen
-
ich nutzte als networkmanger systemd, und habe gerade nochmal nachtestet,
mit
Gateway=fe80::1
funktioniert alles, mit
Gateway=2a03:4000:0:2::1
ist der Server nach einemsudo systemctl restart systemd-networkd systemd-resolved
nicht mehr per IPv6 erreichbar.
Da ich primär auf IPv6 setzte und IPv4 nur Nebensache ist, habe jetzt ausnahmsweise mal von der Zufriedenheitsgarantie Gebrauch gemacht - Server ist zurück im großen Pool.
-
Danke für die Infos.
Ich habe es so verstanden das ich meine Konfig bei fe80::1 lassen kann und es sollte nirgendwo Probleme geben ?Seltsam, das war die Dienstags Aktion - wo kommt da ein "älterer Netzwerkaufbau" her... ?
-
Normalerweise hatten bisher alle Server im SCP folgendes IPv6 Gateway:
Gateway / Routing to fe80::1
Heute habe ich meinen neuen Aktionsserver "RS 1000 G9.5 SE NUE WD24" installiert - dieser hat da aber was seltsames im SCP stehen :
Gateway / Routing to xxxx:yyyy:0:2::1
ich hatte das so natürlich erstmal 1:1 in meine Netzwerk Konfig übernommen - aber : so funktioniert kein IPv6.
Erst nachdem ich das übliche fe80::1 eingetragen habe funktioniert IPv6 wie gewohnt.
Schaust ihr bei euch mal nach den IPv6 Gateways ? Gibt es was anderes außer fe80::1 ?
Nur bei mir falsch, oder nur bei der WD24 Aktion falsch ?
Oder habe ich was übersehen ?
-
Ich tunnel per ssh.
Die einzige Ressource die ich auf dem ARM Server verwende ist also nur eine 20GB Datei, die auf einem ext4 liegt (mount options defaults,noatime,errors=remount-ro), worauf ich per ssh/sftp zugreife.
Ein Unterscheid zum RS Server fällt mir noch ein: RS Server läuft mit Arch linux (lts kernel), der ARM läuft mit Debian.
-
Beobachte ich jetzt schon etwa 1 Woche. ARM ist hier immer deutlich langsamer.
Selbst ein VPS piko G11s 12M ist hier schneller.
Usecase: Ich tunnel eine 20 GB Datei vom Server durchs Netz zu mir nach Hause. In der Datei ist ein verschlüsseltes Dateisystem.
Prinzip: Zero Content Knowledge auf dem Server.
-
Bei meinem ARM in Wien startet nun das Rescue System, aber:
"Loading linux" sieht man 5 Minuten,
"Loading initrd" bis zum prompt nochmal 5 Minuten == 10 Minuten Bootzeit.
Habt ihr das auch ? Nur in Wien, nur bei den neuen ARM ?
-
Ich habe zum Testen einen "VPS 1000 ARM G11" neben einen RS1000 gestellt.
Soweit ist die Performance super, cpu und sequential read speed mit hdparm, random 4K reads mit fio.
Bei einer meiner Anwendung sehe ich aber einen Unterschied.
Anwendung:
Server: ext4 --> 20GB Datei --> ssh/sftp
bei mir: --> sshfs --> random Access auf die 20GB Datei (die ein Dateisystem enthält)
Ein gleicher Testcase dauert etwa 6-7 Sekunden länger:
RS1000 : 16 s
ARM : 22 s
Kann es an der Netzwerk Latenz liegen ?
ich bin in NRW, RS1000 ist in Nürnberg, ARM ist in Wien.
Und beim mtr noch aufgefallen:
- ipv6 ist deutlich schneller als ipv4 ?
- ich nach Wien ipv6: 18ms (ipv4: 31ms)
- ich nach Nürnberg ipv6: 10ms (ipv4: 23ms)
Kann dies mein Problem erklären ? Ein ARM in Nürnberg wäre für mich besser? Oder was könnte ich noch testen /überprüfen ?
-
-
Habe mit dem Entwickler geschrieben,
es gibt 3 verschiedene ISO Varianten, ich hatte oben das 1. Iso genommen.
Nach Rückfrage läuft nur die "local" Variante erstmal ohne Netzwerk.
Den letzten Satz hat er jetzt neu hinzugefügt.
D.h. hier könnt man ein root Passwort setzten, ssh config/keys anlegen, und dann erst das Netzwerk mit ssh starten.
Mit der vnc cosole ist das aber Strafarbeit... nicht mit mir
Jetzt weiß ich, warum netcup kein arm arch Iso anbietet...
