20.1.2010
Im Unterschied zum letzten mal hat es seit dem letzten Bericht fast überhaupt nicht geklappt auch nur ansatzweise die eingeplanten Ziele anzugehen. Zuerst gab es viele Anfragen, dann gab es ein paar Sachen bei MoinMoin zu tun. Teilweise fand ich es etwas nervig das es soviele Fragen gab. Global hat das nicht weitergeholfen. Wenn die Referate und die SL aber einfach so irgendwas machen, kann es schwieriger sein, das im nachinein wieder zu verbessern.
Erledigte Punkte vom letzten Bericht
- Updates
Ich hab gestern vergessen das phpmyadmin auch ein Update braucht.
Erledigte Punkte
MoinMoin
- Nach zwei Fehlerberichten von uns und weiteren Berichten von anderen wurde das Session Handling etwas umgebaut. U.a. wird bei den Sessions jetzt der Verfall gespeichert.
Da sich ausserdem der Aufbau der Cookies prinzipiell verändert hat mussten einmalig alle Session neu gemacht erstellt werden. Für die ganze Funktionalität hat es sich auch angeboten veraltete Sessions zu löschen. Am schönsten wäre es das automatisiert zu machen. Allerdings müsste dann bei jedem Aufruf die Liste aller Sessions durchgegangen werden. Da es da keine skalierende Lösung gab wurde die Funktion ausgegliedert. Beim Testen war es noch etwas unkomfortabel, da alte Session zu einem harten Abbruch führten. Dazu gab es dann einen Fehlerbericht von uns: http://moinmo.in/MoinMoinBugs/190WithMaintCleansessionsChangesetUncomfortable und einen Patch der das Problem abfängt. Der Patch wurde gleich getestet, da ein neues Release bald geplant war.
Einige Probleme beim Umgang mit Sessions wurden auch zurück an die Toolkit Entwickler gegeben (MoinMoin verwendet inzwischen das Python Toolkit Werkzeug).
- Das Release kam dann auch bald. Ich hab dementsprechend gestern auf 1.9.1 aktualisiert. Beim Update sind ein paar Punkte aufgefallen. Das meiste hab ich gleich angepasst. Ein paar Punkte müssen noch gemacht werden. Ein Update braucht etwa: 30 Minuten um Anpassungen und Änderungen durchzusehen, 50 Minuten für das Backup, 30 Minuten für das Update selbst und 1 Stunde für neue Suchindizes. Gerade beim Backup ist die Frage ob das nicht schöner und schneller mit Snapshots umsetzbar ist.
sonstige Updates
- Für Solaris gab es ein paar Patches die keinen Reboot benötigt haben. sun und moon haben die gleich alle bekommen.
/etc/profile und quota
Beim Update von MoinMoin ist aufgefallen, dass der Login von Nicht-root Benutzern auf einmal unverhältnismässig lang geht. Der Vorgang hielt sich mit "quota" auf. Mit irgendeiner Umstellung oder einem Patch muss sich das Verhalten geändert haben. Meine Vermutung wäre das Update von zfs auf user/groupquotas. Vllt. benötigt quota viel Zeit um über alle zfs Filesystem zu iterieren. Vorläufig ist die quota Abfrage in /etc/profile aus gestellt. Da wir momentan gar keine Quotas verwenden, hat es keine realen Auswirkungen. Dennoch sollte dafür ein Ticket bei Sun gesucht oder aufgemacht werden. (Wieder zurück gestellt. Problem gefunden
)
Anfragen
- Ein neues Mitglied für die Admin Stammtisch Liste.
Eine Frage zum Hosting von grossen Dateien.
Die einfachste Lösung für das Problem war der bestehende Service über das kiz ( ~/public_html beim kiz findet sich unter http://www.uni-ulm.de/~login ) .
Diverse Mails zur Wartung des Multifunktionsgeräts im AStA Büro.
Eine Frage wegen Datenschutz und dem Dienst Wiki vom AK FS Hiwis.
Eine Anfrage zur maximalen Grösse von Mails über Mailinglisten.
Theoretisch sollten nach dem neuen Konzept alle Erkenntnisse für die Zukunft dokumentiert werden. Ich werde alle darum bitten und die Punkte dann abhaken.
Offene Punkte
snapshots von /srv/www zusätzlich und als Basis für das Backup
- Dokumentation wie man das Rollback macht
snapshot von /opt nötig ? (Nein, da die alte Installation unter /opt/moin_old/ erhalten bleibt.)
- reguläre Ausdrücke in der Wiki-Farm Konfiguration und die Abarbeitung aller Farmen per Skript
Umstellung der Reihenfolge beim Update (16<->17)
altes /opt/moin löschen
Das Logo für einige Referate ging nicht mehr ( drawing wurde falsch verwendet, besser ist attachment )
gfind . -path "*-wiki/*" -type f -path "*underlay*" -prune -o -print0| gxargs -0 grep -i "{{drawing:"
Zwei für uns sinnlose Aktionen wurden deaktiviert (Despam, WikiSync).
Mir ist erst jetzt aufgefallen das nur englische Category* Seiten als Kategorie erkannt wurden. Ich hab den regulären Ausdruck auf deutsch und englisch angepasst. Es war jedoch nötig danach den Index neu zu machen.
Für die Logins bei denen "Speichere Login-Informationen" nicht an ist, ist die Lebenszeit der Cookies jetzt 1 Tag. Standardmässig ist die Option jedoch an und die Cookies verfallen erst in sehr ferner Zukunft.
Wegen langer Zeit für quota recherchieren.
Nach dem ich mal den Netzwerkverkehr belauscht habe wurde klar, dass das eine Regression der neuen Firewall Regeln ist (siehe 2010-01-14 ). Es werden weitere Ports benötigt (um hier unsinnigerweise quotas zu bearbeiten). Die Frage ist dann nur wie man denn nun genau raus finden kann was für Ports für NFS verwendet werden bzw. welche Version bei einer konkreten Relation verwendet wird.
- zfs / nfsv4
- Dokumentieren wie Filesysteme von moon nach sun kommen.
Testen was das Backup macht wenn moon "weg" ist.
Mit NFSV4 sind nur harte Mounts möglich. Standardmässig hängt sun also im Backup (oder einem anderen NFS Zugriff) fest wenn moon weg ist. In der dsm.sys lässt sich jedoch eine Timeout einstellen, der auch funktioniert. http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/com.ibm.itsmfdt.doc/ans50000335.htm
Das Backup ist dann zwar mit 25 Minuten statt 2 Minuten sehr zäh, aber es hängt nicht unendlich und es gibt sogar eine sinnvoll Fehlermeldung, die wir mitbekommen.
Was für Ports werden für NFS verwendet bzw. welche Version wird bei einer konkreten Relation verwendet? (Insbesondere quota zum cdserv vom kiz aus stellen.)
- Mit vers=x kann man die Version fest klopfen. Komischerweise wird aber auch bei vers=4 eine Verbindung zum Port 111 UDP auf dem NFS Server aufgebaut (und zwar von svc:/network/nfs/rquota:default ). Mit noquota als Mount Option bekommt man auch das abgestellt. Was die Linux Clients dazu sagen wäre noch interessant.
- moon
- viel mehr Doku schreiben wie man die kiz Installation anpasst
- /net entfernen
- Überlegen in welcher Reihenfolge es Richtung funktionierendes LDAP/NFS sinnvoll weitergeht.
Bei den Formularen unter http://www.asta.uni-ulm.de/formular/ kann es leicht passieren das Links ins Wiki durch Wiki Edits ins Leere führen. Wir sollten das Problem per cron job mit bekommen.
und noch eine cron job Familie für mehrzeilige Ergebnisse verbessert
kaputte Links entfernt
MatthiasWeber wegen der Formulare angeschrieben
- Inzwischen kam ein Rundschreiben zu den Notstrom Tests in 2010: 07.04.2010 und 06.10.2010 (5-6 Uhr)
Es wäre schick dafür auch einen cron job zu haben. (Allerdings muss man die Daten manuell eingeben, die Webseite ist nicht trivial automatisiert verarbeitbar.)