CPK berichten worden initieel ook gemaild naar de CPK mailing lijst, je kunt je abonneren (of afmelden) via deze link. Je kunt ook een RSS reader gebruiken om op de hoogte te blijven van de storingen, zie de link met het RSS icoon in de titel van deze pagina. Bij langdurige storingen wordt de CPK op deze website bijgewerkt.
Kijk op meldingen.ru.nl voor RU brede storingen.
Ceph filesystem storing. De services voor het ceph filesystem weigeren op te starten. Ontbreken van die services maakt toegang tot files op Ceph onmogelijk. We hebben contact met onze supportpartij 42on. Duur van de storing is onbekend Update 2024-01-22 We zijn bezig met 42on om het probleem op te lossen, er is vandaag overleg om 17:00. Update 2024-01-23 Een eerste dentry_recover is succesvol verlopen en volgens 42on zijn de Ceph journals nog goed....
Op 10 december 2023 was het GitLab TLS certificaat verlopen. Er is toen een nieuw certificaat gegenereerd zonder een goede certificate chain. Voor browsers is dat geen probleem, maar andere GitLab componenten (registry, runners) konden daardoor geen goede connectie naar GitLab opzetten. Op maandag 11 december 2023 zijn alle certificaten vernieuwd via Let’s Encrypt, die ook zorg draagt voor een automatische vernieuwing.
Jitsi (of eigenlijk de interne prosody service) had een oud certificate, waardoor de service na de normale reboot niet meer wilde starten. Na het vervangen van het certificate en een service restart werkte het weer.
Na het onderhoud aan de centrale routers was er een probleem met de routering van verkeer naar buiten van de servers die aan de 25 Gbit/s infrastructuur zitten. RU Connectivity kan het fiksen als het probleem optreedt door de link naar ons netwerk te resetten, en heeft de netwerkleverancier benaderd om dit probleem op te lossen. Uiteindelijk is het mogelijk gebleken om een statische route te zetten naar ons netwerk, waardoor de verbinding in stand bleef....
Sommige mensen konden niet meer inloggen, de server was niet stabiel meer, waardoor deze gereboot moest worden. Helaas is daarbij vergeten dat de jupyterhub service nog handmatig gestart moest worden, waardoor de overlast ruim een uur heeft geduurd in plaats van een paar minuten. Inmiddels loopt alles weer. We werken aan een oplossing voor dit reboot probleem.
Een tikfout in de DHCP-configuratie had tot effect dat sommige netwerk pc’s geen IP-adres kregen toen ze aangezet werden en dat andere, waarvan de lease van het IP-adres verlopen was, hun IP-adres verloren en daarmee de toegang tot het netwerk. We zullen het proces verbeteren zodat een tikfout in de toekomst de DHCP-server niet meer down brengt.
Na een geplande herstart van de machine waarop jupyterhub draait, startte jupyter niet correct op. De service startte na het aanroepen van een handmatig startcommando. De maatregelen die zijn genomen om dit terugkerend probleem te verhelpen, zijn niet afdoende gebleken.
Door een fout werd de DNS zone z.science.ru.nl niet goed gegenereerd, daardoor waren er geen shares beschikbaar. Door extra te testen proberen we dit in de toekomst te voorkomen.
De router voor de meeste Science services moet dringend gereboot worden. De reboot wordt ’s ochtends vroeg uitgevoerd. Mocht de reboot mislukken, dan is ILS Connectivity op de campus om het op te lossen.
Sinds enige tijd bestaat een directe afleveringsroute van mails vanuit Microsoft Exchange Online Protection (MS EOP) naar de Science mailomgeving (via mx4). Toen daar een extra mail exchange server bij is gezet (namelijk mx5) is vergeten die te testen in samenhang met onze mailman server (zaaivm). Zodoende was het mogelijk dat aangeleverde mail, vanuit @ru.nl adressen, werd gebounced met de melding ’not accepting messages'. De fout is ontdekt en hersteld zodat de zaaivm nu ook op de hoogte is van het bestaan van de mx5....