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.
De following Science services will be placed behind eduVPN. This means if you want to have continued access, you must use this VPN. De volgende Science services worden achter eduVPN gezet. DHZ/DIY SMTP (mail sending) LILOs Webmail If you have questions are experience problems with setting up eduVPN, please contact our helpdesk.
The IMAP server had a problem, which made a reboot necessary.
On Thursday June 6th from 10:00 pm the wireless networks ru-wlan and eduroam will be unavailable for at least 2 hours. All existing connections will be cut off. The wireless network Science however will not be effected and will be kept available.
The central BASS RU environment has been updated last weekend. Part of this upgrade was a change of the web address of the second logon screen, as announced on our BASS page. This morning it became clear that access to the second logon screen via the Port Forwarder didn’t work anymore. Therefore the UCI rolled back the change of the second logon screen. This means that AFTER LOGGING ON TO THE PROXY at https://admin....
During the renewal of the OpenID server a configuration error was made. When users reported problems logging in, we started searching for the origin of problem. When it was found, it could easily be corrected and the server could be restarted with the correct configuration.
The fileserver crashed. After a reboot everything was back to normal.
The fileserver failed to reboot during the regular Monday morning shutdown schedule. It was possible to gain access to the system console only after having removed all power from the chassis. Snapshots were removed using the rescue reboot but rebooting the machine resulted in a faulty filesystem. We were able to boot the system after all filesystems had been checked offline. These actions resulted in a unusual long downtime.
Problem: Crash due to defective disk Solution: Deactivated disk using hot spare and reboot
The fileserver failed the regular Monday morning reboot. Only after a rescue boot and a manual removal of all snapshots rebooting the machine worked.
Problem: Stack: Crash due to failing disk. Solution: Deactivated disk using hot spare
Pile did not shutdown properly during weekly reboot due to a kernel panic. Solution: Executed power-cycle of the system