Solaris Patchday: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| Zeile 7: | Zeile 7: | ||
! Datum !! Uhrzeit !! Zonen-Server !! Dienste | ! Datum !! Uhrzeit !! Zonen-Server !! Dienste | ||
|- | |- | ||
| 16. | | 16.10.2013 || 20 Uhr - 8 Uhr || Oplopanax || | ||
addb | addb | ||
addb-test | addb-test | ||
| Zeile 34: | Zeile 34: | ||
yetanothermoodle | yetanothermoodle | ||
|- | |- | ||
| | | 20.10.2013 || 20 Uhr - 8 Uhr || Davidia || | ||
baobab | baobab | ||
brunelleschi | brunelleschi | ||
| Zeile 56: | Zeile 56: | ||
voss | voss | ||
|- | |- | ||
| | | 21.10.2013 || 20 Uhr - 8 Uhr || Nolina || | ||
ate | ate | ||
cgpro-test | cgpro-test | ||
Version vom 16. Oktober 2013, 05:57 Uhr
Auf dieser Seite finden sie Informationen zum aktuellen Solaris Patchday.
Der nächste Patchzyklus im Solaris-Umfeld findet ab dem 16.7.2013 statt. Bei folgenden Diensten kann es in dem angegebenen Zeitraum zu Ausfallzeiten kommen, da die Host-Systeme nicht im Cluster laufen.
| Datum | Uhrzeit | Zonen-Server | Dienste |
|---|---|---|---|
| 16.10.2013 | 20 Uhr - 8 Uhr | Oplopanax |
addb addb-test alumni-entwicklung alumni-test cib di dirback directory-test et-korrektur forum fupp hickory ip-board klaus kn-hans mathe-online miyuki moodle22test moodle2test odsimpl opencure-test solaris-admins-proxy studyguru webregis-test-his yetanothermoodle |
| 20.10.2013 | 20 Uhr - 8 Uhr | Davidia |
baobab brunelleschi ftp kds-desel kds-unger kernel-config kiss lg-es mobile-moodle online-uebungssystem-test oracle-public propra-test redwood server-zmi stheno svn-kn toolbox-neu translator ucg voss |
| 21.10.2013 | 20 Uhr - 8 Uhr | Nolina |
ate cgpro-test contici delfi2008 directory dna dvt-korrektur imperia-test install kn-solaris-test mentorendb mentorendb-test mysql mysql-entwicklung plane2 (podcasts) poplar praktikum-et praktikum-et-test reiko se-korrektur sloauskunft spruce subversion-zmi teamwork transfer utilities webregis-test |
Alle anderen Dienste laufen auf Cluster-Systemen bestehende aus zwei Nodes. Hier sind nur Ausfallzeiten im Rahmen eines Schwenken des Dienstes auf den anderen Cluster-Node zu erwarten. Der Schwenk auf den anderen Cluster-Node kann von den Produktverantwortlichen selbst zu einem beliebigen Zeitpunkt durchgeführt werden. Die Produktverantwortlichen werden per E-Mail informiert.