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.
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)
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.
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: ...
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. We are assuming the root cause might be that, now more traffic is passing through our firewalls, this degrades the performance in some way. ...
A change in the firewall config had the uncalculated effect that ssh-sessions got blocked/dropped. The config has been reversed.
We need to move a server to another location, during the move some of the services are unavailable, including licenses for: Cadence Labview Originlab Cst Maple Server ExelisIdl Mathematica Synopsys Genesys Matlab VirtualMachine GurobiTokenServer Mentorgraphics Xilinx Hdlworks Moe IntelCompiler New Everything should be completed by 10:00.
Due to the gateway change the printing traffic followed a different route which ran into default blockages in the central firewall, after the problem was found a fix was implemented to allow this traffic to the printserver via the new route.
After switching the gateway for one of our busiest vlans to our own firewalls, a lot of websites were only available from outside that vlan, it took a while to understand the issue and find a fix for it. We now have a temporary fix in place that should make the websites work again.
Due to an unfortunate manual command, the package for filemaker was removed from the server. Service was restored after the weekend, when the backup was restored.
Due to an unfortunate manual command, the package for DHZ was removed from the servers, causing all attempts to login with MFA to fail on for example roundcube and lilo ssh login. Service was restored about half an hour later when the DHZ package was installed again.
Due to a change in how the Microsoft Exchange server validates e-mail, mails sent to an @science.ru.nl address (or similar domains for which we accept e-mail) from an external domain and with a forward to your @ru.nl mail are very likely to be dropped, because the receiving server at Microsoft considers this mail forged, in the sense that the sending client did not address the same domain as the receiving domain. This also applies to our Mail Aliases with @ru.nl addresses in them, when they are addressed from an external mail domain. The forwarded e-mail will be silently dropped, so senders will not notice a problem. ...