This announcement will probably not affect too many users, but it might have some impact and we can't narrow down the recipient space.

For some time now, our group shares on groupdata.phys.ethz.ch, when mounted via SMB, allowed so-called wide links - they point from one group share to a place outside of this share (usually to another share). For $complicated_reasons we have to disable those wide links. This will break redirection to the target share. We believe this is mainly a convenience issue, but we might not be aware of legitimate use cases. So if you find something broken after

Tuesday, October 8, 2024

please get in touch so that we can find a solution. Links within a particular share will still work, but link targets have to be relative (../../papers/thesis.tex) instead of absolute (/home/sharename/documents/papers/thesis.tex).

Thanks.

Update 20:10 Migration finished! Everything should work as normal.

In order to guarantee sustained performance and availability of our storage system, we schedule a maintenance downtime of our home directory server on

Tuesday, July 09, starting at 17:00

This only affects the home shares (technically: smb:\\home.phys.ethz.ch & /home/USERNAME). Email and group shares will have no interruption.

Since the server also needs a file system check, the downtime will take several hours.

For emergency cases, there will be read-only access to last night’s backup as described here .

We will update this posting once the home server is back online.

We schedule a short (~30 min) maintenance downtime of astrogate on Monday, Dec 12, starting at 07:00 in order to replace a network card. During this time no access to the astro SAN data will be possible.

In order to restructure the filesystem of the home directories, we schedule a migration on

Wednesday, 28. March 2012, starting at 17:00 and lasting for several hours.

During this time the home directories (winhome, machome, unixhome), the mail services and some websites will not be available.

To protect you from losing or corrupting any of your files, we strongly recommend you close all open files on the home directories before the migration.

Since we have switched to generic names for our services, the home directories will still be accessible the same way as before after the migration is over, so you don't have to change anything.

Update 19:40 Migration completed. Every test we could think of passed. Please let us know if you find any remaining issues. Thanks for your patience.

In order to solve our recent file server problems, we schedule another migration on

Wednesday, January 25, starting at 17:00 and lasting for several hours.

During this time, you will not have access to your home or group directories, and also email will only work intermittently. Please stop all running jobs and log out prior to the migration.

Update 20:30 Migration completed. Every test we could think of passed. Please let us know if you find any remaining issues. Thanks for your patience.

On Jan 5, after weeks of thorough planning and rigorous testing, we performed a migration of the home directories and group shares to our new SAN system. Soon afterwards, the first phone calls started coming in. The initial problem was very exotic and affected very few people (that's why we had no chance to detect it during the testing period), but the action we took to address it unfortunately caused a cascade of consecutive faults that led to the instabilities you had to endure for one week now and for which we are truly sorry. We now know how to fix the underlying problem, but we cannot operate on the running server. That's why we have to schedule an

emergency file server migration on Sat, Jan 14, starting at 07:00 and lasting well into the afternoon probably.

During this time, you will not have access to your home or group directories, and also email will only work intermittently. Please stop all running jobs and log out before Saturday morning.

We apologize for the suboptimal performance since Jan 5. You have every right to expect better, but this caught us completely off guard. Thank you for your understanding.

Update, Sat 14:15: mounts and email are up and running again. The problem on 32bit machines still persists, but we have an idea how to fix it on Monday.

Update Fri 20.01: we (hence you) are still suffering from severe stability problems on the file server. We are very hard at work and now have a plan that we really really hope will solve the problems. There will be another migration sometime next week. We're truly sorry for the inconvenience you have to endure.

A firmware update on the RAID controller of our file server requires a reboot of this server. We schedule the reboot on Wednesday August 4, at 22:00. The downtime should take no more than 30 min. Please make sure all your data has been saved at that point.

We apologize for any inconvenience.

Update, 22:20: The server has rebooted and everything should work again.

On Wednesday, 7th of April 2010, starting at 6pm and lasting until approximately 9pm, there will be several maintenance downtimes for nearly all of our services due to several software upgrades and relocation of servers.

So if you're using one of our managed workstations or thin clients, or use data residing on group drives, please save all your work and preferably log out/disconnect before Wednesday, 6pm. And even if the services seem back after the first short downtime, don't expect to be able to work again from that point on since we will have several short but also some not so short service downtimes in a row.

Update, 20:30h: Most servers and workstations are back online. Not yet ready for usage are: fatboy, the IDL license server and the Condor master server. They will be back later tonight.

Update, 22:45h: fatboy is back online again. But two infrastructure servers (which haven't been touched by today's maintenance) seem to have hardware issues. Because of that the maintenance of the IDL license server and the Condor master server have been postponed until further notice.

If you're on the road a lot, you might be familiar with our webhome service which provides universal access to your home directory. While this can be a life-saver in some cases, there are a few limitations: a) you only get access to your home directory, b) it's only viable for single-file operations. The protocol of choice for remote file access across public firewalled networks is WebDAV. We are now happy to announce a WebDAV gateway to our file servers.

Should you be interested in using this service, please read our documentation page.

The Informatikdienste of ETH will change their AFS policy by March 31 of this year. AFS functionality will be provided through a dataless AFS cell at ETH.
If you still require an AFS account which is connected to storage you need to act now and arrange an agreement for your use or move your data to some other place. Please consider the following points:

1. data on the ETH AFS server: This service will only be available under a contract with the Informatikdienste as a paid service. We recommend moving your data away from AFS if possible. NAS services (SMB/CIFS, NFS) are available from the Informatikdienste or the Department of Physics. Please ask the ISG D-PHYS if you need help or advice.
2. an AFS identity as user coming from the ETH: If you own data on other AFS servers around the world that are tied to your AFS identity from ETH you may want to keep your ETH AFS identity or transfer ownership to some other AFS identity. This service will be provided by Informatikdienste as a general service free of charge but only upon request. If you need this please let us (isg@phys.ethz.ch and tilo.steiger@id.ethz.ch) know.
3. access of AFS servers as an anonymous user: This service will continue for the foreseeable future without further action required from your side at this time.

Without a reaction from your side we assume that you don't need an AFS account anymore and you will become an anonymous user to AFS.

Note: you can use an AFS identity from another cell if you have one. You don't need an ETH AFS identity for that. E.g., to use your CERN AFS identity on the Linux workstations use klog -cell cern.ch

Further reading: Wer braucht noch AFS??? by Tilo Steiger at the ID-Blog