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.
We will reboot clusternodes and possibly upgrade them from older ubuntu versions to ubuntu 24.04 in the last week of August 2026. If you have clusternodes and would like to plan for an upgrade from ubuntu 22.04 to ubuntu 24.04, please let us know
Our upstream certificate provider HARICA mis-issued several certificates (details) and is in the process of revoking said certificates. When manually renewing the certificate for helpdesk.science.ru.nl, we encountered a configuration oversight and accidentally misconfigured the webserver. This resulted in a redirection loop. We restored the working configuration from backup and reloaded the configuration for the webserver. Update Several thousand more cerficates have again been revoked. This is also led to HARICA being overloaded, because every one is trying to get their certificates re-issued. We are trying to update the certificates where we can.
This morning, we automatically sent a reminder for Science accounts that have a so-called end date in the near future, in this case 31 August 2026. We use the end date to find accounts that are not needed anymore. When both the end date and a grace period have passed, we delete the account. In the normal situation, this end date is automatically postponed if our internal systems indicate that the Science account is still needed in the future, for example, when a student has re-enrolled for the next year. For accounts that are managed by other, existing Science accounts, these owners can extend the end date of their managed logins using our self-service portal DIY. ...
Fileserver peck hosts several network shares. After the weekly reboot on Monday 3 August 2026 around 06:15Z, the machine did not fully start, causing the network shares to be inaccessible. After a manual reboot around 07:25Z and continuing the boot process, the machine’s network shares became available again around 07:35Z.
One of the boot disks was failing and in the process of trying to resolve the issue (reseating the disk), its mirror suddenly went offline as well. After restoring that half, the server is running and we are busy getting a replacement part. In theory the server should not have to go down when the disk is replaced.
We are going to upgrade fileserver “peck” on Friday June 19th 2026. The plan is to do it early in the morning, but you may experience some issues after the upgrade as well. Rebooting the client computer may solve the problem in that case. Please keep an eye on this page to check whether the upgrade is completed or not. The upgrade was finished, but it took a bit longer than expected. ...
This morning gitlab.science.ru.nl was not working correctly or at all. Finally a reboot of the host fixed all issues.
Since a while we’ve noticed our public gitlab server being targeted from various places on the internet, it looks like a DDOS or it could be a lot of AI agents scraping data. Whatever the reason, it is harming regular users normal way of working. Therefore we have implemented an agressive blocking strategy, which can block large parts of the ip range of the internet for a limited time. To compensate for the problems this causes, we have also implemented a fixed allowlist to prevent known friendly ranges from being blocked in this way. If you are cooperating with groups of people who experience this blocking mechanism, please inform us of ip ranges you would like to have included in the allowlist. ...
On Whit-Sunday, the certificate for some of our S3 buckets expired. After figuring out that the problem we saw was related to the certificate, we fixed the certificate and rebooted the server.
We became aware of the Kernel vulnerability and implemented the kernel vulnerability mitigation The change was to set kernel.yama.ptrace_scope = 2 (A sysctl setting). For users of MPI jobs, this setting broke the jobs. When we have a fixed kernel and rebooted the nodes, we can change this back to something that will work with MPI. Workaround or fix, use mpirun --mca btl_vader_single_copy_mechanism none etc...