Actions

Developer Area/Developer Environment

From Mahara Wiki

< Developer Area
Revision as of 15:04, 25 February 2022 by Gold (talk | contribs) (syntax highlight)
 
Overview Finding your way around Dev setup Dev tools Contributing Testing
Keep in touch API Docs Architecture Release Instructions Plugins

This page explains how to set up a copy of Mahara for development purposes.

The Docker version

Included in the main codebase is a docker version of Mahara with Behat capabilities. Before you try this, you will need to have Docker installed. See: https://docs.docker.com/engine/install/ubuntu/

The instructions for running the docker version are here:
https://git.mahara.org/mahara/mahara/-/blob/main/docker/README.md

Please feel free to update if there are missing instructions that would be helpful to others.

The short version

Mahara is a fairly standard PHP web application. You mainly need to place it in your web server and give it a database, and a file storage directory. If you haven't set up a PHP web application before, skip to "the long version" down below.

  1. Set up your Apache web server. For development purposes, it is often handy to have the web root sitting inside your home directory.
  2. Retrieve a copy of the Mahara codebase. Place it in your Apache web root.
  3. Create a Mahara "dataroot" directory outside of your web root. Make it read/writeable by Apache.
  4. Create a database instance and database user for Mahara to use.
  5. Edit the Mahara "config.php" file so that Mahara knows the location of its dataroot directory, and its database login credentials.
  6. Run the Mahara installer by visiting your Mahara site in your web browser. If you are missing any required PHP modules, Mahara should tell you. Depending on what you already have installed, you may need one or more of these:
    • If you're on Ubuntu 16.04 or later
      1. php-pgsql
      2. php-gd
      3. php-curl
      4. php-json
      5. php-zip
    • If you are using Mysql instead of Postgres
      1. php7.4-mysql or
      2. php-mysql

The long version (for Windows)

If you want to install your developer environment on Windows, please check the Windows instructions.

The long version (for Linux)

The instructions explain one way to set up an installation of Mahara for development purposes. These instructions are specifically for Ubuntu Linux, although the process will probably be quite similar in other Linux versions.

The following instructions are for Ubuntu 16.04 and above unless otherwise noted.

1. Install required packages:

sudo apt install \
    make curl wget xvfb git gitk postgresql php7.4-common php-cli libapache2-mod-php7.4 \
    php7.4-curl php7.4-gd php-json php-ldap php-pgsql php-xmlrpc php-zip php-xml php-mbstring \
    nodejs node-gyp php7.4-pgsql php7.4-xml php7.4-xmlrpc php7.4-mbstring libssl-dev npm

Note on php versions: At the time of writing (Nov 2020), php 7.4 has a year of active development remaining, and we are expecting the release of php 8.0 sometime soon. Php 7.4 is currently the recommended version to install. Sometimes there is a generic package _and_ a version-specific package to be installed. [PHP supported versions](https://www.php.net/supported-versions.php)

If you see any errors with the install, you may want to try installing in chunks. See the Troubleshooting section

Set 7.4 as apache2's version of php

sudo a2enmod php7.4

Check which version of Node you are running with node -v

If you are running one of the long term service (lts) versions, 8.x or 10.x, that should work with Mahara fine. If you are running a higher version, or Node is not installed, you will need to add a version to run with Mahara.

2. Get a copy of the Mahara code from git. We'll put it under your home directory, in a new directory called "code": See also Getting Code from Git

cd ~
mkdir code
cd code
git clone https://git.mahara.org/mahara/mahara.git

Or, if that failed, use:

$ git clone https://github.com/MaharaProject/mahara.git

Or, if you have an account on the Mahara gitlab then do the following:

$ git clone [email protected]:mahara/mahara.git

3. Give the Apache web server access to your Mahara code directory:

sudo chmod a+rx ~/code/mahara

3a. To avoid a possible 403 error later, confirm that your code directory permissions are also drwxr-xr-x

ls -la ~/

To fix, run:

sudo chmod a+rx ~/code

Your home directory permissions should be drwx--x--x Check with:

ls -la /home

Fix with:

sudo chmod a+x /home/[name of your home directory]

4. Create a PostgreSQL database user:

sudo -u postgres createuser -P -D -R -S maharauser

You'll be prompted for a password. Enter maharapassword for the password.

If Postgres is not available, check its status and if it says that it's inactive, start the service:

service postgresql status
sudo service postgresql start

Now create a database:

sudo -u postgres createdb -Omaharauser mahara-main

5. Using a text editor, copy these contents into a file and save it to ~/code/mahara/htdocs/config.php:

<?php
$cfg = new stdClass();

$branch = 'main';

// database connection details
// valid values for dbtype are 'postgres8' and 'mysql5'
$cfg->dbtype   = 'postgres';
$cfg->dbhost   = 'localhost';
$cfg->dbuser   = 'maharauser';
$cfg->dbname   = "mahara-$branch";
$cfg->dbpass   = 'maharapassword'; 

$cfg->dataroot = "/var/lib/maharadata/$branch";

$cfg->sendemail = true;
$cfg->sendallemailto = '<your email address>';

$cfg->productionmode = false;
$cfg->perftofoot = true;

Make sure to replace <your email address> with your email address.

If you're mainly testing, and you don't find the stack traces in these screen messages particularly useful, adding $cfg->log_backtrace_levels = LOG_LEVEL_ENVIRON; to config.php will display important warning messages on a single line, without stack traces.

6. Create a dataroot directory (this is where Mahara stores uploaded files):

sudo mkdir /var/lib/maharadata
sudo mkdir /var/lib/maharadata/main
sudo chown www-data:www-data /var/lib/maharadata/main

7. Set up a new local domain name "mahara" for your Mahara site, in /etc/hosts:

sudo sh -c "echo '127.0.0.1 mahara' >> /etc/hosts"

8. Increase your PHP "post_max_size" setting to 32M in php.ini:

If you are using Ubuntu 16.04 or later, these files will be under the version of php you are using, e.g. /etc/php/7.4:

sudo sh -c "echo 'post_max_size = 37M' >> /etc/php/7.4/cli/php.ini"
sudo sh -c "echo 'upload_max_filesize = 32M' >> /etc/php/7.4/cli/php.ini"
sudo sh -c "echo 'post_max_size = 37M' >> /etc/php/7.4/apache2/php.ini"
sudo sh -c "echo 'upload_max_filesize = 32M' >> /etc/php/7.4/apache2/php.ini"

Note: The 'post_max_size' is slightly bigger as a POST command also contains some wrapper information. That wrapper is just text strings and relates to how much the form submits. So usually, 1MB should be enough, but to be on the safe side, 5MB would be better, which then also works for larger uploads.

9. Create an Apache configuration file to point to your copy of Mahara. You can do this by first copying the following contents into a file called "mahara.conf", saved in your home directory. See also: Changing Hostnames

 <VirtualHost *:80>
  ServerName mahara
  DocumentRoot /home/<your username>/code/mahara/htdocs
 
  <Directory /home/<your username>/code>
    Options Indexes FollowSymLinks MultiViews
    Require all granted
  </Directory>
 
  ErrorLog /var/log/apache2/error.log
  LogLevel info
 
  CustomLog /var/log/apache2/access.log combined
  DirectoryIndex index.php index.html
 </VirtualHost>

Then copy the file into your Apache sites-enable directory. The name to give the file will also vary depending on what version of Ubuntu you are using.

sudo cp ~/mahara.conf /etc/apache2/sites-available/mahara.conf

10. Enable the site in Apache:

sudo a2ensite mahara
sudo apache2ctl configtest
sudo apache2ctl graceful

11. Set up cron:

sudo vim /etc/cron.d/mahara
* * * * * www-data /usr/bin/php /home/<your username>/code/mahara/htdocs/lib/cron.php

If you do not wish to get cron emails every minute, use the following instead:

sudo vim /etc/cron.d/mahara
* * * * * www-data /usr/bin/php /home/<your username>/code/mahara/htdocs/lib/cron.php >/dev/null 2>&1


Save your file.

12. Set up npm and gulp

The main Mahara git repository includes SCSS files that compile into CSS files, instead of including CSS files directly. We compile these using a Gulp (NodeJS) script that's included with the code. This can easily be invoked via our Makefile by doing "make css", but it requires setting up a couple of additional items first.

First you'll need to run "npm install" from within the Mahara code directory, to get npm to properly set up all the proper caches and such.

cd /home/<your username>/code/mahara
npm install

Once that's finished, you'll need to install the npm "gulp" package using the "-g" (global) flag, so that "gulp" can be run as a CLI command. This requires using sudo.

cd /home/<your username>/code/mahara
sudo npm install -g gulp

Note that Mahara runs with at least version 10.x of node. This section needs updating Note: In Mahara 18.10 we upgraded dependencies to work with latest node 8.x (LTS), you may need to update node via:

  sudo npm cache clean -f
  sudo npm install -g n 
  sudo n 8.11.3 (latest at patch)

Then update node-sass bindings:

  sudo npm rebuild node-sass

13. Build the CSS

Now that this is done, you can build the CSS files. The easiest way to do this is by doing "make css" in the Mahara code directory. This will run the necessary series of instructions written out in the Makefile.

cd /home/<your username>/code/mahara
make css

If you see a lot of errors, such as depreciation warnings for .css files, try deleting /home/<your username>/code/mahara/package-lock.json and then re-running "nvm install" and "make css", which should resolve the issues.

13a. Build the CSS in non-production mode

Sometimes it gets confusing where the sass info comes from to compile the css files. Too make things easier you can edit the 'Makefile' and change the production mode to false

production = false

Then run the "make css" again - this will compile the *.css files in an easier to read format with comments about which sass file contributed to the chuck of css code, eg:

/* line 27, /home/robertl/code/mahara-devel/mahara/htdocs/theme/raw/sass/layout/_footer.scss */
.admin .footer .footer-inner {
  padding: 10px; }
/* line 36, /home/robertl/code/mahara-devel/mahara/htdocs/theme/default/sass/layout/_footer.scss */
.admin .footer .footer-inner {
  padding: 20px 10px;
  background: none;
  border: 0;
  border-radius: 0; }

14. Go to the site in your browser.

http://mahara/

15. You should see the Mahara installer page. If you do, congratulations! Your development environment is now set up.

Trouble-shooting

Ubuntu 18.04 & PHP 7.2

If you are using Ubuntu 18.04 and php 7.2, you may need to use the "php7.2-*" and installing all at once doesn't work for you:

To help with installing you should install in chunks to help diagnose / fix problems. First do:

sudo apt-get install make curl wget xvfb git gitk postgresql

Once that is installed do:

sudo apt-get install php7.2-common php-cli libapache2-mod-php7.2 php7.2-curl php7.2-gd

If you get the error "The following packages have unmet dependencies" try downgrading your php7.2-common to a compatible version:

sudo apt-get install php7.2-common=7.2.3-1ubuntu1

then run the previous command again

Once that is installed do:

sudo apt-get install php-json php-ldap php-pgsql php-xmlrpc php-zip php-xml php-mbstring nodejs node-gyp

You may also need to install some specific php7.2 versions of these:

sudo apt install php7.2-pgsql php7.2-xml php7.2-xmlrpc php7.2-mbstring

and then:

sudo apt-get install libssl-dev

If you get the error "The following packages have unmet dependencies", try downgrading your libssl1.1 to a compatible version:

sudo apt-get install libssl1.1=1.1.0g-2ubuntu4

then run the previous command again.


Enabling apache2's version of PHP

When you do:

sudo a2enmod php7.2

And see errors like: Considering dependency mpm_prefork for php7.2: Considering conflict mpm_event for mpm_prefork: ERROR: Module mpm_event is enabled - cannot proceed due to conflicts. It needs to be disabled first! Considering conflict mpm_worker for mpm_prefork: ERROR: Could not enable dependency mpm_prefork for php7.2, aborting

You will need to disable the chasing MPM options:

sudo a2dismod mpm_prefork
sudo a2dismod mpm_worker
sudo a2dismod mpm_event

Then do:

 sudo a2enmod php7.2

this way the php7.2 mod should auto enable the correct MPM.


Dataroot & Ubuntu 18.04/PHP 7.2

If you are upgrading to Ubuntu 18.04/PHP 7.2 from earlier version you will also need to go into your dataroot directory (path is defined in the config.php file) and delete the 'dwoo' and 'sessions' sub-directories found there. They will be automatically generated again.


Using MySql8

If you are going to be using MySql 8 or later, you will need to do the following:

We need to add a line to our mysql conf file so that we can log in with older format passwords, so edit:

vi /etc/mysql/mysql.conf.d/mysqld.cnf

And make sure we have

[mysqld]
default_authentication_plugin=mysql_native_password

You will need to set the db user to use the native password

CREATE USER 'maharauser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'mahara';
MySQL in Docker

If you have Docker available you can spin it up a dedicated container for it.

Installing Node versions

Check which version of Node you are running with

node -v

If you are running one of the long term service (lts) versions, 8.x or 10.x, that should work with Mahara fine. If you are running a higher version, or Node is not installed, you will need to add a version to run with Mahara.

You can find various instructions on how to upgrade NodeJS on your distribution depending on your preference on package manager. (There are a couple of links at the bottom of this section.)

A straight-forward way to manage multiple versions of Node is to use NVM:

Once you have it installed run:

nvm install --lts
nvm use --lts

This will download the latest lts version of Node and set it to default. Then if you need to switch versions for other projects, you can do so with "nvm use <version>".

Links to alternative ways of installing Node:


ts-php versions - also add set alternatives here Note on changing versions: you can see which version apache is using by adding phpinfo() in your code.

Adding another branch

1. Create a new local branch for it in git (replace 1.10 / 110 with the version of Mahara for which you want to add a branch)

$ cd ~/code/mahara
$ git checkout -t origin/1.10_STABLE

2. Create the sitedata directory for the new branch:

$ sudo mkdir /var/lib/maharadata/110stable
$ sudo chown www-data:www-data /var/lib/maharadata/110stable

3. Create a database:

$ sudo -u postgres createdb -Omaharauser mahara-110stable

4. Change your ~/code/mahara/htdocs/config.php to point to the 1.10 branch:

$branch = '110stable';

5. Go to the site in your browser to run the Mahara installer:

http://mahara/

 

Switching back to the main branch

1. Change the config.php file:

$branch = 'main';

2. Switch to the right git branch:

$ cd ~/code/mahara/
$ git checkout main

 

Reset the database

1. Delete the old database:

$ sudo -u postgres dropdb mahara-main

2. Create a new one with the same name:

$ sudo -u postgres createdb -Omaharauser mahara-main

3. Go to the site in your browser to run the Mahara installer again:

http://mahara/

If you reset the database a lot, you might want to try out the "maharawipe.sh" utility at https://github.com/agwells/mahara-devtools

Testing a change submitted to Gerrit

1. Go to the change page, for example:

 https://reviews.mahara.org/#change,230

2. In your local repository, switch to the branch listed in the Gerrit change (in this case: main):

$ cd ~/code/mahara
$ git checkout main

3. Update your config.php to use the right branch, too.

4. Copy the "Anonymous Git" URL in the "Download" section of "Patch Set X" and run it in ~/code/mahara to check the branch out, for example:

$ git fetch git://reviews.mahara.org/git/mahara refs/changes/30/230/1 && git checkout FETCH_HEAD
$ make css

5. After finishing the testing, go back to main:

$ git checkout main
$ make css

 

Submitting a change to Gerrit

If you want to contribute a patch to the Mahara project yourself, please check out the wiki page on contributing code. There is also a troubleshooting page in case you run into issues pushing code to Gerrit.

 

Copying a local install to another

This example uses the directory 15stable as an example for the new install and the 14stable install as database and sitedata directory to copy.

1. Do a checkout of the code into a new directory:

$ cd ~
$ mkdir code
$ cd code
$ git clone [email protected]:mahara/mahara.git 15stable

2. Copy the database:

$ sudo -u postgres pg_dump -Fc mahara-14stable > 14stable.pg
$ sudo -u postgres createdb -Omaharauser mahara-15stable
$ sudo -u postgres pg_restore -O -j4 -d mahara-15stable -U maharauser -W -h localhost 14stable.pg

If you've not given the user 'maharauser' full privileges yet (should only need to do this once)

$ sudo -u postgres psql -d mahara-15stable -c 'GRANT ALL PRIVILEGES ON SCHEMA public TO maharauser;'
$ sudo -u postgres psql -d mahara-15stable -c 'GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO maharauser;'
$ sudo -u postgres psql -d mahara-15stable -c 'GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO maharauser;'
$ sudo -u postgres psql -d mahara-15stable -c 'GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public TO maharauser;'

3. Change the wwwroot in the new database:

$ sudo -u postgres psql mahara-15stable
delete from config where field = 'wwwroot';
Ctrl + d to exit

4. Create the config file ~/code/mahara/htdocs/config.php:

<?php
$cfg = new StdClass;

$branch = '15stable';

// database connection details
// valid values for dbtype are 'postgres8' and 'mysql5'
$cfg->dbtype   = 'postgres8';
$cfg->dbhost   = 'localhost';
$cfg->dbuser   = 'maharauser';
$cfg->dbname   = "mahara-$branch";
$cfg->dbpass   = 'mahara'; 
$cfg->dbprefix = '''''''; 

$cfg->dataroot = "/var/lib/maharadata/$branch";

$cfg->sendemail = true;
$cfg->sendallemailto = 'your email address';

$cfg->log_dbg_targets     = LOG_TARGET_SCREEN | LOG_TARGET_ERRORLOG;
$cfg->log_info_targets    = LOG_TARGET_SCREEN | LOG_TARGET_ERRORLOG;
$cfg->log_warn_targets    = LOG_TARGET_SCREEN | LOG_TARGET_ERRORLOG;
$cfg->log_environ_targets = LOG_TARGET_SCREEN | LOG_TARGET_ERRORLOG;
$cfg->perftofoot = true;

5. Copy the source sitedata directory into the new sitedata folder:

$ sudo cp -r /var/lib/maharadata/14stable/ /var/lib/maharadata/15stable
$ sudo chown -R www-data:www-data /var/lib/maharadata/15stable

6. Add a new entry to /etc/hosts:

 127.0.0.1 15stable

7. Create a new Apache vhost file in /etc/apache2/sites-available/15stable.conf:

 <VirtualHost *:80>
  ServerName 15stable
  DocumentRoot /home/<your username>/code/15stable/htdocs
 
  <Directory /home/<your username>/code>
    Options Indexes FollowSymLinks MultiViews
    Order allow,deny
    Allow from all
  </Directory>
 
  ErrorLog /var/log/apache2/error.log
  LogLevel info
 
  CustomLog /var/log/apache2/access.log combined
  DirectoryIndex index.php index.html
 </VirtualHost>

8. Enable the site in Apache:

$ sudo a2ensite 15stable
$ sudo apache2ctl configtest
$ sudo apache2ctl graceful

9. Go to the site in your browser to run the Mahara installer:

http://15stable/

10. Resetting the admin password:

If you do not know the login info for the copied site's database or the new site uses a different 'passwordsaltmain' from the old one you can reset a users password via the CLI script "reset_password.php", for example if you need to reset the 'admin' user's password you can go:

sudo -u www-data php htdocs/admin/cli/reset_password.php -u=admin -p=changeme

This will reset the password and on next login you will be prompted to change the password again to something more robust.

 

Elasticsearch

If you want to test the Elasticsearch search plugin, you'll also need to set up and run an Elasticsearch server. See Developer Area/Setting up Elasticsearch.  

ClamAV

If you want to test the ClamAV virus protection see Setting up ClamAV

 

Set up site for local https://

You will need to set up your Mahara developer site with an SSL certificate if you want to use the web services functionality as that is only available over https.

You should already have Apache 2 installed on your computer. Otherwise, Mahara wouldn't run. Install the openssl and ssl-cert packages:

$ sudo apt-get install openssl ssl-cert

1. Enable SSL in Apache 2:

$ cd /etc/apache2/mods-enabled/
$ ls
$ sudo a2enmod ssl
$ service apache2 restart
$ ls

You should see "ssl.conf" and "ssl.load"

2. You'll need to check that the port for SSL traffic is configured.

$ cd ..
$ cat ports.conf

If you see <IfModule ssl_module> Listen 443, you are good to go.

3. Enable SSL also in your Mahara Apache 2 config file.

$ vim sites-available/mahara.conf (or the name of your config file of the site for which you want to enable SSL)

Paste the following into the .conf file after the </VirtualHost> for port 80. The last re-write rules are only necessary if you use the "Clean URL" functionality.

<IfModule mod_ssl.c>
<VirtualHost *:443>
  ServerName mahara

  DocumentRoot /home/'''<your username>'''/code/mahara/htdocs
  <Directory /home/'''<your username>'''/code>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Require all granted
    </Directory>

  ErrorLog /var/log/apache2/mahara-ssl-error.log
  LogLevel info

  CustomLog /var/log/apache2/mahara-ssl-access.log combined

    #   SSL Engine Switch:
    #   Enable/Disable SSL for this virtual host.
    SSLEngine on

    #   A self-signed (snakeoil) certificate can be created by installing
    #   the ssl-cert package. See
    #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
    #   If both key and certificate are stored in the same file, only the
    #   SSLCertificateFile directive is needed.
    SSLCertificateFile    /etc/apache2/ssl/apache.pem
    SSLCertificateKeyFile /etc/apache2/ssl/apache.key

    #   Server Certificate Chain:
    #   Point SSLCertificateChainFile at a file containing the
    #   concatenation of PEM encoded CA certificates which form the
    #   certificate chain for the server certificate. Alternatively
    #   the referenced file can be the same as SSLCertificateFile
    #   when the CA certificates are directly appended to the server
    #   certificate for convinience.
    #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

    #   Certificate Authority (CA):
    #   Set the CA certificate verification path where to find CA
    #   certificates for client authentication or alternatively one
    #   huge file containing all of them (file must be PEM encoded)
    #   Note: Inside SSLCACertificatePath you need hash symlinks
    #         to point to the certificate files. Use the provided
    #         Makefile to update the hash symlinks after changes.
    #SSLCACertificatePath /etc/ssl/certs/
    #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
    #   Certificate Revocation Lists (CRL):
    #   Set the CA revocation path where to find CA CRLs for client
    #   authentication or alternatively one huge file containing all
    #   of them (file must be PEM encoded)
    #   Note: Inside SSLCARevocationPath you need hash symlinks
    #         to point to the certificate files. Use the provided
    #         Makefile to update the hash symlinks after changes.
    #SSLCARevocationPath /etc/apache2/ssl.crl/
    #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

    #   Client Authentication (Type):
    #   Client certificate verification type and depth.  Types are
    #   none, optional, require and optional_no_ca.  Depth is a
    #   number which specifies how deeply to verify the certificate
    #   issuer chain before deciding the certificate is not valid.
    #SSLVerifyClient require
    #SSLVerifyDepth  10

    #   Access Control:
    #   With SSLRequire you can do per-directory access control based
    #   on arbitrary complex boolean expressions containing server
    #   variable checks and other lookup directives.  The syntax is a
    #   mixture between C and Perl.  See the mod_ssl documentation
    #   for more details.
    #<Location />
    #SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
    #            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
    #            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
    #            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
    #            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
    #           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
    #</Location>

    #   SSL Engine Options:
    #   Set various options for the SSL engine.
    #   o FakeBasicAuth:
    #     Translate the client X.509 into a Basic Authorisation.  This means that
    #     the standard Auth/DBMAuth methods can be used for access control.  The
    #     user name is the `one line' version of the client's X.509 certificate.
    #     Note that no password is obtained from the user. Every entry in the user
    #     file needs this password: `xxj31ZMTZzkVA'.
    #   o ExportCertData:
    #     This exports two additional environment variables: SSL_CLIENT_CERT and
    #     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
    #     server (always existing) and the client (only existing when client
    #     authentication is used). This can be used to import the certificates
    #     into CGI scripts.
    #   o StdEnvVars:
    #     This exports the standard SSL/TLS related `SSL_*' environment variables.
    #     Per default this exportation is switched off for performance reasons,
    #     because the extraction step is an expensive operation and is usually
    #     useless for serving static content. So one usually enables the
    #     exportation for CGI and SSI requests only.
    #   o StrictRequire:
    #     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
    #     under a "Satisfy any" situation, i.e. when it applies access is denied
    #     and no other module can change it.
    #   o OptRenegotiate:
    #     This enables optimized SSL connection renegotiation handling when SSL
    #     directives are used in per-directory context.
    #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>

    #   SSL Protocol Adjustments:
    #   The safe and default but still SSL/TLS standard compliant shutdown
    #   approach is that mod_ssl sends the close notify alert but doesn't wait for
    #   the close notify alert from client. When you need a different shutdown
    #   approach you can use one of the following variables:
    #   o ssl-unclean-shutdown:
    #     This forces an unclean shutdown when the connection is closed, i.e. no
    #     SSL close notify alert is send or allowed to received.  This violates
    #     the SSL/TLS standard but is needed for some brain-dead browsers. Use
    #     this when you receive I/O errors because of the standard approach where
    #     mod_ssl sends the close notify alert.
    #   o ssl-accurate-shutdown:
    #     This forces an accurate shutdown when the connection is closed, i.e. a
    #     SSL close notify alert is send and mod_ssl waits for the close notify
    #     alert of the client. This is 100% SSL/TLS standard compliant, but in
    #     practice often causes hanging connections with brain-dead browsers. Use
    #     this only for browsers where you know that their SSL implementation
    #     works correctly.
    #   Notice: Most problems of broken clients are also related to the HTTP
    #   keep-alive facility, so you usually additionally want to disable
    #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
    #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
    #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
    #   "force-response-1.0" for this.
    BrowserMatch "MSIE [2-6]" \
        nokeepalive ssl-unclean-shutdown \
        downgrade-1.0 force-response-1.0
    # MSIE 7 and newer should be able to use keepalive
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
 
  <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteRule ^/user/([a-z0-9-]+)/?$ /user/view.php?profile=$1&%{QUERY_STRING}
    RewriteRule ^/user/([a-z0-9-]+)/([a-z0-9-]+)/?$ /view/view.php?profile=$1&page=$2&%{QUERY_STRING}
    RewriteRule ^/group/([a-z0-9-]+)/?$ /group/view.php?homepage=$1&%{QUERY_STRING}
    RewriteRule ^/group/([a-z0-9-]+)/([a-z0-9-]+)/?$ /view/view.php?homepage=$1&page=$2&%{QUERY_STRING}
  </IfModule>
</VirtualHost>
</IfModule>

4. Create the SSL folder in /etc/apache2/ if it doesn't already exist:

$ sudo mkdir /etc/apache2/ssl

5. Run the following command to set up your local cert and follow the ensuing steps for generating it:

$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.pem

When it asks you for the "Common name", you can put your local server's name.

6. Restart Apache.

$ sudo service apache2 restart

If you have an error message that pertains to your SSL site, you'll need to fix it first before continuing.

7. Test the Apache config:

$ sudo apache2ctl configtest

8. Delete the old wwwroot as that still points to http://. If you left it, you wouldn't see all assetts.

$ sudo -u postgres psql mahara-main
delete from config where field = 'wwwroot';
Ctrl + d to exit

9. Go to your Mahara URL and use https://. Since you created a self-signed cert, your connection will be untrusted. Proceed anyway.

10. Now you can use your developer site with web services as well.

Set up Behat

You can use the automated testing suite from Mahara 15.04 on. There is a separate installation page for Behat.