Newsletter Januar 2018
2017 ist Geschichte, 2018 noch jung.
Hallo,
2017 ist Geschichte, 2018 noch jung. An dieser Stelle zuerst einmal ein frohes, gesundes und erfolgreiches Jahr 2018 an unsere Leser!
Während man eigentlich noch damit beschäftigt ist, den Feiertagsschmaus zu verarbeiten, schlagen Neuigkeiten aus der digitalen Welt
schon wieder hohe Wellen: ein gravierender Fehler droht zum Problem für viele IT-Systeme zu werden. Diesmal liegt der Ursprung aber nicht in der Software, sondern in den Prozessor-Architekturen selbst. Workarounds auf Betriebssystem-Ebene sind in Vorbereitung oder verfügbar. Natürlich behandeln wir das Thema in unseren GONews. Aber es gab und gibt auch noch weitere spannende Themen für den Einstieg ins Jahr 2018.
Viel Spaß mit den GONews!
Alfred Schröder
Geschäftsführer
Inhalt
- Gravierender CPU-Bug
- Automatisierung als Schlüssel zur modernen IT-Infrastruktur
- Chemnitzer Linux-Tage
- Arena zur Bügermeisterwahl in Arnsberg
- Tipp des Monats
Gravierender CPU-Bug
Das neue Jahr beginnt aus sicherheitstechnischer Sicht leider nicht so optimal. In den letzten Tagen wurde veröffentlicht, dass alle modernen CPUs einen Fehler enthalten, aufgrund dessen unter Linux, Windows und auch MacOS auf Daten im Arbeitsspeicher zugegriffen werden kann. Das Thema als solches ist komplex und vielschichtig, sodass aktuell noch nicht für alle Linux-Systeme Patches verfügbar sind.
Sobald ein Patch für Ihre Distribution angeboten wird, empfehlen wir Ihnen dringend ein Update. Unsere Kunden mit Wartungsverträgen werden wir dann umgehend benachrichtigen.
Lesen Sie hier: Metdown und Spectre
Automatisierung als Schlüssel zur modernen IT-Infrastruktur
IT ist häufig geprägt von Buzzwords. Auch im letzten Jahr war das nicht anders. Von Cloud bis Container gab es viele Schlagworte zu hören. Wirklich wichtig ist aber bei allen Ansätzen der Trend zu einer immer stärkeren Automatisierung. In diesem Bereich ist Open Source wirklich stark, und wir haben eine Menge Erfahrungen in diesem Umfeld sammeln dürfen.
Mehr dazu in unserem Artikel auf unserer Website: Automatisierung als Schlüssel zur modernen IT
Chemnitzer Linux-Tage
GONICUS ist Sponsor der Chemnitzer Linux-Tage am 10. und 11. März 2018.
Weitere Informationen rund um die Messe finden Sie hier: Chemnitzer Linux-Tage 2018
Arena zur Bügermeisterwahl in Arnsberg
Für unsere Arnsberger Leser ist das folgende Event interessant. Das Digitale Forum Arnsberg veranstaltet im Vorfeld der Bürgermeisterwahl eine Wahlkampfarena mit allen vier Bürgermeisterkandidaten im Kaiserhaus in Arnsberg-Neheim. Am 16. Januar 2018 ab 18 Uhr stellen sich die Kandidaten den Fragen zum Thema Digitalisierung.
Melden Sie sich gerne hier oder über info@digitales-forum-arnsberg.de an.
Den Trailer zur Veranstaltung finden Sie hier: Trailer Wahlarena DFA
Tipp des Monats
Hohe Load ohne ersichtlichen Grund
Manchmal begegnet einem das Problem, dass ein Server eine unverhältnismäßig hohe Load hat, der Server aber augenscheinlich ohne Einschränkungen normal zu funktionieren scheint. Die Tools top, htop oder ps zeigen keine erhöhte Load einzelner Prozesse an, auch iotop, sar oder iostat zeigen keine signifikante Plattenaktivität, die die Load auch hochgehen lässt. Das Backup läuft nur nachts und nicht jetzt, kurzum: der Server langweilt sich, warum also die hohe Load?
root@linux:~# uptime
11:51:46 up 131 days, 44 min, 3 users, load average: 131,00, 131,01, 131,05
root@linux:~#
Normalerweise kann das nicht sein, also sehen wir uns die Prozesse einmal genauer an. Im konkreten Fall hatten wir viele Prozesse mit dem Status “D”, bei genauerer Betrachtung fällt auf, es sind 131 Stück, genausoviele wie unsere Load hoch ist. Natürlich ist das kein Zufall.
root@linux:~# ps axl | awk ‘$10 ~ /D/’ | wc -l
131
root@linux:~#
Die Stati der Prozesse sind natürlich fest definiert. “Z” bedeutet z.B. Zombie-Prozess, “S” ist Sleeping (der Normalzustand für Prozesse die meiste Zeit über) und “D” ist “uninterruptable sleep”. Das kommt z.B. vor, wenn ein Prozess darauf wartet, Daten auf die Festplatte wegschreiben zu können. Prozesse in diesem Status reagieren nicht großartig auf Einflußnahme von außen (wie z.B. den Versuch einen solchen Prozess zu killen). Das ist eine Sicherheitsmaßnahme und verhindert, dass Prozesse beendet werden, während sie noch Daten schreiben. Wenn aber durch unglückliche Umstände (oder deutlich häufiger: Programmierfehler bzw. schlechte Software) ein Prozess dauerhaft im Status “D” bleibt, dann kann man nicht viel machen außer rebooten. Für jeden Prozess im Status “D” wird die Load um 1 inkrementiert. Das ist eigentlich sogar ganz gut, denn sonst würde einem so etwas normalerweise nicht einmal auffallen. Echte Auswirkungen hat dieses Problem - ähnlich wie Zombies - allerdings nicht wirklich, außer vielleicht der Tatsache, dass die Load des Servers in der Zeit nicht zuverlässig überwacht werden kann.