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.

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 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 Update: the (first) reboot should take place between 10:00 and 11:00, if subsequent reboots are needed we will try to keep it within the same day timeframe. ...

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.