THIS PAGE IS UNDER CONSTRUCTION

Sites

Mifos's web face to the community consists of two production web sites:

• mifos.com is the public-facing site targeting a general audience and potential customers
• mifos.org Targets the user community, presenting information on deployment, supporting services, and a wiki.

Site configuration

Components

These two sites are powered by a single instance of Pressflow, a distribution of Drupal. Drupal is a PHP-based, open-source, content-management system. Pressflow enhances Drupal for performance, scalability, availability, and testing.

Drupal's standard component stack consists of Apache, PHP, and mySQL.

Virtual hosts and multi-site architecture

Both mifos.org and mifos.com are served by the same Drupal code base, which is set up as a multi-site installation. On the production server, 'mifos.org' is set up as a virtual host served by /path-to-mifos/sites/mifos.org, and likewise for 'mifos.com'.

Code version control — Git

Drupal's code, modules, style, and other parts of these Web sites are all version-controlled by Git.

/var/local/git/mifoswww on mifos.com is a git clone (repository). This is where the live server and the test/stage server push to and pull from. In git parlance, this means /var/local/git/mifoswww is the remote named "origin" for the servers.

Development

The following are instructions for anyone to submit patches to mifos.com or mifos.org.

Setting up a local development environment

In order to submit a patch you must first develop and test the patch locally. Here are instructions for setting up a local environment. We assume that you know how to develop in Drupal and that you have installed the necessary development stack (PHP, Apache, mySQL). Excellent instructions can be found in Drupal's online handbooks. In particular, see this page for help setting up a local development environment. These instructions describe only those steps needed to set up a local environement for mifos.org and mifos.com.

Note that YOU MUST USE mySQL, since the sample database is a mySQL dump.

Install the Mifos code base

1. Create a directory that it is accessible by your web server. In these instructions it is assumed that it's named mifos-local.
2. Cd to mifos-local and clone the Git repository

   git clone git://mifos.git.sourceforge.net/gitroot/mifos/www
   

3. You should now see a clone of Mifos code, configuration files and other files in directory mifos-local/www. If you'd like, you can rename the directory.

Load sanitized databases

A sanitized database containing configuration information is provided for development only.

1. Download and load into mySQL a sample of each site's database from ?????. [TODO implement procedures for getting the db]. Each of the sites mifos.org and mifos.com maintains its own database, so be sure that you download both.
2. Log in to mySQL with administrative rights and grant user mifos full rights on each database. In these instructions, we'll assume that you've named them mifos_org and mifos_com.

   mysql > GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES, CREATE TEMPORARY TABLES
              ON `mifos_com`.* TO 'mifos'@'localhost' IDENTIFIED BY 'mifos';
   mysql > GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES, CREATE TEMPORARY TABLES
              ON `mifos_org`.* TO 'mifos'@'localhost' IDENTIFIED BY 'mifos';
   

3. Make create a copies of sites/default/default.settings.php and place them where the two sites can find them:

   $ cp sites/default/default.settings.php /sites/default/settings.php
   $ cp sites/default/default.settings.php /sites/mifos.org/settings.php
   

4. Modify each settings file to point to the correct database and user:
   1. In sites/default/settings.php:

      ...
      $db_url = 'mysql://mifos:mifos@localhost/mifos_com';
      ...
      

   2. In sites/mifos.org/settings.php:

      ...
      $db_url = 'mysql://mifos:mifos@localhost/mifos_org';
      ...
      

Set up virtual hosts

You should simulate virtual hosting locally. But if you add 'mifos.org' and 'mifos.com' to your hosts file, all requests from your pc will get routed to your local site, rendering you unable to access the production sites. To get around this, set up local aliases – for example, 'mifos.org.local' and 'mifos.com.local' – but make sure that Git ignores them when submitting changes.

1. Add local sites to your installation and soft-link them to the real subdomains

   > mkdir /path-to-mifos/sites/mifos.org.local
   > ln \-s /path-to-mifos/sites/mifos.org /path-to-mifos/sites/mifos.org.local
   > mkdir /path-to-mifos/sites/mifos.com.local
   > ln \-s /path-to-mifos/sites/mifos.com /path-to-mifos/sites/mifos.com.local
   

2. add 'mifos.org.local' and 'mifos.com.local' to your list of virtual hosts. For example, in Linux add these lines to your /etc/hosts file:

   127.0.0.1  mifos.org.local
   127.0.0 1  mifos.com.local
   

3. Add virtualhost entries to your Apache configuration. A copy of mifos.org's virtual-host configuration is attached. Customize it for your local environment.
4. Restart Apache.
5. Test your installation by surfing to http://mifos.org.local, and compare the result to http://mifos.org.

Install external dependency – Apache Solr

finish this section

Submitting patches

Use git format-patch, then send the patch to the mifos-developer mailing list. You may also clone our www repository at sf.net, push changes to a public repository and send a pull request to the mifos-developer mailing list.

Administration

The following must be performed by an administrator with root access to the live servers.

Relevant clones

The "www" repository on sf.net is a public clone. This clone is the primary location where contributions to mifos.com and mifos.org will be solicited. All clones are kept in sync manually.

Making changes

All changes (except user-generated content and changes in the database) are done as git patches. For example:

• upgrading Drupal
• adding a new Drupal module
• upgrading or otherwise changing an exsiting Drupal module

VCS exclusions

Certain things are not committed to version control. These files must be manually maintained (see .gitignore files in the public clone):

• robots.txt
• settings.php
• user-generated content
• the Drupal database

To push content live

• create a patch
• apply the patch to the test/stage server working tree
• if the change looks good, do a "git push" from the test/stage server working tree
• do a "git pull" in the live server working tree
• manually push live anything not tracked in VCS
  • user-generated content (TODO: add steps on how to do this)
• push the changes to the public clone

Schedule for Upgrades/Security Patches

[10/19/2010 2:21:04 PM] Adam Monsen: Ed,
will you set up a schedule for changes/upgrades to the sites? ie,
something like:
        A dev/ops person will push changes to mifos.com/mifos.org the
        first Thursday of every month at 9am Pacific.
        
        Drupal module security upgrades will be performed by the end of
        day the first Wednesday of every month, hence, will be included
        in the push to live on the first Thursday of the month.
Per recommendations of Jim Stamper, upgrades to Drupal, contrib module upgrades, and any necessary patches will be applied monthly. A dev/ops person will push changes to mifos.com/mifos.org the second Thursday of every month at 9am Pacific.  Drupal module security upgrades will be performed by the end of day the second Wednesday of every month, hence, will be included in the push to live on the second Thursday of the month.

Subscribe to Drupal Security Announcements to be aware of any security advisories and any patches to install. 

To revert

First, put out the fire

To immediately revert the live server to a known good state, use "git log" to find a commit, then "git checkout COMMIT_SHA1" to change the working tree to that commit.

Posterity

The more permanent fix must be made in source control. Use "git revert" or simply manually undo the change in another commit, then repeat the process outlined above to push content live.

Other notes

Changes to the following may need to be reverted manually

• database schema/data
• Drupal user-generated content