Yesterday, bushel was upgraded, to complete that, an extra reboot was scheduled on Tuesday morning, however the nfs server did not get started properly after reboot, causing the nfs shares to be unavailable until the nfs service was restarted later in the morning.

On Linux kernel version 7.0.0-42-generic, it appears the network card driver bnxt_en is unstable. About an hour after the weekly reboot today, the network card driver crashes, yielding the machine itself and virtual machines unreachable. A temporary reload of the affected module caused the same crash within a few minutes. We rolled back to 7.0.0-38-generic, which seems to be more stable. Affected virtual machines: zulip1 icsd24 goldengate jupyter24 ldap4 geronimo web2 Update 14:45 It appears we’re running into this issue that has been fixed in the patch bnxt_en: fix DMA mapping length for padded small packets. ...

This morning, after a reboot of fileserver zwik4 at around 06:30, its NFS server did not start correctly. This affected several users who were unable to log in to login nodes such as lilo and cnlogin22; clusternode and JupyterHub users were probably affected as well. We rebooted zwik4 again at around 11:10, after which the NFS server started without problems and the login nodes were reachable again. We do not yet know why this happened. The error we saw, “address already in use”, was quite unexpected, and the problem appears to have been temporary. We will investigate further and update this message if we learn more.

Today, as part of an operating system upgrade of server bushel, a network configuration mismatch left the server offline between approximately 12:30 and 13:01. This affected JupyterHub as well as the other file shares running on bushel. The configuration has been corrected and the services are back online.

A major security vulnerability in PHP was discovered. As of 22 October 2026, our systems have been patched with the new releases. Status as of 2026-10-21 11:00:00 CEST 21 October 2026 at 16:00 CEST the PHP team will release new versions, but exploitation attempts are already happening. There is no mitigation, all PHP sites that use “multi-part” file uploads are vulnerable. Only bringing sites off-line will help. We know that Wordpress sites are affected. So we are taking down all Wordpress sites that we host until an updated PHP version is released. ...

We will upgrade Elabftw today between 11:00 and 17:00. Both elabftw.science.ru.nl and bigchemistryeln.nl are affected, and some downtime is expected. This is a major version upgrade, not a point release. If the upgrade does not go well, we will restore a backup and continue with Elabftw version 5 for the next couple of weeks. Update: both sites have been updated Apologies for the tsunami of old notifications that were previously held back by a bug, which was fixed in the v6 release!

Fileserver peck hosts several network shares. After the weekly reboot on Monday 5 October 2026 around 06:15Z, the machine did not fully start, causing the network shares to be inaccessible. Around 07:35Z we continued the boot process, and the network shares became available shortly after.

A security issue was found in our gitlab installation. However the version we have installed doesn’t look to be vulnerable (we are running the exploit ourselves and getting no results). Meanwhile we are working on upgrading our GitLab installation(s) to make it easier to follow newer GitLab releases. We are aware of the Mattermost/GitLab split, but without an alternative, we need Mattermost to keep on running. We are planning to upgrade gitlab.science.ru.nl on Thursday September 17th, this will involve some downtime for both gitlab and mattermost. (upgrade completed successfully)

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.