Since I set up a system to automatically create school Moodle servers on demand, 109 Moodle instances have been spawned on the shared-code Moodle system. That means at least one teacher from 109 different public schools and ESDs in Oregon has been interested enough in the ORVSD offerings to give it a try. Of course, only a small number of them are far enough along to be using it with their students, but there are quite a few teachers getting up to speed with how the tools work. I’m delighted to see the system seems to be scaling up remarkably well. It’s not having any problem at all dealing with so many separate vhosts/databases running on the same Moodle install.

I expect we’re going to see an explosion of use by the end of the summer and beginning of next fall. I guess I better get those disk arrays ordered … we’re probably going to need a lot more disk space soon.

So what are you waiting for? Apply now at: http://code.google.com/soc/2008/

First, though, credit where credit is due. Martin Langhoff posted almost all of what we needed to do here. All I needed to do is expand upon it to fit our needs.

Second, what the modified code actually does:
1) config.php looks in Moodle dirroot/multisite_config for an ini file matching the server name. I.E.: fqdn.domain.org.ini
2) If found, the ini file is parsed and used to populate the Moodle $CFG

On to the code!

1) Create a directory in your Moodle wwwroot named multisite_config and make sure it’s readable by the web server
2) Create a moodledata_shared directory to hold the various sites’ moodledata directories
3) Modify the wwwroot/config.php file to look like:
<?php /// Moodle Configuration File
unset($CFG);
$CFG->dirroot = '/var/www/moodle_shared';
// Determine hostname
$hostname = $_SERVER['HTTP_HOST'];
if (isset($_ENV['HTTP_HOST'])){ // this is to support cronjobs on a per-host basis
$hostname = $_ENV['HTTP_HOST'];
}
// Load multi-site configs
$multisite_config_filename = "$CFG->dirroot/multisite_config/$hostname.ini";
if (file_exists($multisite_config_filename)) {
$sites_array = parse_ini_file($multisite_config_filename);
} else {
// Whoops! No ini found, fall back to a default Moodle host
$URL="http://default-moodle.domain.org";
header ("Location: $URL");
die("<pre>Unable to open site configuration file for '$hostname'. Has the config file been created?\n</pre>");
}
$CFG->dbtype = 'mysql';
$CFG->dbhost = $sites_array[dbhost];
$CFG->dbname = $sites_array[dbname];
$CFG->dbuser = $sites_array[dbuser];
$CFG->dbpass = $sites_array[dbpass];
$CFG->dbpersist = false;
$CFG->prefix = 'mdl_';
$CFG->wwwroot = $sites_array[wwwroot];
$CFG->dataroot = '/var/www/moodledata_shared/'.$hostname;
$CFG->admin = 'admin';

4) Create an ini file for each Moodle instance you want to host and place it in the Moodle dirroot/multisite_config/ directory. An example ini file for a fictitious template.domain.org Moodle instance:
; multisite_config.ini
[template]
dbhost = localhost
dbname = template_db_name
dbuser = template_user
dbpass = dbpassword
wwwroot = http://template.domain.org/moodle

5) Create a moodledata_shared/hostname directory for the moodledata stuff.

I have a canned mysqldump file I use to create new Moodle sites instead of using the GUI (along with an automated system to create the databases and generate the ini files, but that’s a topic for another post another time). Since I wanted to avoid creating a vhost for every Moodle instance and having to bounce Apache every time I add a new one, I set up a wildcard domain to point at the moodle_shared webroot. But this should work equally well with explicitly-defined Apache vhosts.

Todo:
1) Modify the GUI config to have it write the ini files directly.
2) Look into having site-specific modules. As it stands right now, all sites get the same modules. So far we haven’t run into module conflicts or sites wanting customized versions of modules, but I expect it’s only a matter of time.
3) Performance and scaling testing. This seems to work well enough with the approximately 50 low traffic sites I’m running now, but I’m not sure how much of a penalty the reading and parsing of the ini file imposes. It may not scale well on high traffic sites.
3a) Not sure how well this might be adapted to a multi-server or clustered environment.

Thanks to Google’s generous support, the OSL was able to host three varied and exciting projects:

• Darko Ilic - Watch & Listen, One Laptop Per Child

  Mentored by Brad Morgan and the rest of the OSL team working on the Watch & Listen project, Darko quickly and energetically joined our team building a media player and encoder for the OLPC XO laptops. He impressed us with his enthusiasm in the application process and his work throughout the summer has confirmed our initial impressions. Darko has become a valued and productive member of the Watch & Listen development team. For more information on Watch & Listen, see: http://olpc-player.helixcommunity.org

• Seth Lemons - XUL/XPCOM Kiosk

  Mentored by Eric Searcy, Seth took on the very challenging task of building a truly cross-platform kiosk-mode browser based on the Mozilla Gecko engine. Given the difficulties with stripping down a general-purpose web browser down to the bare minimum needed for a kiosk, Seth chose to build it from scratch using XUL/XPCOM on top of the Gecko engine. A daunting and complicated task, Seth nevertheless managed to get a functioning prototype up before the mid-term evaluation and has been improving it ever since. To see the code and try it our for yourself, go to: http://code.google.com/p/osl-fx-kiosk

• Rob Wohleb and Silas Snider - Drupal/Google API: Drupal modules implementing the Google Premium/Education API

  Mentored by Justin Gallardo and Greg Lund-Chaix, Seth and Rob forged into new territory blending the power of Google Apps with the Drupal content management system. With the recent release of the Google Provisioning and Single Sign-On APIs to the Google Premium and Domains for Education just before the 2007 Summer of Code began, we had a golden opportunity to add support for single sign-on and provisioning of Google hosted domain accounts to Drupal. Using Rob and Silas’ excellent work users can now have Google domain accounts automatically created when a Drupal user is added, and have them be automatically signed into their Google domain account when they log into Drupal. Some additional features in the works include Google Calendar<->Drupal event synchronization and Google mail list<->Drupal user group linkage. To see more about the modules, check out: http://code.google.com/p/drupal-google-api

This year’s Summer of Code was an unmitigated success. We are proud to say all four of our students had committed functional, good quality code before the mid-term evaluation in early July and continued to improve upon that code throughout the rest of the summer. Communication between mentors and students - a critical component - was much improved from previous years and contributed greatly to this year’s successes. Looking ahead - a bit of optimism on our part that Google will choose to renew the Summer of Code program for 2008 - we have some advice and lessons learned to share with the community:

1. Communication: The more the better. Communicate early and often. The more talking among the students and mentors and the project community, the better. Communication builds relationships and trust. It helps bring the student more deeply into the project community and has the potential to turn a summer project into a long-term relationship.
2. Code: Submit early, submit often. It’s much easier for mentors to do their jobs if students submit code as often as possible. Mentors can help bring students into the project community, but by far the most valuable service a mentor can provide is help and feedback with the student’s work - the actual code.
3. Life happens: Illnesses crop up and schedules shift. Murphy’s law strikes. Milestones change, features are added and/or dropped. It is vital that both the students and the mentors be flexible. There’s an excellent chance the project that arrives at the final evaluation is very different than the one proposed in the spring. Students and mentors need to be talking regularly and often so that expectations and deadlines change as the summer progresses - see #1.
4. Education: Last and certainly not least - learn. Even if the code produced ends up being something completely different than what was expected or incomplete, remember that the Summer of Code is as much about learning to participate in FOSS projects and communities as it is about the code itself. Of course it’s good to have student code incorporated into the projects, but it’s even more important to bring talented new contributors into the community. Even if the code written during the summer never makes it into a release, the project or community has gained a potential long-term participant that can produce more code in years to come than they could have done in the course of a single summer. If the code they submit does make it into a release, all the better, but the talented and motivated people SoC brings into our communities are invaluable.

A big “Thank you!” to everyone at the Google Open Source Programs Office and to all of the 2007 Summer of Code participants. The world is a better place because of your efforts.

This year IBM has surpassed their past generosity and has upgraded the booth we’ll be sharing with them and Portland State University to a 20′x20′ booth right at the front enterence of the hall!

Wow. I guess I better make sure I’ve got a clean shirt. :-)

Thanks to Centerstance for sponsoring the grub, O’Reilly and Apress for the door prize books, and the wonderful crew at the Oregon Bus Project for hosting the event.

You: Articulate and educated. Enjoy long weekends at trade shows and install-fests. Willing to relocate to thriving college town. Must not be allergic to penguins. Enthusiasm a must. An affinity for Gentoo a definite plus.

Us: Creative and enthusiastic entity living in an academic environment. Into Xen and FOSSing regularly.

http://jobs.oregonstate.edu/applicants/Central?quickFind=51171

FreeConferences++

I have a Gateway laptop. It’s OK. Not great, but it gets the job done. Last week while I was putting the laptop in my bag a CD in a paper sheath slid between the lid and the body of the laptop and popped the “\” key off the keyboard. After muttering a few dark things about weak-ass construction I dropped a line to Gateway tech support and requested they fix it. After confirming my street address twice and asking for an on-site repair, they said they’d fix it. Cool.

So I get to my desk this afternoon after running some lunchtime errands to find a suspiciously keyboard-shaped UPS box on my desk. Hmm. Must be hard to fit an on-site tech in there, thinks I. Sure enough, opening the box reveals a disembodied laptop keyboard, a packing slip and a short form letter saying, “Please find enclosed the part that you requested along with easy-to-read installation instructions.”

Except there were no instructions. Nor was there the promised on-site support technician to install it.

Oh, and did I mention that the keyboard in the box already had its “Alt” key broken off of it inside the packaging?