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.
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...
The fileserver peck crashed this early morning. After a reboot, the machine ran fine again. Users of cluster nodes that use nfs exported volumes from peck might still experience problems as nfs (network file system) does not seem to be recovering well.
Since last Friday (May 8) around 18:30, our SMTP servers have intermittently refused to accept mail for sending. The issue was caused by rspamd refusing to filter messages for unknown reasons. The issue seems to be resolved for now, we will keep an eye out for the problem to re-occur. Update: It looks like the issue was resolved by explicitly setting some default settings to their default value. By doing this we were able to prevent errors that occurred with some e-mails. We think these errors caused the SMTP server stop accepting mail in some cases.