scripts.mit.edu

Upgrade to Fedora 9

scripts.mit.edu has temporarily added a Fedora 9 server to the server pool, in preparation for a full upgrade to Fedora 9 this summer. The server is otherwise configured identically to the existing servers, so all your scripts should continue to run. If you notice any problems with your scripts, please don’t hesitate to contact us at scripts@mit.edu.

Update to WordPress 2.3.3

We’ve just updated our autoinstaller for WordPress to 2.3.3, which includes a security update.

You can install WordPress via:

$ add scripts
$ scripts-wordpress

from any Athena machine, and following the instructions.

By default, we automatically update your installations to keep up with security updates. We’ve updated all 2.3.2 installations to 2.3.3 for those who haven’t disabled upgrades. (You can turn off autoupgrading if you want, and keep up with security upgrades on your own.)

New features on scripts.mit.edu

If you develop websites on scripts.mit.edu, we thought you might like to hear about some of the new little features we’ve quietly developed over the last year.

• You can now access your website from yourname.scripts.mit.edu instead of http://scripts.mit.edu/~yourname. The new URLs are easier to type and more secure against cross-site scripting attacks. On https://yourname.scripts.mit.edu, current web browsers (supporting SNI) will receive a valid SSL certificate for *.scripts.mit.edu. This also works for group lockers.
• Setting up certificate authentication on scripts is easier than ever. Just add three lines to your .htaccess file, and your visitors will be automatically redirected to port 444, which accepts optional client certificates. Visitors without certificates will be shown a friendly error page (which you can customize if you want). You can restrict access by user, AFS group, or other standard Apache authorization modules.
• A new Apache module supports optional authentication. If you add
  

  AuthSSLCertAuthoritative off
  AuthOptional on

  to your .htaccess file, then the Apache authorization process will be bypassed, so that your script can perform authorization itself, and treat authenticated users differently from anonymous users (which will have the REMOTE_USER variable unset).
• You can now install Python modules into your locker using easy_install --prefix=$HOME from the scripts servers, and they will be automatically accessible to Python scripts in your locker.
• nelhage has made the Jifty web framework for Perl available in the jifty locker for scripts.mit.edu as well as Athena and Debathena.

Trac autoinstaller

We’ve just added another autoinstaller to our stable: Trac, the issue tracker everyone seems to use these days for software projects.

You can get a Trac instance up and running for your own project in less than 60 seconds by typing

$ add scripts
$ scripts-trac

from any Athena machine, and following the instructions.

Like all autoinstalled software, Trac instances will be automatically upgraded after the Trac upstream makes a new release. ([see update below] You can turn this feature off if you want, and keep up with security upgrades on your own.)

This brings the count of autoinstallable applications up to 9:

advancedbook
e107
gallery2
joomla
mediawiki
phpbb
phpical
trac
wordpress

You can read more about these applications on our quick-start page.

update: In fact, because of the way Trac works, you can’t turn off autoupgrades in an autoinstalled Trac instance — there’s one central copy of the software on scripts.mit.edu, not a copy in each Trac instance. You can always do a manual install of the software if you really want to handle upgrades yourself.

SSLUserName being disabled

On March 28, 2008, the scripts.mit.edu team will disable the default SSLUserName functionality. The result will be that, with no other configuration, your scripts will no longer receive the user’s e-mail address in the REMOTE_USER environment variable. If you wish to recreate the old functionality, you can create a .htaccess file in your script’s directory containing “SSLUserName SSL_CLIENT_S_DN_Email”. However, we recommend that you use the SSLCert authentication module as described in our FAQ.