The maintenance has been finished and we have harmonised our user and group IDs with ZEDAT.
News from Sep 05, 2022
Monday September 19th starting 8 p.m. we will do some maintenance on all of the department's Linux systems to harmonise user and group IDs with ZEDAT.
Users will be affected in the following ways:
- All users of Linux desktop machine will have to be logged out off all machines during the time of the maintenance.
G:) will only be available in read-only mode. This also affects users of Windows systems.
- There already is a reservation for this time on the tron and sheldon clusters, so that all running jobs have to be finished by that point and new cannot start and run during this time frame.
- On machines, that still have running user processes, we will kill the processes and restart machines.
We plan to finish the maintenance in the night to September 20th, so that people can get back to work in the early morning hours of September 20th. Except for
not being able to use our systems, during the maintenance window, there shouldn't be any user-visible changes.
Update (02:54): The migration has been finished except for a last few users with a very large number of files on the scratch of the tron cluster and some scattered local filesystems on desktops. The network shares
G:) are again available in read-write mode for all users and the queue for sheldon has been reopened. The queue for tron will be reopened after the scratch migration there is finished.
Update (05:00): The last remaining migrations have finished. We will not restart the tron queue right away, but use the downtime to make some tweaks to the slurm config and resolve some hardware issues.
Update (09:00): As our users get back to work we are receiving issue reports. The windows shares were unreachable for users whose UID changed during the migration. This was due to some internal cache of of the daemon providing the share. The caches have been flushed and access should be restored to all users.
On Linux some programs might unexpectedly not start. This is due to runtime directories having been created in the past now having wrong UIDs and GIDs. This can be resolved simply by rebooting.
Update (09:30): The machines of users who are missing network shares have to be rebooted. This only affects users whose UID has changed and who have tried to connect to a network share between yesterday evening and today 09:07. All other users whose UID changed should see the drives with a red cross. These users should be able to simply click on them to reconnect.