Das längste Thema

  • Eine kleine TTL bürgt das Risiko, dass der Internetauftritt eine Weile offline sein kann. Das passiert zwar selten, aber auch die Registries können einmal ausfallen, so wie z.B. die Denic im Jahr 2010: https://www.heise.de/newsticke…lahm-3-Update-999068.html


    Ich erinnere mich an den Ausfall noch sehr gut.

    Das ist natürlich auch ein Argument. Aber für den Großteil der Nutzer dürfte der Internetauftritt trotzdem offline sein, auch wenn die TTL etwas länger sein sollte. Denn der Eintrag muss ja auch erst einmal im Cache vorliegen. Gerade bei einem so dezentralen System wie den vielen Mailservern ist es ja dann eher ein Glücksspiel, dass gerade der eine Mailserver den Eintrag noch im Cache hat (bzw. der lokale Resolver in der Firma). Eine lange TTL könnte also höchstens dazu führen, dass ein paar "Stammkunden" etwas länger auf die Seite zugreifen können bzgl. die eine Mail mal eben doch noch zugestellt wird.

    Insgesamt überwiegen für mich jedoch ganz klar die Vorteile einer kurzen TTL. Denn Probleme mit dem eigenen Mailserver oder ungeplante Serverumzüge passieren dann in der Regel doch häufiger als dass mal ein Registrar offline ist. Ist dann am Ende des Tages eine Abwegung, welches Risiko man eher eingehen möchte :-).

  • zum Thema DNS fällt mir gerade was ein;


    letzte Woche füllte es den Log, daß eine bestimmte Domain eine ungültige DNSSEC-Validierung hat,

    und weil ich meinen Resolver so eingestellt habe, gab es auch keine DNS-Auflsg.;


    dann dachte ich mir, machste einfach mal host domain.com dns-from-isp

    siehe da, das lieferte IP-Adressen;

    dann dachte ich, einfach eine forward-Zone im BIND der einfach den dns-from-isp fragt,

    und hier passierte das selbe - die selben Log-Einträge und auch keine DNS-Auflsg.;

    dann hab ich den gesamten Log (rund 6 MBytes) an die abuse@-Adresse geschickt,

    und der Spuk hatte am nächsten Tag ein Ende;

    Grüße / Greetings

    Walter H.


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

  • und nun erkläre ich dem anderen Lehrer zum wiederholten mal, dass keiner von uns im Unternehmen Debian, sondern eher RHEL/CentOS oder SLES/openSUSE nutzt. Trotzdem werden wir daran ausgebildet.


    Habt Ihr in Deiner Klasse schon mal eine Umfrage gemacht, wie viele der vertretenen Firmen Debian, RHEL/CentOS und/oder SLES/openSUSE verwenden ?


    Würde mich interessieren, weil ich einigen Firmen (auch sehr großen) kenne, die auch Debian einsetzen.

  • Ich könnte mich grade schon wieder aufregen.


    [...] Berufsschullehrer [...] agile Arbeitswelt [...] dass keiner von uns im Unternehmen Debian, sondern eher RHEL/CentOS oder SLES/openSUSE nutzt

    Ich habe da ein Déjà-vu - Das hatten wir hier doch schon mal :)


    Es gibt auch Unternehmen, die Debian einsetzen. Und die sind gerade nicht mal klein. Solange ihr die Konzepte lernt und nicht nur dpkg-reconfigure php3 und dpkg-reconfigure qmail, dann sollte man das Abstrahieren können ;)

    "Security is like an onion - the more you dig in the more you want to cry"

  • Habt Ihr in Deiner Klasse schon mal eine Umfrage gemacht, wie viele der vertretenen Firmen Debian, RHEL/CentOS und/oder SLES/openSUSE verwenden ?

    Tatsächlich nicht, aber von einigen weiß ich es, vom Rest vermute ich es.


    tab hat schon recht, es kommt auf den Einsatzzweck an. Ich habe auch einen Kollegen, der privat noch eine kleine Hosting Firma mit einem Kumpel hat, die nutzen auch nahezu ausschließlich Debian.

    Aber zumindest bei uns im Betrieb nutzt man Debian nicht, und wir sind ja nun wahrlich ein sehr großes Unternehmen. Fakt ist, dass Debian nicht so sehr wie RHEL oder SLES auf Enterprise ausgerichtet ist. Um nicht sogar zu behaupten, dass es nur eingeschränkt dafür vorgesehen ist.


    Ich habe da ein Déjà-vu - Das hatten wir hier doch schon mal


    Es gibt auch Unternehmen, die Debian einsetzen. Und die sind gerade nicht mal klein. Solange ihr die Konzepte lernt und nicht nur dpkg-reconfigure php3 und dpkg-reconfigure qmail, dann sollte man das Abstrahieren können

    Klar, ich könnte mich da auch immer wieder drüber aufregen. :P


    Meinentwegen nutzen einige Unternehmen auch Debian - aber auch dann vermutlich keine Version, die neulich oldstable verlassen hat.

    Am Ende der Stunde ist ihm dann aufgefallen, dass es ja schon Debian 10 gibt (oh wunder) - und dann war ich auf einmal nicht mehr der "Klugscheißer", den er rauswerfen wollte, sondern sollte ihm so gefühlt den kompletten Changelog zwischen Jessie und Buster erzählen... naja, mit besten Wissen und Gewissen erledigt und ab nach Hause. :P

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Nach einem Kernel-Update (bzw. dem reboot danach) hängt sich der gesamte Server (Ubuntu 18.04) komplett auf. Netzwerk tot, Anzeige eingefroren, tot einfach. In den Logs gibt es nichts; die brechen einfach ab und offenbaren auch keine mögliche Ursache. Der Server stürzt immer kurz danach ab, nachdem systemd gemeldet hat, dass das hochfahren abschlossen sei.

    Beim booten mit dem vorherigen Kernel ist alles in Ordnung und der Server läuft. Hat jemand eine Idee, wie ich das Problem eingrenzen könnte?

    Kernel habe ich schon neu "konfiguriert" via dpkg-reconfigure.

    Es ist ein reiner Docker-Host (wobei die gleiche Kombination aus OS, Kernel und Docker-Version auf einem anderen Server problemlos funktioniert).

  • Nach einem Kernel-Update (bzw. dem reboot danach) hängt sich der gesamte Server (Ubuntu 18.04) komplett auf. Netzwerk tot, Anzeige eingefroren, tot einfach. In den Logs gibt es nichts; die brechen einfach ab und offenbaren auch keine mögliche Ursache. Der Server stürzt immer kurz danach ab, nachdem systemd gemeldet hat, dass das hochfahren abschlossen sei.

    Beim booten mit dem vorherigen Kernel ist alles in Ordnung und der Server läuft. Hat jemand eine Idee, wie ich das Problem eingrenzen könnte?

    Kernel habe ich schon neu "konfiguriert" via dpkg-reconfigure.

    Es ist ein reiner Docker-Host (wobei die gleiche Kombination aus OS, Kernel und Docker-Version auf einem anderen Server problemlos funktioniert).

    Hast du den Kernel mal komplett gelöscht (apt purge) und neu installiert? Würde ich jetzt zumindest mal als erstes versuchen, also nicht einfach nur ein dpkg-reconfigure ausführen. Auch an die Module/Header denken :)

  • whoami0501 : Das sind squeeze und wheezy Systeme. Das ist halt wie die Cobol-Problematik. Da traut sich keiner mehr ran, weil keiner weiß was da alles läuft. Sterben werden die Systeme so schnell auch nicht, denn die wurden irgendwann mal durch den VMWare Konverter gejagt.

    "Security is like an onion - the more you dig in the more you want to cry"

  • vmk das gilt grundsätzlich; bei den anderen Distris nicht viel anders;

    CentOS 5 ist wahrscheinlich auch noch nicht ausgestorben;

    dein Vergleich mit der Cobol Problematik ist dann schon eine Ansage,

    die das Gegenteil aussagt;

    Grüße / Greetings

    Walter H.


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

  • Hast du den Kernel mal komplett gelöscht (apt purge) und neu installiert? Würde ich jetzt zumindest mal als erstes versuchen, also nicht einfach nur ein dpkg-reconfigure ausführen. Auch an die Module/Header denken :)

    Danke für den Tipp, habe alles runter gehauen... Leider ohne Erfolg...

    Ich konnte jedoch gerade beobachten, das die CPU-Auslastung beider Kerne bei 100% stehen geblieben ist (also beim Aufhängen). Ob es ein Zufall ist weiß ich nicht; ich weiß aber auch nicht was es mir sagen soll (schließlich kommt zu diesem Zeitpunkt ja eine ganze Mailkuh in die Gänge). Ich habe gerade nochmal die Logs durchgeschaut, wieder nichts.

  • Nach einem Kernel-Update (bzw. dem reboot danach) hängt sich der gesamte Server (Ubuntu 18.04) komplett auf. Netzwerk tot, Anzeige eingefroren, tot einfach. In den Logs gibt es nichts; die brechen einfach ab und offenbaren auch keine mögliche Ursache. Der Server stürzt immer kurz danach ab, nachdem systemd gemeldet hat, dass das hochfahren abschlossen sei.

    Beim booten mit dem vorherigen Kernel ist alles in Ordnung und der Server läuft. Hat jemand eine Idee, wie ich das Problem eingrenzen könnte?

    Kernel habe ich schon neu "konfiguriert" via dpkg-reconfigure.

    Es ist ein reiner Docker-Host (wobei die gleiche Kombination aus OS, Kernel und Docker-Version auf einem anderen Server problemlos funktioniert).

    Ist es zufällig der Kernel 4.15 und hast du Mailcow dockerized drauf? :/

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Juhu. Neue SSDs sind da, eingebaut und ZFS erstellt. Container alle umgezogen, aus nem anderen Hardware Umbaugrund das System neugestartet, und nun hänge ich im Emergency Mode von Proxmox.


    ZFS bzw. Proxmox speichert ernsthaft, aus welchen Gerätedateien der Pool besteht. Mainboard hat einmal bunt gemischt, und ich habe nun den Salat. Wundervoll. Was kann man da machen?


    Also das ZFS bestand ursprünglich aus sdi und sdh - nun aus sdf und sdg. Und beim nächsten reboot wieder aus was anderem. Grummel...

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber