Größe: 3867
Kommentar:
|
Größe: 3256
Kommentar:
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 6: | Zeile 6: |
* Am 8.12.2009 gab es von 10:00-11:30:37 Probleme beim Dienst "Wiki" bzw. keinen Zugang dazu. Wir haben ein Software Update gemacht. Leider waren wesentlich mehr Schritte bei dem Update nötig als in der Dokumentation aufgeführt. Wohl wieder ein Fall für einen Bug Report. Hoffentlich läuft alles mit der neuen Version schön sauber, sonst braucht es wieder ein Wartungsfenster. -- [[root]] <<DateTime(2009-12-08T10:48:30Z)>> * Tatsächlich gab/gibt es noch Probleme. Zur Vergangenheit gehört von jetzt an hoffentlich das Problem das man sich pro Seite neu anmelden muss. Es gibt einen Workaround der gemeinsam mit den Entwicklern gefunden wurde. Wahrscheinlich wird es in der nächsten Version permanent gelöst. Noch ungelöst ist dagegen das die Hilfe Links die beim Editieren angezeigt werden nicht immer in das Wiki zeigen in dem man gerade ist. -- [[root]] <<DateTime(2009-12-09T21:49:48Z)>> * Der Zugang via https geht jetzt wieder. Für die Zukunft wird die Wartungsnachricht für Nutzer immer angezeigt und unsere Tests laufen separat. -- [[root]] <<DateTime(2009-12-08T12:55:43Z)>> |
|
Zeile 11: | Zeile 8: |
* bekannte Probleme: * 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)>> |
|
Zeile 12: | Zeile 13: |
Zeile 13: | Zeile 15: |
Wartungsarbeiten
- geplante Wartungsarbeiten:
- erstmal keine mehr
Änderungen, Infos zu den Wikis
- bekannte Probleme:
- 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 2009-12-14 08:02:16
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
Beim Editieren erscheint ein Knopf für "Rechtschreibung prüfen". Bisher waren hier relativ wenig Worte hinterlegt. Die verwendete Wortliste wurde stark erweitert (deutsch/englisch). -- FlorianDufner 2009-11-27 08:05:05
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.
Pläne für die Zukunft
Bereits jetzt ist der Zugriff auf die Wikis und das DVS2 auch gesichert über https möglich. Man kann das ganz einfach testen in dem man bei den konventionellen Links das http durch https ersetzt, oder auf https://wiki.asta.uni-ulm.de bzw. https://druck.asta.uni-ulm.de startet. Jedoch ist das verwendete Zertifikat bisher selbst-signiert. In Zukunft sollen die Zertifikate so siginiert sein, das die üblichen Browser sie bereits akzeptieren. -- root 2009-11-28 05:14:46
Ob https nach einer Testphase dann optional oder obligatorisch sein soll wird dann entschieden. -- root 2009-11-28 05:14:46