Das längste Thema

  • evtl. den rss feed parsen.

    Code
    curl -sSN "https://www.netcup-status.de/feed/" | xq -r '.[].channel.item[] | {titl: .title, desc: .description}'

    Das liest sich schon mal als erster Anfang gut. Welcher "xq" ist es denn? Der RSS Feed enthält nur soweit ich sehe nicht den aktuellen Status der jeweiligen Störung. Man könnte allerdings die "<guid isPermaLink="false" </guid>" nutzen um dann weiter zu parsen...

  • Ich habe die Unbound Problematik jetzt doch noch einmal debuggt, weil ich sie auch anders zuverlässig reproduzieren kann…


    Über IPv4 antworten die *.root-servers.net offenbar nicht auf meine UDP-Anfragen: dig @193.0.14.129 . NS

    Code
    IP (tos 0x0, ttl 64, id 24915, offset 0, flags [none], proto UDP (17), length 68)
    1.2.3.4.55571 > 193.0.14.129.53: [udp sum ok] 63676+ [1au] NS? . ar: . OPT UDPsize=1232 (40)

    Über TCP gibt es keine Probleme. Fordere ich etwas anderes an, bekomme ich jedoch eine Antwort: dig @193.0.14.129 netcup.de NS

    Code
    IP (tos 0x0, ttl 64, id 48178, offset 0, flags [none], proto UDP (17), length 78)
    1.2.3.4.51826 > 193.0.14.129.53: [udp sum ok] 19818+ [1au] NS? netcup.de. ar: . OPT UDPsize=1232 (50)

    Wirklich lustig daran ist aber, dass ich das nur über DSL (PPPoE) reproduzieren kann! Über das Mobilfunknetz läuft es einwandfrei. Alle getesten Anschlüsse haben eine öffentliche IPv4-Adresse. Die UDP-Ports sind prinzipiell in alle Richtungen erreichbar. Mit tcpdump fällt mir auch nichts Besonderes auf. Der einzige Unterschied ist die MTU, die bei PPPoE 1492 ist. Mit der UDPsize herumzuspielen bringt wohl nichts. Ich bin aber auch kein DNS-Experte.


    Irgendwelche Tipps, was ich noch versuchen könnte? Mir würde es schon mal reichen, wenn dig eine Antwort bekommt. :(

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Das ist doch hochgradig unseriös. Prognosen sind immer schwierig, besonders wenn sie die Zukunft betreffen (wer auch immer den Spruch erfunden hat). Das gilt bei Wetter ganz besonders. Eine Voraussage auf so lange Zeit kann eintreffen, muss aber nicht. Warten wir es doch erst mal ab, vielleicht kommen ja auch 55 Grad dabei rüber statt nur 50. Da brutzeln die deutschen Urlauber an der Adria schneller, können fünf Tage eher durchgebraten zurück nach Deutschland reisen und haben dann bequem diese eingesparten fünf Tage Zeit, ihre Quarantäne abzusitzen. Oder es werden 60 Grad, dann können sie sich die Quarantäne sparen, weil die Coronaviren das nicht überleben. Passt doch alles!


    Naja, Hauptsache eine gute Schlagzeile.

  • Danke, ist ein praktisches Tool! :)


    Das war jedoch unspektakulär, da es genau die Unbound-Konfiguration ausspuckt:

    Code
    rst.x1188.rs.dns-oarc.net.
    rst.x1198.x1188.rs.dns-oarc.net.
    rst.x1204.x1198.x1188.rs.dns-oarc.net.
    "1.2.3.4 DNS reply size limit is at least 1204"
    "1.2.3.4 sent EDNS buffer size 1232"

    Seltsamerweise kann ich aktuell (über Unbound) keine Probleme mehr feststellen. :/


    Mit deaktiviertem IPv6 gab es (unter bestimmten Voraussetzungen) die geschilderten Probleme. Mit aktivem IPv6 hat er mir aber das Log zugemüllt, wenn IPv6 nicht verfügbar war. Letzteres habe ich jetzt mal mit einer weiteren Defaultroute (Metric 2048) gelöst, die immer existiert. Scheinbar hat er sich am standardmäßigen EACCES verschluckt, bei EHOSTUNREACH ist bei nicht verfügbarem IPv6 wieder Ruhe.


    Aber ich könnte wetten, dass die IPv4-Probleme bei den DNS-Root-Servern irgendwann wieder auftauchen. Weiß der Geier, warum ich das jetzt nicht mehr reproduzieren kann. Einerseits bin ich froh, aber ich traue dem Frieden noch nicht ganz.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Bis jetzt musste ich ja noch nie ein vLAN einrichten. Jeder Server läuft für sich.

    Jetzt würde ich das aber hier bei Netcup gerne mal testweise versuchen. (Man weiß ja nie, wann man das mal schnell braucht ;))

    Gibt es irgendwo eine nette Anleitung (für Ubuntu-Server) für jemanden, der das noch nie gemacht hat? (Kann ja sooo schwer nicht sein :S)


    EDIT:

    usecase: Direkte Kommunikation der Server untereinander, also kein vorgeschalteter Server mit Firewall oder ähnliches. Die Server sollen weiterhin über ihre bisherige IP von außen zu erreichen sein.

  • aRaphael Einfach eine statische Netzwerkkonfiguration für das zweite Interface (eth1 bzw. ens6) hinterlegen? :)


    Wenn die angebundenen Server nur untereinander kommunizieren sollen, brauchst Du nicht mal einen Gateway angeben. Also einfach ein privates IPv4-Subnetz und eventuell ein IPv6-ULA aussuchen, fertig.


    https://wiki.ubuntuusers.de/Ne…che-Netzwerkkonfiguration

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • aRaphael Ergänzung: Bei IPv6 eventuell noch "DAD" und "RA" bzw. die Autokonfiguration deaktivieren. Sonst dauert es manchmal unnötig lange.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • gerade die Begegnung der 3ten Art: einen Linux ISO downgeloadet, in einer VM installiert,

    und dann läßt mich des System net direkt als root anmelden, aber kennt kein SELinux;

    was hat den Murx geritten Paranoia ohne SELinux an den Tag zu legen? 8o

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • /me erstellt endlich mal ein "Backup" seiner YouTube Music Likes Playlist 8)

    Da werden jetzt zwar einige Duplikate und unnötige Dateien dabei sein, aber die sortiere ich später aus…

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Bremstest - eine Lok gegen ein Auto

    Stahl (Monoblock-Reifen der Lok) auf Stahl (Schienen) bremst halt net so gut;


    bei einem ICE dauert des schon 10 km und mehr bis der steht

    (hier aber auch von mehr als 200 km/h auf 0 km/h);


    ein Supertanker braucht 13 km bis er zum Stehen kommt,

    sollt also mehr als diese 13 km vor der Küste zu bremsen beginnen :D

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)