Das längste Thema

Quote from killerbees19

Was mir erst jetzt auffällt: Es ist nie …::1 betroffen, immer nur eine andere (zufällig aussehende) Adresse.

Ja dann kein Wunder, dass bei mir alles geht. Ich mache das nur so.

interessanterweise, beim Stoirageserver ist es wie KB19 es sagt;

die anderen beiden sind Ok;

Ich habe auch Probleme mit IPv6 Teilweise bei meinen Servern und habe nichts an der Konfi geändert.

Hier habe ich eine Erklärung gefunden: https://forum.netcup.de/netcup…e-routing-q-a/#post147418

Jetzt geht IPv6 bei mir wieder Überall.

Quote from Track1991

Jetzt geht IPv6 bei mir wieder Überall.

Bei mir noch nicht von überall aus. Aus dem erweiterten Netz von GoDaddy bleibt es immer noch bei 2a00:11c0:47:1:47::140 hängen, aber nur die Adressen, die nicht auf ::1 enden.

KB19 bei meinem Storage-Server das selbe; die anderen beiden Ok;

und während ich des eintipp, wie wenn Dombledore seinen Zauberstab geschwungen hätte;

geht das wieder

sollte bei Dir mittlerweile auch gehen, da auch bei mir die Packete bei 2a00:11c0:47:1:47::140 versandeten;

Quote from mainziman

sollte bei Dir mittlerweile auch gehen, da auch bei mir die Packete bei 2a00:11c0:47:1:47::140 versandeten;

Nein, aus diesem einen Netzwerk klappt es weiterhin nicht.

Das Problem gab es in den letzten Monaten immer wieder mal, siehe auch hier. Da der letzte Hop aber im Anexia-Netzwerk ist, scheint es nicht am anderen Anbieter zu liegen.

Quote from eripek

Vielleicht bekommen wir heuer zu Weihnachten netcup-Tischuhren bei denen die 720 Monatsstunden richtig auf die Realmonatsstunden verteilt sind

Damit mal Kundentermine einhalten

Spannende Sache

1&1 Versatel scheint bei den Routing sehr Schnell zu sein.
Es hat sich Innerhalb Anexia was an der Traceroute getan, weil weniger Hops vorhanden sind.

Quote from mainziman

Valkyrie "Lernen durch Schmerz", tut Dir was weh bei?

rm -rf /

mir nicht

--no-preserve-rootist doch doof

Funktioniert da eigentlich

ln / /test
rm -rf /test

?

perryflynn Einspruch Euer Ehren;

Verzeichnisse können nur per Symbolic-Link verlinkt werden

ln -s / /test

und dann stellt sich die Frage ob

rm -rf /test

nicht ohnehin nur den Symbilc-Link beseitigt

interessant wär das da

rm -rf /test/

Quote from mainziman

perryflynn Einspruch Euer Ehren;

Verzeichnisse können nur per Symbolic-Link verlinkt werden

ln -s / /test

und dann stellt sich die Frage ob

rm -rf /test

nicht ohnehin nur den Symbilc-Link beseitigt

interessant wär das da

rm -rf /test/

Display More

Lasst mich Licht ins dunkle bringen. Ist eine Xubuntu 20.04 VM.

pasted-from-clipboard.png

Quote from whoami0501

Lasst mich Licht ins dunkle bringen. Ist eine Xubuntu 20.04 VM.

damit hat sich meine Vermutung bestätigt

und bei 'Licht ins Dunkel' stellt es ma die Haare auf;

hab 'ne Allergie gegen die ORF-Aktion;

Quote from mainziman

Einspruch Euer Ehren;

Es war eine Frage, also muss man da keinen Einspruch erheben. Ich wusste wirklich nicht, ob das geht.

whoami0501

Jetzt probiers mal bitte mit nem --bind mount.

Mal für die Unwissenden oder besser gesagt "auch noch nicht wissenden" hier. Unter Debian Buster / Raspbian Buster muss man Wireguard mittlerweile aus den Buster Backports ziehen. Die Version im Unstable Zweig wird nicht mehr gepflegt.

Hatte mich schon gewundert, warum es jetzt so lange keine Updates für Wireguard gab...

Und Raspbain wird scheinbar gerade auf 5.4.51 angehoben... Huh, na hoffentlich klappt das alles.

broda

Quote from whoami0501

Mal für die Unwissenden oder besser gesagt "auch noch nicht wissenden" hier. Unter Debian Buster / Raspbian Buster muss man Wireguard mittlerweile aus den Buster Backports ziehen. Die Version im Unstable Zweig wird nicht mehr gepflegt.

Das war tatsächlich neu für mich und wollte ich gleich umstellen. Aber siehe da, ich hatte mal nachgedacht beim Einrichten

Andererseits kann ich bei mir nicht nachvollziehen, dass die Version aus unstable so veraltet wäre?

# apt policy wireguard-tools
wireguard-tools:
  Installiert:           1.0.20200513-1~bpo10+1
  Installationskandidat: 1.0.20200513-1~bpo10+1
  Versionstabelle:
     1.0.20200513-1 90
         90 http://deb.debian.org/debian unstable/main amd64 Packages
 *** 1.0.20200513-1~bpo10+1 500
        500 http://deb.debian.org/debian buster-backports/main amd64 Packages
        100 /var/lib/dpkg/status

# apt policy wireguard-dkms
wireguard-dkms:
  Installiert:           1.0.20200623-1~bpo10+1
  Installationskandidat: 1.0.20200623-1~bpo10+1
  Versionstabelle:
     1.0.20200712-1 90
         90 http://deb.debian.org/debian unstable/main amd64 Packages
 *** 1.0.20200623-1~bpo10+1 500
        500 http://deb.debian.org/debian buster-backports/main amd64 Packages
        100 /var/lib/dpkg/status

Wenn ich die offizielle Anleitung richtig verstehe (https://www.wireguard.com/install/) wird die aktuelle Version in Bullseye gepflegt (testing). Auch unstable (sid) scheint die neueste Version zu beherbergen. Nur ältere Versionen (die meisten werden wohl Buster verwenden(?)) sollen Backports verwenden. Aber es spricht ja auch nichts dagegen die Bullseye version zu nehmen, wenn man testing/unstable repos sowieso schon eingerichtet hat. Oder habe ich da was falsch verstanden? Zumindest ist in unstable eine neuere Version als in den buster-backports

Ohh - ich habe es gerade nochmal bei mir geprüft, das ist richtig. Dann habe ich nichts gesagt, mein Fehler... ich muss wohl die Zahlen durcheinander gehauen haben.

Quote from whoami0501

ich muss wohl die Zahlen durcheinander gehauen haben

kommt in den besten Familien vor

Hat hier zufällig jemand Smokeping unter Debian Buster laufen?

Ich scheitere gerade daran, dass ich IPv6 Probes/Targets nicht ans Laufen bekomme.

Irgendwelche Tipps, was da in die Config muss? Mit den Beispielen klappt das nicht…