Das ist strange.Gerade professionelle Admin-Skills im Unix-Umfeld sind aktuell wahnsinnig gefragt. Alle mir bekannten (Nicht-Windows-)Admins können sich vor Anfragen und Abwerbeversuchen kaum retten.
Ich jedenfalls bin von einer Massenentlassung erwischt worden, wo man ganz gezielt die Leute mit Skill loswerden wollte, und zwar zu Tausenden - mit dem Tenor >Skill wollen wir nicht mehr bezahlen, denn der kommt jetzt aus der Cloud.<
Und an Offerten hab ich nur gesehen, dass Java-Coder gesucht sind - mit einer Ausnahme, aber da ging es darum, dass man den gesetzlichen Mindestlohn nicht wirklich bezahlen wollte.
Okay, falsch vermutet. Und das hier scheint jetzt einer von denen zu sein, wo es tatsächlich reicht, den Browser zu aktualiseren, auch wenn das OS schon ein bischen veraltet ist.Ein Gegenbespiel ("We are aware of targeted attacks in the wild abusing this flaw."): https://www.mozilla.org/en-US/security/advisories/mfsa2020-03/#CVE-2019-17026
Der aktiv ausgenutzte Bug erlaubt die Ausführung beliebigen JavaScript-Codes und ist - dank JavaScript - unabhängig vom darunterliegenden Betriebssystem.
DMZ von kommerziellen Sites, ja, da konnte man das machen. Überall sonst hätte man sich lange Begründungen für einen Emergency-Change ausdenken müssen (nur um dann gesagt zu kriegen, dass ausser der DMZ eigentlich eh nichts ins Internet exposed sein darf).Viele vernetzte Systeme können beim besten Willen keine drei Monate mit der Installation von Security-Fixes warten. Bis dahin wird schon längst auf breiter Front probiert, die Sicherheitslücken auszunutzen.
(Surfende Clients aka Arbeitsplatzrechner sind nochmal ne andere Geschichte.)
Im Grunde ja, da hast Du recht.Sollte die Konsequenz nicht heißen, grundsätzlich keine "Apfelkisten" zu verwenden?
Ich persönlich bin da ein bischen im Zwiespalt, weil ich einerseits die Apfelkisten mag - ich finde, man hat da genau das richtige gemacht und auf die Unix-Basis eine wirklich schöne Oberfläche gebaut (was eigentlich jeder hätte tun können) - andererseits aber den elitären Dünkel dieses Shops nicht mag, und auch selber keine solchen Kisten verwende, sondern sie eher für Leute im weiter vorgerückten Alter empfehle.
Quelle ist Ich. In der PostgreSQL mailinglist, und das Stichwort ist "zwanzig Zeilen Shellscript".Quelle?
Ja. Nein. Genau darum ging es. pg_dump ist die eine Sache, das kann man immer machen, damit kriegt man eine einzelne Datenbank in eine Datei exportiert.Du solltest die laufende Datenbank natürlich mit den Datenbank-eigenen Bordmitteln sichern (mysqldump, pg_dump etc.). Alles andere (inklusive ZFS-Snapshots) produziert inkonsistente Backups. Damit können die meisten Datenbanken dank WAL und andere Mechanismen umgehen, ist aber trotzdem grob fährlässig.
Das interessantere sind die WAL. Ich hab das gelernt weil es mit Oracle bei den Banken immer so gemacht wird, und Postgres kann das auch. Die redologs, oder WAL, enthalten ein Journal mit sämtlichen Veränderungen der Datenbank. Wenn du also irgendeinen Filesystem-Backup hast, und sämtliche WAL seit dem Beginn dieses Filesystem-Backup, dann läßt sich die Datenbank damit nicht nur wiederherstellen, sondern an jeden beliebigen späteren Zeitpunkt positionieren. Und das ist völlig korrekt und sauber - vorausgesetzt die WAL enthalten dafür genug Info, man wirft nichts durcheinander und verliert nie auch nur ein einziges WAL.
Und deswegen, weil das eben ein bischen kritisch ist, sagen die postgres-Leute, man kann zwar solche Backups machen, aber man soll dazu den Filesystem-Backup (oder ZFS-snapshot) zunächst auf eine extra Platte schreiben, alle relevanten dazugehörigen WAL mit dazuschreiben, und dann von diesem Zeug nochmal einen gebündelten Backup erstellen der dann sicher alles enthält was man zum wiederherstellen braucht.
Ich mach es anders - ich schreibe kontinuierlich jedes WAL gleich nach seiner Freigabe direkt ins Backup (die besagten zwanzig Zeilen Shellscript), und mache gelegentlich ein Filesystem-Backup dazu. Damit habe ich auch alles Erforderliche gesichert. (Und ich schreibe in zwei unabhängige Backup-Systeme plus ein drittes in der Cloud, also drei separate Instanzen.) Aber da heißt es, das wäre nicht professionell (und mit zwanzig Zeilen Shellscript geht es schon gleich überhaupt nicht, weil sowas darf ja nicht sein).
Irgendwann geb ich's dann halt auf, und denke mir: auf dem heutigen Niveau wären wir niemals zum Mond geflogen.
Wo ist die denn beim Tesla? wegduckNachdem IT-ler in der Gesamtbevölkerung nur einen kleinen Anteil ausmachen, ist im Bereich Browser der DAU tatsächlich der Standard.
Um bei Autovergleichen zu bleiben: wer hier im Forum ist beim Auto kein DAU und könnte ad hoc eine Zylinderkopfdichtung tauschen?
Im Grunde kann man sowas machen. Und es hat die zusätzliche Schönheit, dass man nicht mehr um Change-Genehmigungen betteln muss, sondern umgekehrt einen Issue bekommt wenn es nicht glatt funktioniert.Meine üblichen Betriebssystem-Updates in Produktion laufen folgendermaßen:
Gib es irgendwo oben in der Liste ein Problem oder zeigt das neue Image in der Produktion eine erhöhte Fehlerrate, wird das Deployment automatisch rückabgewickelt und ein Admin benachrichtigt, der es sich anschaut.
- CI-Server erkennt eine neue OS-Version
- Neues Base-Image wird gebaut, konfiguriert und in der Testumgebung ausgespielt
- Automatische Tests laufen gegen die Testumgebung
- Neues Image wird via Rolling Update in Produktion ausgespielt und via Monitoring automatisiert beobachtet