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.
De volgende Science services worden achter EduVPN gezet. Dit houdt in dat als je toegang wilt houden je deze VPN moet gebruiken. DHZ/DIY SMTP (mail versturen) LILOs Webmail Als er vragen zijn of problemen met het opzetten van EduVPN, neem dan contact op met onze helpdesk.
We hebben het authenticatieproces voor login server lilo7 (lilo7.science.ru.nl) bijgewerkt als onderdeel van een test. Vanaf nu wordt je ~/.ssh/authorized_keys bestand op lilo7 genegeerd. Deze wijziging is bedoeld om te voorkomen dat slechte actoren gemakkelijk blijvende toegang kunnen krijgen. Het goede nieuws is dat we nu toegang kunnen verlenen tot lilo7 van buiten de voorheen zeer beperkte IP-bereiken. Om toegang te krijgen vanaf een nieuw IP-bereik, moet u ons voorzien van uw openbare SSH-sleutel en het IP-bereik waarmee u verbinding gaat maken....
Door omstandigheden gaat de Science VPN onmiddelijk uit. Zie dit nieuws artikel waar we eerst nog 1 december als uiterste datum noemde. Als er vragen zijn of problemen met het opzetten van EduVPN, neem dan contact op met onze helpdesk.
De webmail applicatle “Rainloop” is permanent uitgezet, omdat het open source project niet meer geupdate wordt. We hebben zelf niet de middelen om de veiligheid ervan in de gaten te houden of het project zelf over te nemen.
De RADIUS-service was tijdelijk niet beschikbaar na een automatische update van het FreeRADIUS-pakket. RADIUS wordt gebruikt voor authenticatie van Eduroam, OpenVPN en Vpnsec bij gebruik van Science-accounts. Het probleem werd automatisch opgelost toen onze RADIUS-configuratie naar de RADIUS-servers werd gepusht.
Door een CPU crash was de server milton onbruikbaar in de nacht van vrijdag op zaterdag, na een handmatige reboot werkte alles weer.
De fileserver die wij bushel noemen is vrijdagavond gecrashet om nog onduidelijke redenen. Vanaf toen tot de handmatige reboot waren alle shares op de server onbereikbaar. Alle shares van bushel: /vol/acfiles /vol/aerochem /vol/aggrgtindroplets /vol/akolkmandata /vol/albert /vol/amsbackup /vol/amscommon /vol/archivespruijt /vol/avance600 /vol/beevee /vol/bioniccell /vol/bio-orgchem /vol/bko /vol/boltje /vol/ccz /vol/cczhelpdesk /vol/cczsecr /vol/celbio1 /vol/celbio2 /vol/celbio3 /vol/chemprac /vol/chemstaff /vol/coastoffon /vol/cognac /vol/communicatie /vol/cursusdossiers /vol/desda /vol/devneurob /vol/diafragma /vol/dis /vol/ecogen /vol/ehef1 /vol/ehef2 /vol/ehef3 /vol/ehef4 /vol/epsylon /vol/femtospin /vol/frequencycomb /vol/fsr /vol/gissig /vol/gmi /vol/goudsmit1 /vol/goudsmit4 /vol/goudsmitoldusers /vol/grafting /vol/hafnerlab01 /vol/hafnerlab02 /vol/hafnerlab03 /vol/heatgenes /vol/heatyield /vol/hfml-backup /vol/hfml-backup2 /vol/hfml-backup3 /vol/hfml-backup4 /vol/hfml-backup5 /vol/highres /vol/honours /vol/huckgroup /vol/icis /vol/ifl-d1 /vol/imappdir /vol/imappdocs /vol/imappsecr /vol/immbureau /vol/immstaff /vol/impuls /vol/introcie /vol/invbio /vol/invbio2 /vol/isptinspec /vol/jupyter /vol/kaartenbak /vol/kangoeroe /vol/khaj /vol/korevaarstudents /vol/kuijperslab01 /vol/linova500 /vol/linova800 /vol/liquids /vol/mbaudit1 /vol/mbaudit3 /vol/mbaudit4 /vol/mbonderwijs /vol/mbsl /vol/mlf90 /vol/mlfalgemeen /vol/mlfsec /vol/modprspm19 /vol/molbiol /vol/morph /vol/mpcoldmollab /vol/mwstudiereis /vol/neuroinf /vol/neuroinf2 /vol/nmr500data /vol/nmrliquid400 /vol/nmrliquid500 /vol/nmrsolid000 /vol/nmrsolid300 /vol/nmrsolid400 /vol/nmrsolid600 /vol/nmrsolid850 /vol/nmrsolid950 /vol/nmrspectra /vol/oii /vol/olcii-archief /vol/olympus /vol/pcsm-share /vol/pcsoftmattersecr /vol/ppimm /vol/pracnat /vol/ruversatest /vol/sbs /vol/secrmolbiol /vol/sigma /vol/sigmacies /vol/snn3 /vol/snn4 /vol/soheto /vol/solids /vol/spacdata3 /vol/spectra /vol/spibdossier /vol/spm /vol/spm30cobp /vol/spm30febp /vol/spm30fecobp /vol/spm30mkdata1 /vol/spm30mkprojects1 /vol/spm30procobp23 /vol/spmdata3 /vol/spmdata4 /vol/spmdata5 /vol/spmdata6 /vol/spmdata7 /vol/spmexfoliation /vol/spmmagstm /vol/spmnanolab /vol/spmstaff /vol/ssi /vol/staff-hfml /vol/stroom /vol/studiereis2013 /vol/sucudo-transfer /vol/tartarus /vol/tf2devices /vol/thalia /vol/ucm /vol/unl /vol/uscm-ssi /vol/uscm-ssi-archive /vol/vsc /vol/vsc1 /vol/vsc10 /vol/vsc11 /vol/vsc12 /vol/vsc13 /vol/vsc14 /vol/vsc15 /vol/vsc16 /vol/vsc2 /vol/vsc3 /vol/vsc4 /vol/vsc5 /vol/vsc6 /vol/vsc7 /vol/vsc8 /vol/vsc9 /vol/vscadmin /vol/wiskalg /vol/wiskunde
Bij de introductie van Ubuntu 24.04 werd duidelijk dat zogenaamde uids/gids van gebruikers gewijzigd moesten worden als ze te klein waren en daarme in een gereserveerd deel van Ubuntu 24.04 zaten. Deze wijzigingen konden direct uitgevoerd worden op servers, omdat die altijd aan staan, maar hadden een workaround nodig op C&CZ beheerde Ubuntu client PC’s. Vandaag bleek dat deze workaround geen rekening hield met nieuwe accounts, d.w.z. eerstejaars studenten en nieuwe medewerkers konden geen gebruik maken van de Ubuntu client PC’s....
Gitlab pages was niet bruikbaar door een probleem met de onderliggende data service (S3). Het duurde even voordat we iets gevonden hadden wat het probleem oploste, door verwarrende logregels.
De storage voor gitlab pages, gebruikt via het S3 protocol, raakte in een storing, we weten nog niet precies waarom. Na het herstarten van verschillende servers in het storage cluster kwam alles weer op. Daarmee was ook het gitlab-pages probleem opgelost. update 20-08-2024 Rond 12:15 vandaag weer hetzelfde, binnen 20 min gefixt