CPK messages are initially sent to the CPK mailing list, you can (un)subscribe via this link. You can also follow the service interruption messages via RSS using the link in the title under the RSS icon. If the CPK takes more time to resolve, any updates are published on this website.
For RU wide service interruption see meldingen.ru.nl.
De following Science services will be placed behind EduVPN. This means if you want to have continued access, you must use this VPN. De volgende Science services worden achter EduVPN gezet. DHZ/DIY SMTP (mail sending) LILOs Webmail If you have questions are experience problems with setting up EduVPN, please contact our helpdesk.
We have updated the authentication process for login server lilo7 (lilo7.science.ru.nl) as part of a test. As of now, your ~/.ssh/authorized_keys file on lilo7 is ignored. This change is designed to prevent bad actors from easily gaining persistent access. The good news is that we can now grant access to lilo7 from outside the previously very restricted IP ranges. To gain access from a new IP range, you will need to provide us with your public SSH key and the IP range you will be connecting from....
Due to circumstances we are forced to shut the Science VPN with immediately effect. See this news article where we previously said this would happen on December the 1st. If you have questions are experience problems with setting up EduVPN, please contact our helpdesk.
The webmail interface called “Rainloop” has been permanently shut down, due to the upstream project not being maintained anymore. We don’t have the resources to fix security issues or take over the open source project ourselves.
The RADIUS service was temporarily unavailable after an automatic update of the FreeRADIUS package. RADIUS is used for authentication of Eduroam, OpenVPN, and Vpnsec when using Science accounts. The issue was automatically resolved when our RADIUS configuration was pushed to the RADIUS servers.
Due to a CPU crash, the milton fileserver was down overnight. After a manual reboot the server was ok again.
The fileserver we call bushel crashed for as yet unknown reasons on Friday evening. From then until the manual reboot, all its shares were down. All affected shares: /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
With the introduction of Ubuntu 24.04 by C&CZ, it turned out that the uids/gids of some users had to be changed because they were too small. This was immediately rolled out on servers, since those are always powered on, but needed a workaround on Ubuntu client PCs. Today it became clear that this workaround ignored new accounts, so first year students and new employees couldn’t use Ubuntu clients. This has been fixed now and all C&CZ managed Ubuntu client PCs in computer labs and the Library of Science have been updated....
Gitlab pages was unavailable due to a problem with the underlying S3 storage. It took a while to fix, due to confusing messages in the logfiles of the service. title: gitlab pages onbruikbaar door storing in rados gw
The backing store for gitlab-pages, accessed via the S3 protocol, went into failure mode for still unknown reasons. After restarting several servers of the storage cluster, the service became available again. update 20-08-2024 It happened again Today at 12:15, fixed quicky (within 20 min)