Dispatch #4: 2007/01/26

This short update will detail some important changes hitting the environment, plus highlight a project from the past year you may not have known about.Wireless Upgrade, Wednesday January 31. You may have noticed some nifty gadgetry on the ceiling of building 221 recently. It’s all part of a wireless upgrade we’ve had in the works for some time now, and we’ll be pulling the trigger early in the morning on the 31st of January.Here’s the skinny…The improvements:

• We’ll be on lab-wide, lab-supported wireless. The registration you have in 201, 222, etc. will work here in 221 and 203.
• It will be more reliable and useful than the wireless we have now. 802.11 A, B, and G will be available on all floors, with stronger and wider coverage, producing an overall better bandwidth and a much more favorable user experience. For some people, it should be a world of difference.
• We have plans to eventually support optional encrypted authenticated wireless for secure communications, providing the same benefits of a VPN connection without additional software or inconvenient network routing rules.
• Known malicious and explicit sites will be blocked. The page that indicates if a site is blocked includes an option to request removal of the block. Systems has been operating within this site blocker for months now, and we’ve not seen a negative impact.

The changes:

• Generally, no more static IP registrations. What this means is that users will register for wireless access once, online — similar to what our guests do now. On that registration form, they’ll also indicate if they need a long-term registration, and if they need to send mail using outside services. These changes will get implemented automatically for the user with no further inconvenience. We’ve found that the typical usage model doesn’t require the use of a statically assigned address, but we understand that it’s sometimes necessary. We have contingencies in place for that. If you fall outside this typical usage pattern and need a static IP address, drop us a note letting us know how many and the purpose for them, and we’ll take care of you.
• No more .mcs.anl.gov wireless addresses. The laboratory’s cybersecurity policy requires specific treatment of wireless networks as visitor networks, and we need to fall into compliance with this one. Tasks that require a .mcs.anl.gov address for access will have to use some alternative method. In anticipation of this, we’ll be changing our proxy configuration to allow wireless users to proxy for access to sites that would normally require a VPN. But people who want to SSH from wireless to a managed linux desktop in MCS will have to either run the VPN or connect via shakey/terra/harley. If you feel this presents an undue burden on you and your work, please let us know so we can study the issue and come up with a solution.

What won’t change:We don’t anticipate any changes outside of what’s noted above. Things that work now should continue to work on the new network as well. For example, Mac/Unix laptop users will still be able to print via our unix print server.Server upgrade, Monday January 29.On Monday afternoon, we’ll be upgrading a pretty important server in our infrastructure. However, we’ve studied the upgrade solution and are confident there will be little to no user-visible disruption of service. In fact, users don’t directly interact with this machine at all, as it’s a pure back-end management server on our private management network. However, due to its importance in the environment, we wanted to give you all a heads-up that it’s happening, and that, should things not go smoothly, there may be some service disruptions in some areas including account creation, adding new machines, and name service additions or changes.MCS Web overhaulLast spring, we outlined a plan for migrating to a new web server. Then the person who was going to implement that plan quit, and it took some time to find his replacement. Now, the landscape has changed and we’ve got a new path. As announced in December, Beth Cerny Patino started work with us, tasked with designing and implementing the new web look for MCS, its groups, and other CLS sites such as the CI and IGSB. She’s been making steady progress on that front, and you’ll soon see a brand new look for the MCS pages that is far more functional and aesthetically pleasing the the hack job performed by your humble narrator.Once this is in place, Beth will be able to help you migrate your sites onto the new server. Our goal is a from-scratch rebuild of the MCS web, with old paths and URLs going away. Obviously, since we can’t change the printed word out there, any URLs that you feel must be preserved we can handle. We’ll also be working on a helpful and functional “File not found” page that should help users get to where they need to go. This will be discussed in more detail in a future update, along with a divisional presentation with Q&A to follow.But don’t panic. Before anything like this happens, we’re going to take it slowly and make sure we’re not going to orphan URLs that have a high search ranking on search engines. Our goal is not to abandon pages that people are using — it’s to avoid wasting time migrating webs that are out of date and out of use. The goal right now is to let you know how we’re planning to proceed, and to get you thinking in the right context to make the switch as smooth as possible.MCS Backup System UpgradeWe’d like to highlight a major project undertaken this past summer that you may not know about. There’s a fair amount of things we do that you might not know about, which generally means we’ve done it well since nothing broke :). In that spirit, we’re going to highlight the upgrade work done on our tape backup system last year.The system prior to upgrade was in dire need of an overhaul. The tape robot itself was working fine, but the various components that make up the system were antiquated. Our largest capacity tapes held around 85GB of data compressed; most of them had a 14GB capacity. And they were s. l. o. w. The server was a 1998 vintage IBM AIX machine that was being pushed beyond its processing limits running the backups for MCS servers, TeraGrid, Jazz, and various other machines. Then, the arrival of Benoit Roux and the kBT cluster highlighted how under capacity we were.With assistance from Benoit’s group, we were able to upgrade our TSM server to a cutting edge server capable of handling the demand we place on it. We also purchased two high capacity (and high speed) tape drives for the robot. With these improvements in place, our per-tape capacity rose to over 600GB per tape (with the right kind of tape). This means our maximum capacity in the robot went from around 300TB of data to over 2PB, assuming we fill every tape slot with a high capacity tape. Now, we’re not doing that right now, but are in the process of phasing out the older slower tapes and adding the newer tapes as time and money allow. We’re still operating with 4 of the older tape drives, and will be upgrading these drives over the next year or so.JP Navarro led this project, and it went splendidly. Thanks, JP!