Re: Wie könnte man Exim Bug erkennen?
cool. Ich habe es an den Author testssl.sh weitergeleitet Am 10.09.19 um 12:49 schrieb Heiko Schlittermann: Heiko Schlittermann (Di 10 Sep 2019 11:27:13 CEST): leicht testen. Siehe dazu den Testscript aus den Regression-Tests an, in 4.92.2 ist es Test 0909. Im aktuellen Master branch ist es jetzt Test 1100. Der nutzt ein präpariertes Spool-File, liest das ein und gibt eine expandierte Variable aus. -- Heiko -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Re: real hardware (was: Schlechte Laune?)
Hallo Thomas, On Tue, Sep 10, 2019 at 11:59:05 +0200, Thomas Guettler wrote: > >>Also auch wenig Bootprobleme. > > > >Nur wenn man sich echte Hardware wegdenkt. Die hoert deswegen aber nicht > >auf zu existieren. > > Fuer mich existiert an vielen Bereichen Hardware nicht mehr. Und das > finde ich super. Unsere Software laeuft als SaaS im Rechenzentrum des > Kunden. Der hat VMWare und wir nutzen dort die VM. Das laeuft seit Jahren > super stabil. Sicherlich existiert die Hardware irgendwo. Aber dafuer > ist jemand anderes verantwortlich. Die genauen Verantwortlichkeiten werden im Fehlerfall vom Kunden aber nicht unbedingt erkannt. Wenn die VM oder das System, auf dem sie laeuft ein Problem hat, koennten Support-Ticket oder Bugreport trotzdem bei Dir landen. Dann geht eine Menge Zeit fuer (erfolgloses) Nachstellen des Fehlers mit Eurer Software drauf, bevor der Kunde dann irgendwann kleinlaut zugibt, dass es "vielleicht" doch an seiner Infrastruktur liegt, die durch VMs/Container und Orchestrierung so komplex geworden ist, dass er sie nicht mehr ueberblickt. Wir verwenden auch VMs, aber hauptsaechlich zu Testzwecken. Das darin getestete System muss im spaeteren Einsatz beim Kunden aber auf echter Hardware laufen, aus Performancegruenden und damit es die alleinige Kontrolle ueber die Hardware hat. > Es gibt getrennte Verantwortungsbereiche: Hardware macht Firma x, > Linux-VM verwalten macht Firma Y. Es ist auch schoen, wenn man mal > nicht fuer alles verantwortlich ist. Solange dabei Daten verarbeitet werden, fuer die es egal ist, ob sie wegkommen, mag das funktionieren. Immerhin gibt man durch solche Konstrukte die Daten aus der Hand. Mich stoeren nicht VMs/Container an sich, sondern die oft vertretene Ansicht, dass man Systeme/Services gar nicht mehr anders betreiben kann -- oder "weil man das jetzt so macht". Gruss, Christian -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing
Re: Wie könnte man Exim Bug erkennen?
Heiko Schlittermann (Di 10 Sep 2019 11:27:13 CEST): > leicht testen. Siehe dazu den Testscript aus den Regression-Tests an, in > 4.92.2 ist es Test 0909. Im aktuellen Master branch ist es jetzt Test 1100. Der nutzt ein präpariertes Spool-File, liest das ein und gibt eine expandierte Variable aus. -- Heiko signature.asc Description: PGP signature
Re: Wo willst du arbeiten, wenn du Admin wärst?
Am Dienstag, den 10.09.2019, 12:04 +0200 schrieb Thomas Güttler: > > > Nicht schön, aber nachvollziehbar. Wäre ich Admin (ich bin eher > Software-typ), dann würde ich lieber in einer Firma arbeiten die > tausend Server hat, nicht nur zwanzig. Also finden die kleinen Firmen > keinen fähigen Admin. > Richtig. In den meisten kleinen Firmen hast Du zudem die Herausforderung, tagtäglich eine nervige Menge an Handarbeit auf dem Schirm zu haben, aber an einer Schwelle, an der sich die Investition in beispielsweise Infrastruktur- und Konfigurationsmanagement, in Dinge wie puppet oder ansible, gerade noch nicht lohnt. Ergebnis: Du bleibst auf ewig verdammt dazu, dort in Handarbeit immer wieder diesselben Probleme zu lösen, die längst besser/robuster/meist auch wirtschaftlicher gelöst sind, nur eben nicht für Organisationen Deiner Größe und Dich als Einzelkämpfer, der dann im schlimmsten Fall (eigenes Erleben) auch schon mal aus dem Urlaub zurückkommt, weil in dem Fileserver das RAID ausgefallen ist und sich niemand, auch von den Dienstleistern drumherum, mit Debian auskennt... Das Problem ist zudem ja: Es hört bei den Anforderungen, die in 2019 an Infrastruktur stehen, nicht bei dem einen Admin auf. Du brauchst mindestens zwei, weil der eine auch mal Urlaub machen möchte. Und dann hast Du sofort die gesamte Baustelle auf dem Tisch, die sich mit Wissens- und Change-Management beschäftigt, um sicherzustellen, daß die Admins, nun, denselben Wissens-Stand haben, den sie brauchen, um das System betreiben zu können. Das musst Du schaffen, das braucht Geld und Wissen. Und schlimmstenfalls hast Du dann einen komplexen Prozess und zwei Admins, die sich bei Dir langweilen, weil die Handvoll Server im Regelfall laufend genau so viel Aufwand verursacht, daß man es nicht ignorieren kann, aber nicht so viel, daß es die verfügbaren Menschen auslasten, geschweigedenn ganztägig mit halbwegs anspruchsvollen Tätigkeiten versorgen könnte. Lesenswert dazu (weiß nicht, ob das hier schon mal rumgeflogen ist) ist der Thread von Kristian Köhntopp auf Twitter, siehe dies hier: https://twitter.com/isotopp/status/1009364595084025856 > > Wir suchen schon lange einen fähigen Linux-Admin. Aber das ist nicht > zu finden. Software-Entwickler findet man eher. > Wir finden leider beides nicht im Moment. :( Ich nehme dafür bei unseren Marktbegleitern sehr oft wahr, daß dort Leute sind, die ganz massiv und fokussiert auf Kunden losrennen, die sich genau auf ihre Fachdomain konzentrieren, ihren Kram auf AWS oder eben DO deployen und die Energie, die wir selbst noch brauchen, um Infrastruktur zu streicheln, voll und ganz in ihre Produkte stecken können. Ich fürchte, als KMU verliert man dieses Rennen irgendwann. Viele Grüße, Kristian
Wo willst du arbeiten, wenn du Admin wärst?
Am 09.09.19 um 21:54 schrieb Kristian Rink: Am Montag, den 09.09.2019, 21:45 +0200 schrieb Martin Schuchardt: Also bitte, ärgert Euch gegenseitig nicht. Jeder hat entsprechende Anforderungen an ein Setup, Anforderungen die mit Hardware / VM / Containern unterschiedlich erreichbar sind. Daher sollte jeder für sich selber entscheiden, was für ihn das richtige ist. Ack. Ich sehe es (leider) pragmatisch, bzw. muss es so sehen: Mir wäre Bare Metal lieber, aber gegenwärtig ist es nahezu unmöglich, Personal zu bekommen, das imstande und willens ist, Infrastruktur zu administrieren. Sehr interessanter Punkt. Der fähige Admin vor Ort, der in einer kleinen Firma tätig ist ... das ist am Aussterben. Nicht schön, aber nachvollziehbar. Wäre ich Admin (ich bin eher Software-typ), dann würde ich lieber in einer Firma arbeiten die tausend Server hat, nicht nur zwanzig. Also finden die kleinen Firmen keinen fähigen Admin. Und SaaS ist billig und macht keinen Urlaub. Wir suchen schon lange einen fähigen Linux-Admin. Aber das ist nicht zu finden. Software-Entwickler findet man eher. Ich stelle das nur fest und finde es schade. Aber so ist es. Mithin dienen die verschiedenen Layers vorrangig als Einkaufsabstraktion, die man versucht, so weit "oben" als möglich zu ziehen, damit das eigene (teure, knappe) Personal sich auf die Dinge fokussieren kann, die sich aus fachlichen Gründen nicht auslagern lassen. Und an dem Punkt ist es im Extremfall eben schon eine Rechnung, ob ich drei Leute brauche, um Linux-Infrastruktur zu betreiben, oder die drei Leute Anwendungen bauen lassen kann, die etwa auf irgendwelchen Droplets bei Digital Ocean laufen. Viele Grüße, Kristian Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Schlechte Laune?
Hallo Christian, Am 09.09.19 um 20:24 schrieb Christian Perle: Hallo Thomas, On Mon, Sep 09, 2019 at 15:42:44 +0200, Thomas Güttler wrote: Ich finde systemd super. Und dass es den Kernel ablösen soll, das ist vermutlich nicht von dir ernst gemeint, oder? Nein, damit war nur die Tendenz gemeint, dass systemd immer mehr Dienste assimiliert, die nichts mit einem Initsystem zu tun haben. Und die Vorstellung, etwa Bootprobleme ohne eine Shell zu debuggen, finde ich ziemlich gruselig. Wenn das Image nicht läuft, dann wird ein neues erstellt. Das Image (bzw der Container) wird erstellt, verwendet, verworfen. Es gibt keine Updates mehr. Die IT-Welt besteht nicht nur aus Containern. Ich rede von einem System, das auf wirklicher Hardware laeuft. Das brauchst Du auch, wenn Du Container/VMs/whatever benutzt. Also auch wenig Bootprobleme. Nur wenn man sich echte Hardware wegdenkt. Die hoert deswegen aber nicht auf zu existieren. Für mich existiert an vielen Bereichen Hardware nicht mehr. Und das finde ich super. Unsere Software läuft als SaaS im Rechenzentrum des Kunden. Der hat VMWare und wir nutzen dort die VM. Das läuft seit Jahren super stabil. Sicherlich existiert die Hardware irgendwo. Aber dafür ist jemand anderes verantwortlich. Sicherlich wird es noch per Hand gepflegte Linux Installationen geben, aber vieles wird in dem SaaS Sog aufgelöst. Und so kommt Layer ueber Layer, Abstraktion ueber Abstraktion und wenn es irgendwo kracht, lassen sich Fehler kaum noch nachvollziehen. Das KISS-Prinzip, was unixoide Systeme eigentlich ausmacht, wird gerade so richtig verkackt. Es gibt getrennte Verantwortungsbereiche: Hardware macht Firma x, Linux-VM verwalten macht Firma Y. Es ist auch schön, wenn man mal nicht für alles verantwortlich ist. So viel schlechte Laune zum Montagabend, Christian Warum schlechte Laune? Es gibt unterschiedliche Meinungen. Aber das ist doch kein Grund für schlechte Laune, oder? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Re: Wie könnte man Exim Bug erkennen?
Thomas Güttler (Di 10 Sep 2019 11:01:50 CEST): > mal was Konstruktives, Schaffendes: > wie könnte man einen Test schreiben, der den aktuellen Bug in Exim erkennt? > Siehe https://github.com/drwetter/testssl.sh/issues/1313 Bin mir nicht sicher, ob das von außen testbar ist, außer Du hast den Exploit. (Der bisher nur im Labor als POC existiert.) Der original Reporter hatte eine SEGV festgestellt und war dabei über den problematischen Programmcode gestolpert. Das haben wir dann analysieren lassen um die Gefährlichkeit einschätzen zu können. Den Securityleuten von Qualys ist es gelungen, einen Exploit zu konstruieren (deren Mails habe ich dem Exim mit ins Git-Repo gelegt). Du könntest versuchen, rauszufinden, was Du noch alles tun musst, damit Du zu einem Segfault kommst. Aber auch das wird Dir vermutlich nicht weiterhelfen, weil das erst passiert, wenn die Mail aus dem Spool zurückgelesen wird, da ist die Einlieferung schon abgeschlossen. Wenn Du *auf* der betroffenen Maschine drauf bist, kannst Du das sehr leicht testen. Siehe dazu den Testscript aus den Regression-Tests an, in 4.92.2 ist es Test 0909. Im aktuellen Master ist es auch noch dort, wird aber noch mal umziehen. -- Heiko signature.asc Description: PGP signature
Wie könnte man Exim Bug erkennen?
Hallo, mal was Konstruktives, Schaffendes: wie könnte man einen Test schreiben, der den aktuellen Bug in Exim erkennt? Siehe https://github.com/drwetter/testssl.sh/issues/1313 Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
