I was thinking of the right thing to title this dispatch. I started with "Progress is progress, but sometimes it's slow." That sums things up somewhat, because we're making progress, just not as quickly as I'd like. But, still, it didn't feel righ...
I was thinking of the right thing to title this dispatch. I started with “Progress is progress, but sometimes it’s slow.” That sums things up somewhat, because we’re making progress, just not as quickly as I’d like. But, still, it didn’t feel right. A quick peek for quotes on the subject of progress yielded this gem:
It is a bad plan that admits of no modifications. — Publilius Syrus
Also apt. In any case, in this dispatch: an update on the progress we’re making in the various pushes to get our new infrastructure online and retire the old hardware and software to the excess pile, but first, an announcement!On Monday, 3/17, we’ll have a new team member helping us out with Help Desk and user support issues. His name is Bryant Fortson, and he’ll be sitting in 221-B259. With this will come some changes. Specifically, Tina will no longer be permanently based in B256, as she’ll be sharing Help Desk duties with Bryant, and, after some office shuffling, we’ll have a situation set up where the Help Desk is staffed during standard Argonne operating hours (8:30 AM – 5:00 PM, Monday through Friday, closed for lunch from 12:30 to 1:00 PM). Given his role with the group, I’m sure you all will meet him in short order, but by all means drop by after he’s settled away on Monday and introduce yourself.Now, on to the progress updates. Did I scare you with the quote above? I didn’t mean to — things are actually moving along, we’ve just had to adjust some methods, some deadlines, and some expectations. I’m going to talk specifically about three of the upgrades we’re working on in parallel, all of which are fairly high profile: mail, web, and printing.Mail service update: We’ve reached the point we wanted to be at about a month ago, due in part to some failed methodologies, and in part because of emergencies that steal our focus. This week, we begin the actual synchronization of mailboxes. For every MCS mail account, we’ll be migrating messages over to the new server; that process has already begun. This obviously affects the time line I posted last month, so let’s revisit and modify that a little:
- This week: Continued migration of mailboxes. How long this process takes is still a wild card. We’ve now developed an automated system allowing us to migrate the users to the new server without us needing to know any passwords (this was very important, and fairly tricky), but what we don’t know is how long it will take to get everyone done. The nature of this method requires us to do this completely serially, which means only one user at a time (though not necessarily one mailbox at a time). I’m allowing two weeks for this process, we’ll adjust accordingly after a few days of processing.
- March 24 (projected): Switchover. When you attempt to access your old mailbox, you’ll be given instructions on how to set your new e-mail password and change your mail client to use the new mail server. Anyone with a current MCS e-mail account will be able to get rolling without requiring an in-person visit or call to the help desk for a new password, as long as you remember your current e-mail/unix workstation password.
Do you notice what’s missing from this time line that was in the previous one? Converting user procmail scripts to sieve. Alas, we’re punting on that. We tried, we really did. There are various scripts out there that attempt to do it, but ultimately in order to make it work, we’d just simply have to rewrite everyone’s recipes anyway. And as much as having a new person help us on help desk duty allows us to devote more time to things like this, it doesn’t give us that much time. There are plenty of fish to fry once we’re done with this migration.Bearing that in mind, we offer up this consolation (which was always our plan ‘B’ anyway) — if you need help translating your procmail recipes to sieve recipes on the Zimbra server, we’ll help you. We’ll schedule a time to go over your server-side filters and implement them for you. Considering that this is something we’ll be doing by hand and isn’t something we can easily do in parallel, I’d ask that you take an honest crack at it before resorting to having us do it. At the very least, it’s worthwhile to see how many of your existing recipes are still valid and worth implementing on the new server; if the procmail files we have to translate have already been culled of extraneous entries, that’ll make it a smoother process.If you have no idea what the above two paragraphs mean, the good news is that you’re probably not affected by them. So relax, and read on.New Ticket System: One of the other things that needs to happen before we can turn off the decrepit mail server is migrating away from Req as our default ticket system. I sent out a survey some time ago to the users of our ticket system, and the answers to that, along with the needs of the various support entities in MCS and ALCF, have driven us to declare RT:Request Tracker the de facto successor.RT’s got some solid heritage — it, in fact, traces its routes back to Req. It’s going to get us a number of features we’d been missing, such as a nice web interface and a way for users to check on the status of their requests. You’ll still be able to simply send an e-mail, but you’ll be able to do much more as well. If you currently use Req, we’ll either migrate you over to RT when the time comes or move you to something else depending on your preference. More details will emerge as we get closer to that.As far as that “something else”, we also offer Trac as an option for software projects (which gets you an integrated subversion repository and a wiki). We’re in the process of integrating the capability of receiving trouble tickets via e-mail. Our preference will be to either migrate current Req lists to RT, Trac, or a simple mailing list. If none of those options are right for your project, we can discuss options at the time. Our goal is to keep the number of different packages supported to a minimum for obvious reasons.Mailing lists: Another issue that needs resolving before we can move poor old cliff to the excess pile is our mailing lists. Once we get the two tasks above out of the way, we’ll migrate majordomo lists off cliff, converting them to mailman lists on the new list server. Once we’re converted to mailman, you’ll be able to manage your lists and subscriptions via a web interface, far more intuitive than the current mail-only method on majordomo. We’ll start tackling this in earnest soon.Web Update: Some time back, we announced the CLS (now CELS) Website Content Management tool. It’s been getting some use, but we’re fast approaching the point where it’s going to get a lot more useful to many more people. Next week we will be announcing another Tips & Tricks session, this one highlighting the uses for this tool and walk everyone through how it can make managing the web sites for your group, your projects, or yourself that much easier. We’ll also be unveiling a new look for research group pages, providing a beautifully designed page that’s distinct but within Argonne’s identity guidelines and driven by the back-end database the above-mentioned Content Management tool uses.Expect an announcement on that session this week. In that session we’ll also go over the migration plan for personal pages and group pages not covered by the above.Print server: Currently, our print services are a bit of a hodge-podge. Windows users use one print server, linux and MacOS users use another with some people printing directly to some printers… it’s a mess. But it’s going to get simpler and easier, and we like that. The new print server will serve linux, MacOS X, Windows, and just about anything else for machines whether they’re on wireless or the wired net. No authentication and easy configuration. We’re in the final testing phases now, and will send another announcement before we make it live. Once this is live, we’ll be switching our printing from the old HPs in 221 to the Canon copiers. In 360, the large printers will obviously remain, though we will enable the Canon copier for B&W printing. As well, the fax in 221-D256 will switch to be the copier, with incoming faxes routed to a divisionally accessible network share where the PDFs can be viewed, printed, or trashed (saving paper from junk faxes).Mac and Windows users will be able to send faxes from their desktops through the Canon in 221-D255. Once that’s live, we’ll retire the old CTFax server and have the number forwarded to the Canon.When the copiers come online, the location for some types of print jobs in 221 will change. Color printing upstairs will happen at the color copier located in 221-A224, while B&W print jobs can be printed at either 221-A224 or 221-D255. Downstairs, both B&W and color print jobs will be handled through the color copier by the elevator.All the copiers will be able to scan (though the B&W copiers will only scan B&W). We’ll put up full documentation on all this when it’s ready.That about does it for now. Updates will come as warranted, and expect a new Dispatch in April.Happy still-groggy-from-that-lost-hour-of-sleep Monday to you all!