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.
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.
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.
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:
Es kann natürlich sein, dass alles viel zügiger voran geht, in diesem Fall sind wir natürlich vor 11Uhr wieder da :-)
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.
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.
Nur so als Notiz: Ich bin nächste Woche (KW17) im Urlaub. Auch das Service Center wird in diesem Zeitraum geschlossen sein.
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.
Aus welchen Gründen auch immer, haben sich in den letzten Tagen vermehrt Probleme mit der Anmeldung am Poolclient ergeben. Der Rechner verweigerte schlicht die Anmeldung. Nachdem ich das auf mehreren Rechnern verifizieren konnte, habe ich vermutlich die Ursache gefunden: nslcd Dieser Daemon ist zuständig für die Anfragen gegen den LDAP. Soll heißen, der schaut nach, ob es User X im LDAP gibt. Genau dieser Daemon wird beim booten nicht korrekt gestartet, wegen dubioser Fehlermeldungen bezüglich der libcrypt11 Bibliothek. Fragt man Google, sind wir da nicht die Einzigen, mit dem Problem. Der Eintrag und einige andere sind schon älter, aber er betrifft uns jetzt. Vermutlich hat eins der zahlreichen Updates uns dieses Problem eingebrockt :-/
Die Lösung sieht derzeit so aus, dass ich nslcd aus dem alten Init herausgenommen habe und dafür eine passende Systemd Konfiguration erstellt habe:
[Unit] Description=LDAP connection daemon After=syslog.target network.target [Service] EnvironmentFile=-/etc/default/nslcd Type=forking PIDFile=/var/run/nslcd/nslcd.pid ExecStart=/usr/sbin/nslcd Restart=always RestartSec=2s [Install] WantedBy=multi-user.target Alias=nslcd.service
Systemd sorgt nun dafür, dass der Daemon gestartet wird, sobald der sich verabschiedet hat. Wenn es noch Probleme geben sollte ... ihr wisst ja, wie ihr mich erreichen können ;-)
Das Kopieren der Daten hat zwar geklappt, aber der Bootloader Grub hat sich bei der Installation verweigert :-/ Das Ursache habe ich mittlerweile gefunden. Daher starte ich heute einen zweiten Versuch gegen 21Uhr. Wenn dieses Mal alles klappt (rsync muss noch einmal komplett durchlaufen, um aktuelle Änderungen mitzunehmen), dürfte die Downtime bei 30 Minuten liegen.