Skip to content

Blog

Automatischer Shutdown der Poolrechner

Da in letzter Zeit mein Script nicht mehr so richtig wollte, um die Poolrechner um 19Uhr herunterzufahren, musste ich ein wenig umbauen. Normalerweise erfolgt das Herunterfahren via SSH vom Server aus. Wenn aber ein Client hängt ... hängt das Script :-/ Also habe ich ein Script erstellt, was vom Cron alle 15 Minuten aufgerufen wird, und den Poolrechner herunterfährt, wenn keiner am Rechner eingeloggt ist. Das betrifft natürlich nur den C-Pool. Um 19Uhr gilt das nicht, da werden die Poolrechner zum Shutdown gezwungen. Wenn nun also das Script nicht so arbeitet, wie getestet, dann meldet euch bitte, damit ich den Fehler suchen und korrigieren kann.

Java8 ausgerollt

Auf dem Poolimage habe ich jetzt noch "schnell" Java8 installiert. Ihr findet es als Link unter /usr/bin/java8.

Beim drucken von PDFs -> Leere Seiten

Seit der letzten Version von Iceweasel und Firefox tritt das Problem auf, das beim drucken von PDFs im Browser leere Seiten herauskommen. Das Problem ist bekannt (Google) und betrifft den internen PDF Viewer. Die einzige (derzeitige) Lösung besteht darin, die Datei mit einem externen Programm anzuschauen und zu drucken.

Desktop freeze

Wohl unabhängig vom DNS Problem scheinen die Poolrechner immer noch Schmerzen zu haben. Es ist leider sehr schwer zu debuggen. Es gibt einige Studenten die haben das Problem bereits wenige Minuten nach dem einloggen, andere arbeiten den Tag über durch. Ich habe bereits von autofs (für die $HOMES) auf die gute alte /etc/fstab umgestellt; "hal" rausgeworfen, der für einige Meldungen verantwortlich war, und nun habe ich im Boot Menü (das blaue Fenster nach dem Einschalten) unter "Tools" einen weiteren Eintrag hinterlegt (der bereits vorausgewählt ist), der als Init nicht mehr Systemd verwendet. Stattdessen wird wieder das alte /sbin/init aktiviert. Eventuell liegt da der Hase im Pfeffer (wir hatten ja gerade Ostern).

Wer also ebenfalls Probleme hat, sollte es mal mit diesem Starteintrag versuchen. Wenn es aber nichts ändert, bzw. es bleibt nun stabil -> Informiert mich !

Als nächstes (aber erst ab nächste Woche) tausche ich den Kernel und prüfe, wie ich die Nvidia Treiber und Nouveau (der freie Nvidia Treiber) parallel anbieten kann.

Wer noch Ideen hat ... immer her damit.

Probleme im Pool / DNS

Wir haben heute mal wieder massive DNS Probleme, weshalb vermutlich eine Menge Probleme im Pool auftauchen. Seit einiger Zeit testen "böse Menschen" das Uni Netz durch, um "anfällige" DNS Server zu finden. "Anfällige DNS Server" bedeutet konkret, dass die Server rekursive Anfragen von überall erlauben. Heißt: ein dig heise.de @{offener DNS} liefert die IP von heise.de. Wenn man nun nicht nur einen einzelnen Host abfragt, sondern ganze Netze, hat man eine sogenannte "DNS amplification" Attacke.

Da es einige Server im Uni Netz gibt die anfällig dafür sind (aber nicht RBG/ISP), und diese teils wiederum auf die HRZ DNS Server verweisen, haben die Kisten bei denen gut zu tun. Im Augenblick ist es sogar so, dass viele RBG Server nicht mehr gelistet werden, je nachdem welcher HRZ DNS Server per DHCP od. auf dem Poolclient befragt wird.

ISP/RBG besitzt selbst keinen eigenen DNS Server mehr, da für uns nur doppelter Verwaltungskram anfiel, ohne einen wirklichen Vorteil davon zu haben. Wir nutzen nur noch "dnsmasq" (DNS Caching Daemon), der wiederum auf die Server vom HRZ zeigt. Und damit wären wir wieder bei dem ursprünglichen Problem.

Als Workaround habe ich nun alle RBG/ISP Hosts in die /etc/hosts gepackt, sodass mit dem DNS 130.83.160.60 zumindest die RBG/ISP Server wieder erreichbar sind. Für die Poolclients gilt dies erst nach einem reboot.

Wartung am 2. Mai

Da ich Urlaub hatte, konnte ich den letzten Wartungstermin nicht nutzen. Daher werde ich den 2. Mai dafür verwenden anstehende Arbeiten durchzuführen. Dazu zählt die Aktualisierung des SAN Backends (ISCSI -> Open-E DSS7), Dateisystemchecks, und vor allem ein RAM Upgrade.

Dafür muss ich die gesamte RBG/ISP Server Infrastruktur herunterfahren.

Das bedeutet für diesen Zeitraum:

  • Kein E-Mail
  • Kein Poolbetrieb
  • Kein LDAP (wichtig für Fachgebiete, die unseren LDAP nutzen!)
  • Keine Mailinglisten

Es kann natürlich sein, dass alles viel zügiger voran geht, in diesem Fall sind wir natürlich vor 11Uhr wieder da :-)

SSL Zertifikate getauscht

Kurzer Hinweis: ich habe nun überall die SSL Zertifikate getauscht(Support/Mail/webmail..) und nebenbei die privaten Schlüssel von 2048 auf 4096Bit erhöht.

Auto Reset von Clientssh*

Den Studenten gelingt es regelmäßig die Clientssh1-3 VMs in einen unbenutzbaren Zustand zu versetzen, sodass kein SSH Login mehr gelingt. Bisher wurde die jeweilige VM von Hand resetet. Diese Aufgabe habe ich nun dem Monitoring System überlassen, da ich zum einen Urlaub nächste Woche haben, zum anderen die Resets in den letzten Wochen stark zugenommen haben. Die Resets erfolgen erst dann, wenn mehre Minuten kein Login möglich ist.

Urlaub KW17

Nur so als Notiz: Ich bin nächste Woche (KW17) im Urlaub. Auch das Service Center wird in diesem Zeitraum geschlossen sein.

Poolimage auf SSD Raid1

Bisher lief das Poolimage nur auf einer einzelnen SSD Festplatte. Dank der QSL Mittel haben wir vergangene Woche aus der einzelnen Platte ein SSD Raid1 gebaut. Zwar hätte der ISCSI Failover Cluster dann einen Schwenk auf den zweiten Host getätigt (aka Spiegelung via DRBD) , aber das hätte nicht nur einen Schwenk für das Poolimage bedeutet, sondern für die gesamte RBG/ISP Infrastruktur. Durch die Erweiterung sind nun alle Festplatten in einem Raid Modus :-) . Zusätzlich ergibt sich ein höherer Datendurchsatz, dadurch das nun beide SSDs Daten liefern können. Dies ist insbesondere bei einem vollen Poolraum sehr nützlich.

Made with Material for MkDocs