C&CZ Problem Card

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.

 

Service Interruptions


1407: NFS problems under investigation

When we moved the gateways of our networks from the old location to the new firewalls, we have received some complaints about NFS filesystems having slowness, longer delays or unavailability. In general NFS should never be a requirement for a clusternode job if you can avoid it, because this I/O is always much slower than local I/O from /scratch. We are investigating how we can optimise the network to resolve this issue, but we are hard pressed to know the exact cause of the problem....

1415: Clusternode maintenance day - February 6th 2026

Every half year we do clusternode maintenance, with at least a package ugprade and a reboot, but sometimes other maintenance can happen, such as changes in filesystems or network configurations. The upcoming date for this maintenance is February 6th, 2026 (Friday)

Resolved Reports


1416: Radius certificate expired (Eduroam login)

The certificate of the radius server has been replaced this morning, users who use their science account for authenticating to the Eduroam network will not have been able to connect until the certificate was fixed. You may need to ’trust-on-first-use’ or other setting in your device to properly reconnect and trust the certificates, if that still fails.

1414: ldap unavailable

A brief service interruption occurred this morning when one of our LDAP servers refused to start. This affected services that depend on LDAP for user authentication. Services such as Eduroam (using science login for authentication) and GitLab experienced authentication failures during this time. We are investigating the source of the failure to prevent recurrence.

1411: Homeserver upgrade memory

Recently we have experienced some issues with nfs filesystems one of the main suspects was the ZFS filesystem having a lack of cache memory on the machine. In order to improve the situation we will install more memory in the servers. This will cause a downtime of about 10-15 minutes per server. We plan to do this before 10:00 or after 16:00 on Monday Oct 27, 2025. Update 27 Oct 2025 The memory upgrade was concluded around 09:15 on Monday 27 Oct....

1413: Elabftw upgrade and move

The ElabFTW server will be upgraded and also moved to another host on Monday October 27th, this will be a little bit more involved than a normal version upgrade, and you can expect some downtime during the move and upgrade. Update: upgrading was done on the old server, moving to the new server ran into some unexpected issues, we will plan a new date for that. Update: move was done on Sunday November 2nd, some users report problems logging in, but that appears to be temporary due to elab running on a different ip address and machine....

1412: Physical server move

On Thursday 23rd we will move the host of the rstudio website and another server to another location. This will cause some downtime, starting from about 9 O’clock and it should be done within 1 hour.

1410: gitlab registry unavailable

The GitLab registry used by gitlab.science.ru.nl and gitlab.pep.cs.ru.nl is currently unavailable due to a disk failure in the storage backend. The faulty drive is being replaced, after which the registry should be available again.

1409: Miii server issues

Due to some cleanup changes, the miii server ended up without the proper firewall rules and account configuration scripts that it was supposed to get. We were able to fix the server eventually, but during the day, users were unable to work until it was fixed.

1408: Network reconfiguration vmhosts

With the changes in the networks, we are able to optimise some vlan configurations to utilise the high speed link, which was impossible before. The network reconfiguration may need a reboot of the server, but otherwise not too much downtime is expected. The reboot takes about 5-10 minutes if necessary. The list of vm’s affected (only those without redundant functionality are listed): vmhost05: mestrenova143 pagespep pep1 nolaivalkhof mestrenova150 fsecure pep2 pages licensevm1 goudsmit zaaivm stormvogel nolaigoffert desdapi vmhost06:...