MIT SIPB Script Services for Athena default storage engine changed from MyISAM to InnoDB

November 20, 2014 at 7:07 pm by in

We have changed the MySQL default storage engine on from MyISAM to InnoDB. This change only affects newly created tables. Existing tables are unaffected, with the exception noted below of Trac databases. No user action is required.

InnoDB offers many improvements over MyISAM and has become the default engine upstream as of MySQL 5.5. Even though still runs MySQL 5.1, we made this change because it is required by Trac 1.0.2. We have also converted all Trac databases to InnoDB to let them continue working with Trac 1.0.2.

If you wish to take advantage of the new features provided by InnoDB, you can convert existing tables using the ALTER TABLE command. You can still create new MyISAM tables by passing the ENGINE=MyISAM parameter to CREATE TABLE. You can also convert InnoDB tables back to MyISAM with ALTER TABLE.

Note that the version of InnoDB running on does not yet support FULLTEXT indexes. We expect this to be eventually fixed when we upgrade to MySQL 5.6 or later. Until then, tables that use FULLTEXT indexes should be left on the MyISAM engine.

.htaccess files no longer require mode 777

June 12, 2009 at 12:57 am by in

It is no longer necessary to use chmod 777 .htaccess to mark your .htaccess files readable by Apache. As of May 30, 2009, Apache is now given implicit read access to all file with names beginning in “.ht”, such as .htaccess or .htpasswd (assuming the AFS directory is readable by daemon.scripts, as is automatically the case in your web_scripts directory by default).

CGI scripts will soon require the executable bit

October 30, 2008 at 4:16 pm by in

If you write custom scripts on, you will need to be aware of an important new requirement: we will soon require the UNIX executable bit to be set on your scripts. This affects scripts written in any language other than PHP. This is a standard requirement on UNIX systems, but due to a technical quirk of the original design, it has not been enforced on up to this point. Therefore, you may need to adjust the executable bit on some of your scripts.

We currently plan to implement this change on Saturday, Nov. 8, 2008.

What you need to do

Make sure that the executable bit is set on any script that will be run on the servers. You can check this on Athena, using a command similar to the following:

athena% ls -l /mit/andersk/web_scripts
-rwxr-xr-x  1    39270 anders     115 2008-03-14 19:11 test.cgi
-rw-r--r--  1    39270 anders      79 2008-04-23 22:22 test2.cgi

The bit to look for is the ‘x’ in the fourth column. In this example, test.cgi has the executable bit set, and test2.cgi does not. You can fix test2.cgi as follows:

athena% chmod +x /mit/andersk/web_scripts/test2.cgi
athena% ls -l /mit/andersk/web_scripts
-rwxr-xr-x  1    39270 anders     115 2008-03-14 19:11 test.cgi
-rwxr-xr-x  1    39270 anders      79 2008-04-23 22:22 test2.cgi

Version control

If your custom script is in a version control repository, you may additionally want to ensure that this change to the executable bit is recorded in the repository.

  • For Subversion, run
    svn propset svn:executable ON file.cgi
    and then make a commit.
  • For CVS, make a forced commit by running:
    cvs commit -f -m "" file.cgi
  • Git will automatically detect the change when you git add the file.

Technical details

In the original design of 2004, the AFS kernel module was modified so that the servers would see every file as having the executable bit turned on. This was necessary because every page—including static content pages like HTML files and JPG images—was executed as a CGI script, using the Linux binfmt mechanism. It soon became clear that this mechanism had a fundamental security problem, so it was redesigned, but the AFS patch was kept for backwards compatibility.

However, the nonstandard semantics of the executable bit have been increasingly interfering with certain applications on, such as the popular Git revision control system. We have therefore decided to disable it after a short transitional period.

We are collecting logs of scripts that are being executed without a proper executable bit, and we will contact the owners of any affected scripts that we find. If your custom scripts are infrequently accessed, you may need to test them yourself using the directions above.

New features on

March 25, 2008 at 1:55 am by in

If you develop websites on, 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 instead of The new URLs are easier to type and more secure against cross-site scripting attacks. On, current web browsers (supporting SNI) will receive a valid SSL certificate for * 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 --user 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 as well as Athena and Debathena.

© 2004-2020, the SIPB project.
These pages may be reused under either the GFDL 1.2 or CC-BY-SA 3.0.
Questions? Contact

You are currently connected to