Basically, you make three directories:

• one containing the content and an .htaccess file denying all access
• one containing an .htaccess file allowing access via basic auth
• one containing an .htaccess file allowing access via pubcookie

The directories with access via the different authentication methods will also contain symbolic links to either files in the content directory(if the files are not going to change much) or to another directory in the content directory so that you can change the files around without redoing the symbolic links.

You can take a look at an example implementation of this scheme in the multi-auth directory on my staff Web site.

Bonus:

• Put the “skip-innodb” line into the .my.cnf file.
• Stop the DB.
• Start the DB.

InnoDB is gone.  Yaaay.

detail:

bin/mysqldump -u root -p –lock-tables –add-drop-database DATABASE_NAME > DATABASE_NAME.sql

/rc22/d77/agraf/bin/rpl  ‘ENGINE=InnoDB’ ‘ENGINE=MyISAM’ DATABASE_NAME.sql

bin/mysql -u root -p DATABASE_NAME < DATABASE_NAME.sql

It is a relief to have the WordPress documentation using the latest, more secure version of WordPress again.  Of course this blog is using WordPress 2.5.1 and the new http-authentication plugin now.

• MediaWiki instructions went from version 1.11.0 to 1.12.0
• MoinMoin instructions went from version 1.5.3 to 1.5.8

The new version of MediaWiki has an option for selecting InnoDB or MyISAM, so the previous changes to that documentation don’t seem quite as necessary, but they still make sense, so I’ve left them intact.

• Python was upgraded from 2.5 to 2.5.2
• The sqlite3 (3.5.4) command-line tool was added.
• Python’s sqlite3 module now functions properly
• The MS SQL Server PHP module was added, which allows connections to MS SQL servers using PHP.

Here’s a brief mention on the MySQL Reference Manual of problems that InnoDB has when its data or log files are stored on NFS volumes: Restrictions on InnoDB Tables

Warning

It is not a good idea to configure to use datafiles or logfiles on NFS volumes. Otherwise, the files might be locked by other processes and become unavailable for use by MySQL.

The issue in the cases I see commonly seems to be that when the NFS client system is rebooted, the NFS server does not get any notice that locks should be released on the files.  When the NFS client comes back up from the reboot and reconnects to the server, those files are still locked, and the client cannot get a new lock on them.  This causes MySQL to issue errors like the following:

InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.

and this:

InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means ‘Resource temporarily unavailable’.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!

Now that step has been added to the end of the Ruby Gems on Your Account instructions.

I know we are running an out-of-date installation of Ruby and Rails, but we have requested a new one. Keep your fingers crossed.

Our Web & Web dev hosts
ruby 1.8.4
ruby on rails 1.1.6

Current stable versions
ruby 1.8.6
ruby on rails 2.0.2

I have changed the WordPress instructions to use the old 2.0.11 version of WordPress until the plugin gets fixed.

Installing MediaWiki
http://www.washington.edu/computing/web/publishing/mediawiki.html

These instructions include a default installation that uses the MediaWiki user and authentication system, as well as an option for using the Pubcookie SSO authentication system that is used for most UW Technology applications at the University of Washington. The problem with the way those instructions say to set things up is that you need to log in with Pubcookie before you can even view the wiki. This isn’t always what’s desired.

A couple weeks ago two users requested a means of setting up MediaWiki so that it could be anonymously read, but users would need to log in using Pubcookie in order to edit a page. I came up with a solution which they were both happy with, and which seems to work. I am not sure if there are ways of breaking MediaWiki when it is configured in this manner, but it seems to be working fine so far.

Here is a copy of MediaWiki configured with the new anonymous read/Pubcookie required for edits configuration:

Test Wiki

The instructions have now been updated to include the new section called “Requiring UW NetID Authentication only for Editing“.

The next thing to work on is changing the MediaWiki documentation to inform users that they should probably use the MyISAM storage engine on MediaWiki installations backed by MySQL on the UA Web servers. This is because InnoDB databases will not come back automatically if ovid is restarted without shutting down MySQL first. The culprit is NFS, which is used to serve all the files in user Web and home directories on the UA system.

The upgrade will include Apache, PHP, OpenSSL, mod_uwa, and enabling compression.

More detail is available on the public Web page for this upgrade.

Update: This work was completed in March.