Größe: 4527
Kommentar:
|
Größe: 2816
Kommentar:
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 1: | Zeile 1: |
#acl All:read WikiGroup:read | #acl FlorianDufner:read,write All:read WikiGroup:read |
Zeile 5: | Zeile 5: |
* aktuell keine. * Es gibt einen Bug in einem aktuellen Patch von Sun. Der Fehler wurde hier http://forums.sun.com/thread.jspa?threadID=5420594&tstart=0 von mir aufgezeigt. Inzwischen hat sich jemand von Sun gemeldet. Es wird hoffentlich bald eine Verbesserung geben. Wir sind aktuell aber nicht mehr von dem Problem betroffen. Wenn eine verbesserte Version des Patches kommt, wird er wie normal alle Patches irgendwann nachts eingespielt (sagen wir mal zwischen 1 und 3 Uhr). -- [[root]] <<DateTime(2009-12-18T18:26:24Z)>> * Ein Patch Manager von Sun hat sich jetzt mit dem Ergebnis gemeldet das der Patch als "BADPATCH" zurück gezogen wurde. Es sollte also keine neuen Admins in die Falle tappen. -- [[root]] <<DateTime(2009-12-18T19:34:50Z)>> |
* Donnerstag 14.1.2010 oder Freitags 15.1.2010 zwischen 3-4 morgens werden Patches eingespielt. Betroffene Dienste: alle. * Im Laufe des Mittwochs, 14.1.2010: Um einen Fehler zu beheben und einen Bugfix zu testen wird ein Patch für den Dienst Wiki eingespielt. Der Dienst wird kurz nicht verfügbar sein (< 1 Minute). Und alle Sessions in allen Wikis werden danach ungültig sein, d.h. alle Nutzer müssen sich neu einloggen. |
Zeile 11: | Zeile 10: |
== Wochen Plan == * Unter https://wiki.asta.uni-ulm.de/computer/FlorianDufner/WochenPlan finden sich versuchsweise regelmässige Berichte was ich gerade so beim Computerreferat plane/mache. -- [[root]] <<DateTime(2010-01-13T14:41:43Z)>> |
|
Zeile 13: | Zeile 15: |
* keine reproduzierbaren mehr * Es gab mehrmals Probleme mit alten Cookies. Benutzer konnten sich erst dann persistent einloggen wenn die alten Browser Cookies im Browser gelöscht wurden. Das Verhalten liess sich aber leider nicht reproduzieren. Falls jemand so ein Problem hat, wäre ich bspw. an dem "kaputten" Cookie interessiert, dass man man bspw. mit AddOns wie Web Developer für Firefox auslesen kann. -- [[root]] <<DateTime(2009-12-14T06:02:16Z)>> * Wir haben ein offizielles Zertifikat für den Webserver mit den Wikis. Testweise ist der Zugang via https verpflichtend. Sollte das schwachsinnig sein oder Probleme machen freuen wir uns über Rückmeldungen. -- [[root]] <<DateTime(2009-12-14T12:30:41Z)>> * Im Vorgriff auf die Kommentare zu Datenschutz und Logging unter [[Benutzerordnung]] hab ich schon öfter überlegt was für verbindliche Aussagen man dazu überhaupt treffen könnte. Als ersten Schritt zu weniger Daten werden seit dem Update auf MoinMoin 1.9.0 keine IP Adressen oder DNS Namen mehr in den Revisionen angezeigt. Ausserdem werden diese Daten für neue Veränderungen und Zugriffe an erster Stelle gar nicht mehr gespeichert. Dieser erste Schritt bezieht sich ausschließlich auf die Daten die innerhalb der Webapplikation Wiki anfallen. Es werden weiterhin IP Adressen in den Logs des Webserver gespeichert (auch für die Wikis). Da steht eine gute Lösug noch aus, die einerseits dem Datenschutz, aber andererseits auch der Ursachenforschung bei Problemen gerecht wird. -- [[root]] <<DateTime(2009-12-15T15:39:49Z)>> |
* Cookies bei den Wikis (Login funktioniert nicht): Bugfix vorhanden, wird demnächst eingespielt. Workaround: alle cookies für wiki.asta.uni-ulm.de einmalig löschen . |
Zeile 24: | Zeile 22: |
* Wir haben ein offizielles Zertifikat für den Webserver mit dem DVS2 (http://druck.asta.uni-ulm.de). Testweise ist der Zugang via https verpflichtend. Sollte das schwachsinnig sein oder Probleme machen freuen wir uns über Rückmeldungen. -- [[root]] <<DateTime(2009-12-14T13:14:35Z)>> | * keine Probleme bekannt |
Wartungsarbeiten
- geplante Wartungsarbeiten:
- Donnerstag 14.1.2010 oder Freitags 15.1.2010 zwischen 3-4 morgens werden Patches eingespielt. Betroffene Dienste: alle.
Im Laufe des Mittwochs, 14.1.2010: Um einen Fehler zu beheben und einen Bugfix zu testen wird ein Patch für den Dienst Wiki eingespielt. Der Dienst wird kurz nicht verfügbar sein (< 1 Minute). Und alle Sessions in allen Wikis werden danach ungültig sein, d.h. alle Nutzer müssen sich neu einloggen.
Änderungen und Infos zu bestimmten Diensten
Wochen Plan
Unter https://wiki.asta.uni-ulm.de/computer/FlorianDufner/WochenPlan finden sich versuchsweise regelmässige Berichte was ich gerade so beim Computerreferat plane/mache. -- root 2010-01-13 16:41:43
WWW: Wikis
- bekannte Probleme:
- Cookies bei den Wikis (Login funktioniert nicht): Bugfix vorhanden, wird demnächst eingespielt. Workaround: alle cookies für wiki.asta.uni-ulm.de einmalig löschen .
Die bisherigen AdminNachrichten pro Wiki gibt es in Zukunft an einer zentralen Stelle (nämlich hier). Wo sinnvoll wurde das in den einzelnen Wikis bereits angepasst. Zentral wird von der Wiki Übersichts Seite hierher verlinkt. -- root 2009-11-28 05:14:46
WWW: DVS2 (Druckreferat)
- keine Probleme bekannt
Mailing
- Bei unseren Mailinglisten, die ja auf den System des kiz betrieben werden, gibt es zwei-drei problematische Features:
- Die Header Zeile "X-No-Archive" wird bei der Archivierung im Archiv der Liste berücksichtigt. Mitunter fügen Abonennten diese allgemein in alle ihre Mails ein, diese werden damit nicht archiviert.
- In Mails die über eine Liste weiterverteilt werden (an die Abonenten) wird diese Zeile nach dem Archivieren auf der Liste ebenfalls eingefügt. Konkret führt das dazu das Mails die über eine Liste an eine weitere Liste gehen nur auf der ersten archiviert werden.
- Empfänger erhalten bei normalen Versandzeiten Mails die sie über mehrere lokale Wege erhalten nur einmal ausgeliefert.
- In Kombination bedeutet das, dass man als Abonnent im Extremfall nicht nachvollziehen kann, ob eine Mail verteilt wurde. Sie findet sich weder im Archiv einer Liste noch erhält man die Mail separat über die Liste mit einem evt. Markierung im Thema [Referat].
- Bisher haben wir zu den folgenden Punkten realistische Wünsche bzw. Anfragen auf Konfigurationsänderung / Software Update beim Thema Mailinglisten angefangen:
- Konfigurierbarkeit des Verhaltens bei X-NO-ARCHIVE Headern.
- Archivierung von Mails mit anderem encoding (z.B. utf8) so dass Umlaute immer lesbar sein sollten.