As announced in two previous postings in July 2007 and February 2008, PHP 4 has reached the end of its development life; security issues require us to migrate to PHP 5, the currently supported version. We’ve been working on migration issues for the past several months, and we believe we can migrated based on our original target date of May 1.
To ease the transition for our users, we have devised a way to allow two web servers to co-exist on the same machine. (Geek aside: to do this, we’re using Apache’s reverse proxy directive, ProxyPass). Our current plan is to put the PHP 5 -based server into production on Wednesday, April 23 at 5:00 PM; we will continue to keep the old server running so that any sites which have problems under PHP 5 can continue to run until their code is fixed.
In most cases, code that works with PHP 4 should work with PHP 5, but there are exceptions. We know that the development framework LSCR has been using for our web team’s internally-developed applications (such as our department directory, news+events system, and course listings) does not work under PHP 5; we are in the process of migrating our code to the Zend framework. If you are one of our web customers, we will be contacting you about migrating your department’s applications to the new framework.
If you are managing your own PHP code, or your own installation of a PHP tool like WordPress or drupal, it might be a good idea to test your code on our development server, which is already running PHP 5, sometime before April 23. Mail sysadmin@LS if you’d like to get set up on the development server.
If you do nothing, your site will be migrated on April 23, and it’s possible that it will work just fine, but we would recommend that you check and test for problems. Most problems should be minor and quickly fixable; if you have major problems after the migration, contact sysadmin@LS and we can temporarily put your site back on the old server to give you time to deal with the issues.
I posted last July that PHP 4 is nearing the end of its life, and that therefore we must begin migrating our sites to PHP 5. PHP 5 is largely compatible with PHP 4, but I expect that most sites based on older code will need at least some modification to work properly under PHP 5.
The final version of PHP 4, version 4.4.8, was released in January and was recently installed on our main web server. The PHP development team has committed to providing security patches for 4.4.8 until this August; after August, using PHP 4 will be a violation of the campus minimum security standards. That situation gives us a fairly hard deadline for migration, and we’d like to be migrated well before then.
We have set up a development web server running Apache 2.2.8 and PHP 5.2.5 to allow departments to test their sites with PHP 5. Contact sysadmin@LS if you are interested in getting set up on the development server.
Our target date for cutting over to PHP 5 will be May 1, 2008. At that time, we’ll put PHP 5 in production on our main server, and any of your PHP code which is incompatible with PHP 5 will break. I expect that most sites will continue to work fine, with perhaps some small glitches, but it’s impossible to know unless you test your code beforehand.
We’ll be sending more communications about this change-over as it approaches.
Bernie Rossi from the CalMail team posted a message today about legacy mailing addresses on CalMail. Many people are still using user@uclink (or @uclink2, @uclink3, @uclink4) as their From: address in their email clients; some others got set up as user@calmail.berkeley.edu when CalMail first went into production.
All of these alternate addresses have been basically equivalent until now; you could use any of them in your From: address, and anyone sending you mail could use any of them to address you. They all wind up in your CalMail inbox. Going forward, most of this will still be true; mail sent to user@uclink will still be delivered to user@Berkeley.EDU. The change is that, due to anti-spam provisions in the mailing list system, you will need to subscribe to the mailing list with the same address you use in your From: address in your email client. There are mailing lists which have been in existence for many years which are filled with @uclink and other legacy addresses; CalMail’s current plan is to replace those email addresses on mailing lists in bulk. (Scheduled for February 28).
What that means is that if you currently have your From: address set to be user@uclink, on February 29 (happy leap year!) mail you send to (most) mailing lists on lists.berkeley.edu will not be delivered–it will be held for approval by the list owner.
The easiest thing to do is just to set your mail client to use user@Berkeley.EDU as your From: address. It looks nicer that way, anyway. Bernie provided rudimentary instructions if you want to do it yourself, or you can contact your LSCR support team for help. Note that if you do this before February 28, you may have the same problem sending to mailing lists until the change is made, so it’s best to wait until the end of the month.
Today Calmail announced that the mailing list software running on lists.berkeley.edu has been migrated from Majordomo to Mailman. Majordomo had been in place for at least 15 years, but the software was severely obsolete. Mailman is the most commonly used mailing list management package, and mailing list owners will be happy to learn that your list management can now be done entirely through a pretty good web interface, instead of having to send cryptic email messages with Majordomo commands.
If you have public mailing lists, you’ll have to update the instructions you publish about how to sign up for the list. You’ll also want to familiarize yourself with the new interface for approving subscriptions and moderating postings, if you use those features. You will find it a lot easier in the new system once you get used to it.
The team has been working on this migration for over two years; the fact that it is now here will enable a number of other projects to move forward. Most importantly, Calmail is now very close to being able to realistically replace the functions of most departmental mail servers. CalMail is much better positioned to be able to deal with anti-spam and anti-virus protection schemes, and there is no way we can compare with the 24×7 support the service is offered. There are a few more technical details to work out, but we expect that we’ll move most of the email domains that we currently run on L&S hardware or departmental hardware over to CalMail’s departmental domain service over the next year or so. I encourage any of you who are still running your own mail servers to consider whether CalMail can meet your needs.
Apple released Mac OS X 10.5, code named “Leopard” this week. Leopard represents a noticeable but not compelling upgrade from Tiger; there are a few nice new user features, but the underlying operating system is not fundamentally changed. Most users won’t notice a huge difference in the way the system works.
Unfortunately, there are some compatibility issues with Leopard which could be fairly significant, at least at first. The most significant issue for the campus is that Tivoli Storage Manager (TSM), the software which powers UC Backup, is incompatible with Leopard. IBM is planning to release an updated version in the first quarter of 2008–it looks like Leopard users will be without campus backup for several months at least.
FileMaker also has some problems with Leopard; FileMaker Inc. announced a free update to FileMaker 9 which fixes the problems, but has also said that it will not certify or update previous versions of FileMaker. Most campus FileMaker users are using versions earlier than 9, so this will likely be a problem if you can’t upgrade to FileMaker 9 right now. (See my post from July 27 on the need to migrate to a modern version of FileMaker).
Several Adobe applications, including Acrobat Professional which is in use by many departments, also have problems with Leopard. The MacOS Rumors site has a list of reported compatibility issues.
Because of these problems, especially the problem with TSM, at this time we are recommending that users not buy upgrades to Leopard. and if possible, buy new computers with Tiger installed instead of Leopard. If you have Leopard, contact your computing support team to see if we can work around the problems.
Leopard should be a good operating system, but it will take some time for all these applications to catch up with it.
For several years now, I’ve coordinated a bulk purchase of computers for L&S units. The idea of the bulk purchase is to save us the time we spend configuring identical or nearly-identical computers one at a time, and the extra 10-20% more we spend for those computers than we would if we bought them all together. Purchasing in bulk just makes sense.
However, coordinating the bulk purchases has been challenging. The vendors give me pretty tight timelines, so there’s not much opportunity to publicize the deal before the deadline for the discount expires. I always get requests from managers the day after the deal expires. And the rest of the year, managers have to decide whether to buy a computer when they need one, or wait for the bulk purchase to save a little money.
So this year, I’m trying something new. In collaboration with The Scholar’s Workstation, I’ve managed to get a web page for L&S computer recommendations placed on the TSW web site. This page will include Dell desktops, and Apple desktops and notebooks, with discounted pricing and our configuration recommendations. I plan to add Windows laptop configurations as well. We will keep the page current, so you’ll be able to get our recommendation and pricing any time during the year, not just during a two-week period in September.
I think this will work a lot better for L&S than the bulk purchase program did; the challenge will be keeping up with the changes in products and technology.
We’ve been working for almost a year now on a plan to migrate away from Eudora as an email client. Qualcomm announced last year that they are discontinuing Eudora as a product, and they have already stopped development. This has left us with an email client with known security holes which are never going to be fixed; an unpleasant situation for all concerned. Qualcomm had really given up on Eudora long before the announcement, so it didn’t come as a complete surprise to us.
Most of the team that was working on Eudora at Qualcomm, including Steve Dorner, Eudora’s original developer, are now working for the Thunderbird project. Thunderbird is an open-source, full-featured email client, and it really is a pretty good product. I’ve been using it myself for a few months, and I think it’s pretty easy to use, and more reliable than Eudora was.
We know that people have a lot of experience working with Eudora, and in some cases a huge number of existing mailboxes and address book entries. One of the things we’ve been spending time doing is coming up with documentation to help users with the transition. Check out our Thunderbird pages; they give some basic background on the program, as well as information which will help Eudora users familiarize themselves with the new client.
Right now we’re testing our migration procedures with a few test departments and with selected individuals; there are a few expected glitches, but in most cases the transition isn’t too difficult. We expect that we’ll be starting to schedule migrations for all our departments in September.
The UCB Messaging Steering Committee today sent out a memo to the campus technical mailing lists officially de-supporting Eudora, and recommending Thunderbird as a replacement. They give a deadline of October 31, but that deadline is kind of arbitrary; that’s the day the UC support contract with Qualcomm runs out, but it’s not like Qualcomm is giving us any support, anyway. LSCR’s timeline is a little more extended than that; we’re expecting to have the bulk of our users migrated by the end of the calendar year.
Contact your support team if you’re interested in being migrated early in the process, or if you have any questions.
One of the things we’ve been hearing from folks in L&S is that LSCR doesn’t communicate enough; that we’re quick to respond when they call us, but we don’t do enough to tell people about what’s going on in technology in the industry and on campus. Part of the reason for that is that to communicate via our web site or email is fairly time-consuming for us. Before we’ll put up a post on our web site, we want to be sure it’s correct and complete, which requires us to spend time developing the content, and then going through an editorial process before a page can go live. For a lot of our content, that process is important; for example, our Thunderbird pages couldn’t be published until we were sure Thunderbird was going to be our email client recommendation, and we’d developed enough content to be worth making an announcement. (And really, we still haven’t made a formal announcement about Thunderbird, because as soon as we do that, people will want to know when we’ll be migrating them, and we’re still working on our schedule for that. The short answer is: within the next six months).
We need a communication mechanism that has a better signal-to-noise ratio than email (what percentage of your incoming email did you actually read today?), but less formality than our web site. Fortunately, technology has already helped us out with this one; blog software is easy to install and use (we’re using WordPress), and it’s easier to be informal in a blog context. Plus, the ability for readers to add comments can create an open dialog that saves everyone from having to ask the same questions over and over.
I’ll be posting news, announcements, and random thoughts about computing in L&S on a regular basis. Pretty soon (once it goes through our editorial process!) we’ll have an advice article on how to subscribe to blogs using RSS, which can keep you updated without the notices getting lost in your email.
We’re also planning to offer blog space to any departments who use our server for their web site; if the department chair or IT manager wants a blog, it’s easy for us to add a new blog to fit into your existing web site.
