MoodleDocs - User contributions [en]

Development:CVS for developers

2008-06-13T04:57:05Z

Theforce: /* Merging fixes */ -- note re: db schema added

'''CVS''' is the Concurrent Versioning System, a commonly-used way of managing source code for large software projects. CVS keeps all versions of all files so that nothing is ever lost, and usage by different people is tracked. It also provides ways to merge code if two or more people are working on the same file. All code and all versions are stored on a central server (in the case of Moodle, at cvs.moodle.org). The [http://cvsbook.red-bean.com/cvsbook.html CVS book] holds more information about CVS than you need.

If you just want to download Moodle using CVS to run a site, then you probably don't need this page - please see [[CVS for Administrators]] instead.

==Joining the project as a developer==

So, you've been offered CVS write access to help us develop and maintain Moodle! Welcome aboard!

To be able to write changes into [http://cvs.moodle.org/ Moodle's CVS archive], you first need to have an account on the server. Only trusted developers get these accounts. To request access, go to the "Apply for CVS Access" tab on the CVS page on Moodle.org (http://moodle.org/cvs). Tell us what modules you'd like to access (e.g. a language module), and why. You'll receive notification in a day or so.

With that done, you should have all the permissions you need, so you just need to set up your machine and download the current source code so you can start working on it.

For the examples on this page, let's assume your username is '''myusername''' and your password is '''mypassword'''.

==CVS modules==

Within CVS, the word "modules" refers to separate collections of code. In Moodle we have the following modules within our repository:

* '''moodle''' - the main Moodle source code
* '''lang''' - all the language packs
* '''[[Development:contrib|contrib]]''' - user contributions and other assorted code in development
* '''mysql''' - a customised phpMyAdmin to plug into Moodle for database admin
* '''windows-cron''' - a small package that makes cron possible on Windows systems
* '''docs''' - various extra user-contributed documentation

Most people are working on the existing features in the moodle module, but many are also contributing new ideas in the contrib modules. Once code reaches a certain level of maturity in the contrib area, it can be migrated over into the main moodle tree.

==Basic CVS commands==

===CVS on Unix===

Moodle CVS uses ssh as a transport layer for security, so you will have to set a CVS_RSH environment variable in your Unix shell. It's best to put these commands in your .bashrc or .cshrc so you don't have to type it all the time:
setenv CVS_RSH ssh (for csh, tcsh etc)
export CVS_RSH=ssh (for sh, bash etc)

Next, you can check out the latest development version of Moodle using this (all one line). NOTE: Don't try to do run this first CVS command over an existing moodle installation: start fresh with a new directory!:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle

The command is similar for other CVS modules:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib

If you want to checkout a single plugin (attendance block as an example here) from contrib into the current directory, you can use:
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance

Note that you will be prompted for mypassword for each command unless you set up authorized keys. Read [[Development:SSH_key|SSH Keys]] for more details on how to set those up.

Now, you should have a new 'moodle' directory. You can rename it and move it around if you like. Go into it:
cd moodle

All the latest Moodle files should be in there. You can now change files in your copy. To compare your files and directories against the main CVS copy on the server use cvs diff, e.g.:
cvs diff -c config-dist.php
cvs diff -c lang

To fetch the latest updates from the server use:
cvs update -dP

To copy your new files back to the server you would do something like:
cd lang/ca
cvs commit

You will be prompted to add some comments (depends on your default text editor). Please write a meaningful, descriptive comment and '''always include the name of any tracker issues that talk about the issue you are fixing''' (eg '''MDL-XXXX''').

After that your changes will be sent to the CVS server and stored in the repository. Done!

To save more time you can put default arguments into a file called .cvsrc in your home directory. For example, mine contains:
diff -c
update -dP

Try 'cvs help' for more details ...

===CVS on Mac OSX===

You can follow the same instructions as for Unix (above) in a terminal window. However, the cvs command is not installed by default in an OSX. You first need to install the XCode Tools. You should find this on your original installation disk. Failing that it can be downloaded (a fairly hefty download) from the Apple developer web site ([http://developer.apple.com]).

===CVS on Windows===

First, you need to download a completely fresh copy of Moodle using your developer account.

1. Get TortoiseCVS from tortoisecvs.org and install it, then reboot. (Tortoise is not currently supported on vista but [http://www.syntevo.com/smartcvs/index.html SmartCVS] works well).

2. Find or create a new folder somewhere where you want Moodle to be downloaded to.

3. Right-mouse-click that folder and choose "CVS Checkout" from the menu. You should see a dialog box.

4. Copy this text into the CVSROOT field (using your own username!):

:ext:myusername@cvs.moodle.org:/cvsroot/moodle

5. Under the "Module" field, type "moodle" to get the latest development version of Moodle, "contrib" to get the contributions directory, or "mysql" to get the MySQL Admin module.

6. Press the button: "OK" and everything should be downloaded.

A dialog box should show all the files being downloaded, and after a while you should have a complete copy of Moodle. After this first checkout, you can fetch the latest updated files from the CVS server:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Update".
# Sit back and watch the logs scroll by. Take note of conflicts that may occur if your local code has changes that conflict with the incoming versions - you will need to edit these files and resolve the conflicts manually.

After modifying files (you will notice their icons change from green to red!), you can commit them back to the CVS server like this:

# Right-mouse-click on your Moodle folder (or any file) and select "CVS Commit...".
# In the dialog box, type a clear description of the changes you are committing. '''Always include the name of any tracker issues related to what you are fixing''' (eg '''MDL-XXXX''').
# Click "OK". Your changes will be sent to the server.
# If you create a folder, BE CAREFUL about using the "CVS Add" option as it will add the folder to CVS without requiring a commit. Once added, the folder cannot be removed from CVS even though it will be pruned so long as it is empty.

Please note that as of April 15 2008, TortoiseCVS 1.10.6 might not work really well with Windows Vista. You could report bugs to TortoiseCVS site (hosted by SourceForge) or google "TortoiseCVS vista" for more details.

==CVS commit messages==

Every commit you make to CVS should have a commit message containing
* a tracker issue id like MDL-12345 (if necessary, create an issue before committing, the only exception is for very minor typos.)
* A brief description of the problem you are fixing. (If you are feeling lazy, you may be able to get away with copying and pasting the issue summary from the tracker.)
* If it is not immediately obvious, a brief summary of why this change fixes the problem. If a longer description is necessary, you may also want to add more information to the tracker issue, or Moodle Docs, but the code changes + commit message should provide enough clues to how the fix works on their own.

==Working with branches==

This diagram shows how the main moodle module branches into different versions over time.

[[Image:Cvstree.png|CVS tree]]

To see all the current tags and branches that are available, use this command on any old file (such as index.php in the top moodle directory):
cvs status -v index.php

Some tagging guidelines:
* Tag and branch names should always be all upper-case.
* Tags and branches should ALWAYS be applied to the entire module (all of Moodle). Don't tag individual files or directories.
* We don't allow renaming of tags because people may be relying on them, so get them right the first time!

===Trunk development===

The Trunk of CVS is the main development version of Moodle. In CVS it is also known as the HEAD, or default branch.

Moodle developers try to keep this stable as possible, but as it usually contains new code it probably has bugs and small instabilities.

Every now and then we decide the product has enough features to make a release. At this time, the trunk is tagged with a MOODLE_XX_BETA tag (in case we ever want to roll back to that point) and a new branch is formed for the release, called MOODLE_XX_STABLE.

A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs.

===Stable branches for each release===

As soon as the stable branch MOODLE_XX_STABLE is created, development efforts will fork into two streams for a while. Some people may continue working on new features in the trunk for the next release, but most developers should be concentrating on using the current STABLE branch and fixing bugs that are found in it.

You can switch your local copy of Moodle to the STABLE version using the following command in Unix from the root directory:
cvs update -dP -r MOODLE_XX_STABLE

After that, all the commands described above will apply to that stable version. To return to the trunk version just issue:
cvs update -dPA

On Windows clients you should have a menu from which you can choose the branch.

Once the new STABLE branch really stabilises, a release can be declared. Packages are created for distribution and the branch will be tagged (by Martin Dougiamas) with a tag named: MOODLE_XXX

===Merging fixes===

All bug fixes in any STABLE branch should be merged back into the trunk so that they become available in future versions of Moodle. A floating tag called MOODLE_XX_MERGED needs to be maintained to keep track of the last merge. The procedure for such a merge is as follows (I'm using CVS on the Unix command line but the steps are the same for any CVS client):

[[Image:Merging.png|thumb|right|300px|This diagram summarises the process]]
1. I highly recommend keeping one checked out copy of each stable branch and the trunk/head version locally to make it easier to jump between them. Set them all up as virtual web sites on your development machine. I use directories like /moodle/18, /moodle/19 /moodle/dev etc.

2. Update to the latest stable version (I'll use XX in the example but it could be 18, 19 etc) for the relevant files, and do a cvs diff just to double-check exactly what you are checking in. Note you only need to update the files/directories you are working in, but sometimes it help to update everything anyway just to do a final check on the functionality using the web.

cd /moodle/XX/user
cvs update -dPA
cvs diff -c file1.php file2.php

3. If all looks OK, check in the fix to the stable branch. Make sure that the commit message contains the bug tracker ID (eg MDL-1111) and a decent description of your thoughts on the fix. If you don't specify a message in the command line, you'll be put into an editor to type one.

cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php

4. Go to the very latest trunk version and make sure it's up-to-date.

cd /moodle/dev/user
cvs update -dPA

5. Merge everything into your local copy of the trunk from your stable branch since the last merge. You can use the same sequence of (4) and (5) to merge the changes into other stable branches too (to backport the fix to the previous stable versions).

cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php

6. Carefully watch the update logs for conflicts, and fix every file that you see with a conflict. Afterwards, it may help to just run a diff to make sure the result is what you expected:

cvs diff -c file1.php file2.php

7. Check your merged local copy back into CVS trunk version

cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php

8. Go back to your branch version

cd /moodle/XX/user

9. Update the floating merge tag for the affected files (so that it matches MOODLE_XX_STABLE) so that this process can be repeated next time

cvs tag -RF MOODLE_XX_MERGED file1.php file2.php

Finally, the values for $version in all the Moodle version.php files within the stable branch should not be updated at all if possible (except the last digit if absolutely necessary). The reason is that someone updating from a very stable version to the next very stable version could miss database upgrades that happened on the trunk.

In other words, if you have changes to the database schema to commit to a stable branch, please check with Martin Dougiamas, or one of the other core Moodle developers.

===Merging fixes with TortoiseCVS===
Situation: we did a fix on MOODLE_19_STABLE. We modified one file for this fix. This fix needs to be done on Moodle 1.8 and trunk(HEAD). All following CVS instructions will be applied on the file that we changed.

1. Update to the latest stable versions (HEAD included)

Right click on the moodle folder
CVS update
OK

2. On your MOODLE19 branch: commit your fix

Right Click on the file
CVS commit
Enter a description: "MDL-XXXX bug fix description"
OK

3. On your HEAD repository: merge the changes

Right Click on the file
CVS>
Merge...
Start: MOODLE_19_MERGED
End : MOODLE_19_STABLE
OK

4. If the resulting file have some conflicts, TortoiseCVS displays a red square on the file icon. Edit the file with your text editor and resolve the conflicts.

5. Run a diff to make sure the result is what you expected

Right Click on the file
CVS Diff
OK

6. Commit the fix

Right Click on the file
CVS commit
Enter a description: "MDL-XXXX bug fix description, merged from 19"
OK

We've commit MOODLE_19_STABLE and trunk. It's now time to backport the change on MOODLE_18_STABLE.
On your MOODLE18 branch: reproduce step 3 to 6.

7. On your MOODLE19 branch: update the floating merge tag for the affected file

Right Click on the file
CVS>
Tag...
Tag: MOODLE_19_MERGED
Select 'Move existing tag'
OK

On your MOODLE18 branch: reproduce step 7 (with Tag: MOODLE_18_MERGED).

===Feature branches for large changes===

Occasionally, there may be a very large feature that needs to be checked in so several people can work on it, but it is too unstable to be included in the main development trunk.

In these cases a short-term branch can be created to work on the feature, and then merged back into the main trunk as soon as possible. An example called MOODLE_19_WIDGET branch can be seen in the above diagram.

If you need to do this for your new WIDGET feature, follow these steps:

1. Discuss with other developers to make sure it's necessary!

2. Make a new tag on the trunk (for all of moodle) called MOODLE_XX_WIDGET_PRE

cvs tag -R MOODLE_XX_WIDGET_PRE

3. Create your branch called MOODLE_XX_WIDGET

cvs tag -Rb MOODLE_XX_WIDGET

4. Work in that branch until the feature is reasonably stable. Commit as necessary.

cvs commit

5. When ready, merge the whole branch into the trunk, fix conflicts, commit it to the trunk and then abandon the branch.

cvs update -dPA
cvs update -kk -j MOODLE_XX_WIDGET
cvs commit

Good luck, be careful and have fun!

==Who on earth is ...==

Some of the people committing to the Moodle codebase have non-boring account names on the CVS server. If you are ever looking at a CVS commit, and wondering "who on earth is this purpleblob person?" This information is now available at: [http://moodle.org/mod/cvsadmin/view.php?cid=1 Moodle developers with write access].

==Tips and Hints==
* [http://moodle.org/mod/cvsadmin/ Change your password or SSH key] (click on "Update my developer information")
* [[Tracking Moodle CVS with git]]
* [http://moodle.org/mod/forum/discuss.php?d=34472 Merging Custom Moodle Code With Stable Releases]
* [[Unmerged files]]: To see if you've forgotten to merge any file.
* [http://ximbiot.com/cvs/manual/ CVS Manual]
* [[Development:contrib|Introduction to the '''contrib''' area of CVS]]

==See also==

* [http://tracker.moodle.org/browse/MDLSITE-193 "All developers should switch to using the cvs.moodle.org alias"]
* [[CVS for Administrators]]

[[Category:Developer|CVS for developers]]
[[Category:Developer tools]]

[[es:CVS para desarrolladores]]
[[fr:CVS pour développeurs]]
[[pt:CVS_para_programadores]]

AuthMoodle

2008-06-04T02:56:58Z

Theforce: added link to MediawikiSSO

=AuthMoodle.php=

(See also [[MediawikiSSO]])

* an extension of mediawiki's AuthPlugin class so that moodle users can sign in to a mediawiki with the same login/pw
* used in this https://docs.moodle.org mediawiki production site
* download from http://moodle.org/file.php/5/moddata/forum/366/196104/AuthMoodle.php
* first posted by Martin Dougiamas in april 2006 in http://moodle.org/mod/forum/post.php?reply=196104 as an attachment

quoting Martin's instructions based on the root folder of the wikimedia installation:

Save it in extensions/AuthMoodle.php.
Then you just put this in LocalSettings.php:

<pre>
require_once( 'extensions/AuthMoodle.php' );
$wgAuth = new AuthMoodle();
$wgAuth->setAuthMoodleTablePrefix('');
$wgAuth->setAuthMoodleDBServer('yoursite.org');
$wgAuth->setAuthMoodleDBName('yourdb');
$wgAuth->setAuthMoodleUser('yourdbuser');
$wgAuth->setAuthMoodlePassword('yourdbpass');
</pre>

==Bugs with AuthMoodle in mediawiki 1.7==
* preferences are no longer sticky (they pretend to save but don't really save) '''fix:''' disable this '''if''' in includes/SpecialPreferences.php around line 290:

'''/*'''
if (!$wgAuth->updateExternalDB($wgUser)) {
$this->mainPrefsForm( wfMsg( 'externaldberror' ) );
return;
}
'''*/'''
* if the moodle database prefix is different from the mediawiki database prefix must match (or be blank) '''fix:''' edit the function tableName in includes/Database.php around line 1310 and 1313:

function tableName( $name ) {
global $wgSharedDB''', $wgAuth''';
# Skip quoted literals
if ( $name{0} != '`' ) {
if ( $this->mTablePrefix !== '' && strpos( '.', $name ) === false
'''&& strpos ($name, $wgAuth->mAuthMoodleTablePrefix) === false''' ) {

* for mediawiki 1.7, I had to change line 33 to '''includes/'''AuthPlugin.php and comment out line 223-226 (refers to a non-existent function)

==See also==
* bugtracker conversation leading to creation of AuthMoodle http://moodle.org/bugs/bug.php?op=show&bugid=4666
* usage info: [[MoodleDocs:Authentication]]
* based probably on http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/auth/

[[Category:MoodleDocs]]
[[Category:Developer]]

User:Luke Hudson

2008-04-10T04:57:04Z

Theforce:

I'm one of the developers in the eLearning team at Catalyst IT.

I've been working on Moodle development for nearly two years now, working on a large variety of tasks.

I was born in 1977 in London, but moved to New Zealand about twenty years ago.

I speak French reasonably fluently, as a second language, and I've learned some German and New Zealand Sign Language.

NTLM authentication

2008-02-19T01:02:37Z

Theforce: /* Assumptions */

{{Moodle 1.9}}This document describes how to set up NTLM/Integrated Authentication in Moodle.

This is integrated into Moodle 1.9 onwards.

For earlier versions, it uses a modified version of LDAP Authentication.
The NTLM Authentication module is available in the Modules and Plugins database here:
http://moodle.org/mod/data/view.php?d=13&rid=314

==Assumptions==

#You are running MS Active Directory for Authentication.
#The Server hosting your website is a member of the Active Directory Domain that your users are also members of.
#You are able to define people inside your Network (and authenticated to the Domain) from an IP range or IP range of computers.
#You have "some" basic knowledge of php and are able to configure the index.php with the range of internal IP addresses.
#You are familar with or have read the LDAP authentication documentation.
#The Active Directory domain credentials of your users are returned as '''DOMAINNAME\username''' from your authentication service. If you are using the Winbind service from the Samba project, this can be untrue, depending on your Winbind configuration settings.

If you can not modify your settings to satisfy this last assumption, then you will need to remove or comment out the line that reads:
$username = substr(strrchr($username, '\\'), 1); //strip domain info
and add the relevant lines of code to extract the username part from the domain user credentials and store it in $username.

==Installation on 1.9==

No installation needed. See the Auth/LDAP settings for the NTLM config options. You only have to

*Set the subnet mask
*On IIS: turn on Integrated Authentication
*On Apache - use one of the 3 methods outlined below

==Installation on 1.6/1.7==
#Copy the folder AUTH/NTLM into the AUTH folder of your moodle installation.
#Configure the IP/Subnet Mask in the Config screen.
[https://docs.moodle.org/en/NTLM_authentication#Configuring IP/Subnet Mask see below for more help]
If the IP/Subnet Mask does not give enough complexity for your network, Modify the auth/ntlm/index.php file - for instructions on doing this, view the comments in the file.
#Turn Integrated Authentication ON and Anonymous Authentication OFF for the moodle\auth\ntlm\oncampuslogin.php file. [https://docs.moodle.org/en/NTLM_authentication#How_to_Turn_Integrated_Authentication_on see below for more detailed instructions]
#Visit the admin page of your moodle installation - you should see notification that the NTLM_AUTH module has been installed.
#go to the configuration > variables page, find the dbsessions setting (in 1.8 on admin page server \ sessions page), and set it to "YES" then save the page.
#go to the Authentication admin page and select auth_ntlmtitle as your authentication method Note: - this doesn't display full text as I haven't created a language file for this module - you will also see auth_ntlmdescription instead of a proper description - you don't need to worry about this, as you will be the only one who ever sees this.
#Configure this page with your normal LDAP settings. NOTE: the Alternate Login URL at the bottom of this page (or on the main authentication page in 1.8 - and needs to be set manually to the oncampus url)has been set to the NTLM page. - if you wish uninstall this auth module, you must reset this variable on the new authentication type page. eg - if you wish to revert back to manual authentication, then change to manual, and then make sure you delete the alternate login url at the bottom of the page.
#(OPTIONAL) modify the offcampuslogin page to give errors when students try to prefix their usercode with your domain.
around line 216 find this code, uncomment all the lines and replace the letters 'DOM' with your domain:

if (empty($errormsg)) {
if (strstr(strtolower($frm->username), "DOM\\") <> false) { //NAD - DOM messages.
$errormsg = get_string("invalidlogin") . " DOM\\ is not required!";
} else if (strpos($frm->username, "@") <> false) {
$errormsg = get_string("invalidlogin") . " enter your username - not your e-mail address.";
} else {
$errormsg = get_string("invalidlogin");
}
}

==Installation on 1.5==

See the README in the auth/ntml package.

==How to Turn Integrated Authentication on==
The File ntlmsso_magic.php (1.9 or above) or oncampuslogin.php (1.8 or below) MUST have NTLM/Integrated Authentication enabled at the server or the page will not work.
===IIS Configuration===
Open up IIS, and find the auth/ldap/ntlmsso_magic.php (1.9 or above) or auth/ntlm/oncampuslogin.php (1.8 or below) file,
#right click on the file, choose properties
#under the "file security" tab, click on the Authentication and Access control "edit" button
#untick "Enable Anonymous Access" and tick "Integrated Windows Authentication"
===APACHE Configuration===
There are currently 3 possible methods for this:

====Using the NTLM part of Samba (Linux)====

* Get the plugin here: http://samba.org/ftp/unpacked/lorikeet/mod_auth_ntlm_winbind/ and follow the instructions inside the README file. You'll need to install the Apache development packages in addition to the core C develpment packages.
* Once you have compiled it, put it inside Apache's modules subdirectory (this location depends on a number of factors, like compiling Apache yourself, using different Linux distributions packages, an so on), and load and enable the module in Apache's configuration. For example, if your Apache modules are under <code>/usr/lib/apache2/modules</code>, you'll need something like this in your Apache configuration file (usually called <code>apache2.conf</code> or <code>http2.conf</code>):

<IfModule !mod_auth_ntlm_winbind.c>
LoadModule auth_ntlm_winbind_module /usr/lib/apache2/modules/mod_auth_ntlm_winbind.so
</IfModule>

* Install the Samba <code>winbind</code> daemon package. This packages relies on Samba's configuration file to get some important settings (like the Windows domain name, uid and gid range mappings, and so on). In addition to that, you'll need to make your Linux/Unix machine part of the domain. Otherwise winbind won't be able to pull user and groups informationi from the domain controllers. You should read the Samba documentation to perform this step, but the most important part is having something like the following lines in your <code>smb.conf</code> file (in addition to what you already have there):

workgroup = DOMAINNAME
password server = *
security = domain
encrypt passwords = true
idmap uid = 10000-20000
idmap gid = 10000-20000

: and executing the command (as root):

# net join DOMAINNAME -U Administrator

: where '''DOMAINNAME''' is the NetBIOS windows domain name, and '''Administrator''' an account with enough privileges to add new machines to the domain. You'll need to type this account's password for the command to succeed.

: Also, make sure you have disabled "Microsoft Network Server: digitally sign communications (always)" in your Domain Controllers Security Policy, unless you are using a version of Samba that can sign SMB packets.

* Restart the <code>winbind</code> service to apply the changes and test that it's running ok by executing:

$ wbinfo -u

: You should get the full list of Windows domain users. If you use '''<code>-g</code>''' instead, you'll get the domain groups list.

* Check that your <code>winbind</code> package installed the authentication helper command <code>ntlm_auth</code>, as we'll need it later. We'll assume the helper is located at <code>/usr/bin/ntlm_auth</code>. If yours is at a different location, make sure you adjust the path in the example below.

* Add something like this to your Apache configuration file (usually called <code>apache2.conf</code> or <code>http2.conf</code>). We'll assume that your Moodle <code>$CFG->dirroot</code> directory is located at <code>/var/www/moodle</code> in the example:
: '''For 1.9 or above use''':
<Directory "/var/www/moodle/auth/ldap/">
<Files ntlmsso_magic.php>
NTLMAuth on
AuthType NTLM
AuthName "Moodle NTLM Authentication"
NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
NTLMBasicAuthoritative on
require valid-user
</Files>
</Directory>
: '''For 1.8 or below use''':
<Directory "/var/www/moodle/auth/ntlm/">
<Files oncampuslogin.php>
NTLMAuth on
AuthType NTLM
AuthName "Moodle NTLM Authentication"
NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
NTLMBasicAuthoritative on
require valid-user
</Files>
</Directory>
* Check the permissions of the Winbind pipe directory (Ubuntu places it under <code>/var/run/samba/winbindd_privileged</code>, yours may be placed at a different location). Apache will need to be able to enter that directory, so we need to make sure it has the right permissions. So have a look at the permissions of that directory and note the name of the group assigned to it. The following example is from a Ubuntu 7.10 machine:

$ ls -ald /var/run/samba/winbindd_privileged
drwxr-x--- 2 root winbindd_priv 60 2007-11-17 16:18 /var/run/samba/winbindd_privileged/

:so we see the group is <code>winbindd_priv</code>.

* Instead of modifying the directory permissions (which could break other services that use winbind) we are goint to make the Apache user (<code>www-data</code> in our example, but could be <code>httpd</code>, or <code>nobody</code>, etc.) is part of the appropiate group. Execute the following as root:

# adduser www-data winbindd_priv

: <code>adduser</code> is available in Debian and Ubuntu at least. If your distribution doesn't have <code>adduser</code>, you can edit <code>/etc/group</code> manually to achive the same effect.

* Restart the Apache service to apply the changes. Have a look at Apache's error log to see that everything is ok.

* Couple of gotchas - in Fedora Core, keep alive is turned OFF by default in the httpd.conf - see this bug for further info: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188138 
* Email Dan if you get this working - I'm keen to hear how people go using the samba winbind option!
::-- Hi Dan! I made it work using Ubuntu 7.04. That's what I've used to update the documentation. [[User:Iñaki Arenaza|Iñaki Arenaza]] 10:43, 30 September 2007 (CDT)

====Using the NTLM Auth Module for Apache====
#get the Module from: http://modntlm.sourceforge.net/
#use something like this in your httpd.conf: http://moodle.org/mod/forum/discuss.php?d=45887#211074

====Using the mod_auth_sspi Module for Apache 2 on Windows====
NOTE: This setup is currently being used in a live production environment, and is therefore suitable for such use provided it is correctly configured and tested.

This is the recommended method for Apache 2 on Windows, however it will '''not''' work on Linux/UNIX systems.
It provides better stability and higher performance than other NTLM modules.

* Download the mod_auth_sspi Module from: http://sourceforge.net/projects/mod-auth-sspi/. At the moment of writing this (2007.09.30), the current version is mod_auth_sspi 1.0.4, which has two different ZIP files to download:

::* mod_auth_sspi-1.0.4-2.0.58.zip : Use this file if you are using Apache 2.0.x.
::* mod_auth_sspi-1.0.4-2.2.2.zip : Use this file if you are using Apache 2.2.x.

* Unzip the right file and copy mod_auth_sspi.so (it's inside '''bin''' subdirectory) to your Apache modules directory.
* Edit your Apache 2 configuration file (httpd.conf) to load the module.

<IfModule !mod_auth_sspi.c>
LoadModule sspi_auth_module modules/mod_auth_sspi.so
</IfModule>

* Choose one of the two methods below

: '''Method 1''': This method is recommended for servers that will host a single Moodle instance. Configure NTLM from the main configuration file, add the following to httpd.conf (substitute "C:\moodle" with the path to your Moodle installation e.g. "C:\my-moodle"

:: '''For 1.9 or above use''':
<Directory "C:\moodle\auth\ldap">
<Files ntlmsso_magic.php>
AuthName "Moodle at My College"
AuthType SSPI
SSPIAuth On
SSPIOfferBasic Off
SSPIAuthoritative On
SSPIDomain mycollege.ac.uk
require valid-user
</Files>
</Directory>
:: '''For 1.8 or below use''':
<Directory "C:\moodle\auth\ntlm">
<Files oncampuslogin.php>
AuthName "Moodle at My College"
AuthType SSPI
SSPIAuth On
SSPIOfferBasic Off
SSPIAuthoritative On
SSPIDomain mycollege.ac.uk
require valid-user
</Files>
</Directory>

: '''Method 2''': The alternative method is to use a .htaccess file
:This method is recommended for servers that will host multiple Moodle instances. It allows additional Moodle instances to be configured without restarting apache, and also makes the solution a little more portable. We need to add a directive to the main httpd.conf to allow configuration of authentication within .htaccess files.
<Directory C:\moodle>
AllowOverride AuthConfig
</Directory>

:: '''For 1.9 or above''':
:::Create a new text file named '.htaccess' in the directory 'C:\moodle\moodle\auth\ldap' and add the following directives:
<Files ntlmsso_magic.php>
AuthName "Moodle at My College"
AuthType SSPI
SSPIAuth On
SSPIOfferBasic Off
SSPIAuthoritative On
SSPIDomain mycollege.ac.uk
require valid-user
</Files>

:: '''For 1.8 or below''':
:::Create a new text file named '.htaccess' in the directory 'C:\moodle\moodle\auth\ntlm' and add the following directives:
<Files oncampuslogin.php>
AuthName "Moodle at My College"
AuthType SSPI
SSPIAuth On
SSPIOfferBasic Off
SSPIAuthoritative On
SSPIDomain mycollege.ac.uk
require valid-user
</Files>

:This enables the Moodle folder to be moved to any apache webserver that is configured to allow authentication configuration through .htaccess

For further help and discussion: http://moodle.org/mod/forum/discuss.php?d=56565

==Configuring IP/Subnet Mask==
Subnet masks are based on binary patterns so need a bit of knowledge to understand. The best way to find out what IP/Subnet masks to use is to ask your Network Admin.
* '''(pre-1.9 only)''' Once you have configured your IP/Subnet masks, you can use the check_ip.php page to test if you have set these ranges up correctly.
* The new way of specifiying subnets is even easier/more flexible than before 1.9. Just type them one after the other, separated by commas. You can use several syntaxes:
** Type the network-number/prefix-length combination. E.g. 192.168.1.0/24
** Type the network 'prefix', ending in a period character. E.g. 192.168.1.
** Type the network address range ('''this only works for the last address octect'''). E.g. 192.168.1.1-254
:All the three examples refer to the same subnetwork.
* So assuming you need to specify the following subnetworks:
** 10.1.0/255.255.0.0
** 10.2.0.0/255.255.0.0
** 172.16.0.0/255.255.0.0
** 192.168.100.0/255.255.255.240
:You can type:
10.1.0.0/16, 10.2.0.0/16, 172.16.0.0/16, 192.168.100.0/28
: or:
10.1.0.0/16, 10.2.0.0/16, 172.16.0.0/16, 192.168.100.240-255
:or even:
10.1., 10.2., 172.16., 192.168.100.0/28
:(the last one cannot be expressed as a network 'prefix' as the netmask does not fall in an octect boundary).

==Notes/Tips==
# (pre-1.9 only) When using IIS, dbsessions is required to be set to "YES" because when Integrated authentication is turned on for the oncampuslogin.php page, and dbsessions is set to "NO" then the server impersonates the user to write the session in the moodledata\sessions folder. The recommended fix is to set dbsessions to "YES" so that sessions are stored in the db. The non-recommended alternative method is to allow domain users write access to the sessions directory.
# (pre-1.9 only) If you forget to change the internal IP addresses in index.php to your own, you can just use the offcampuslogin url to login using your admin account. eg: http://yoursite.com/moodle/auth/ntlm/offcampuslogin.php
#If you are using Firefox, you will need to follow these steps:
:*Load Firefox and type about:config in the address box. The configuration settings page should be displayed.
:*In the Filter box, type the word "ntlm" to filter the NTLM strings. You should see three settings displayed.
:*Double-click on "network.automatic-ntlm-auth.trusted-uris".
:*In the box, enter the full URL of your Moodle server. For example <pre>http://moodle.mydomain.com</pre>
:*Close Firefox and restart.

==Specific File information==
(mainly for developers)
#auth\ntlm\index.php This is the page used for the Alternate Login URL setting on the config page for the NTLM plugin. The index.php file handles which login page to use based on the IP address of the user. if inside your network, they should be directed to the oncampuslogin.php screen. if outside your network, they should be directed to the offcampuslogin.php screen. you will need to modify the if statements in this file to match the IP ranges inside your network.
#auth\ntlm\index_form.html this is a copy of the file login\index_form.php. The only change in this file from the standard one is that the form action="index.php" is changed to form action="offcampuslogin.php" this is because anyone who is displayed the form will be an offcampus user.
#auth\ntlm\offcampuslogin.php this is a copy of the file moodle\login\index.php with a couple of minor modifications. the modifications to this file involve the setting of a variable ($onoroffcampus = "offcampus";) this is used by the auth plugin to define which page is being used for authentication. the other modification is for displaying extra error messages to the user. - with all the authentication methods we have students are constantly confused about how to enter their credentials if you use NTLM authentication elsewhere at your site you will be aware of the users having to enter the domain\username when authenticating. - this code block sits around line 215 in the file.
#auth\ntlm\oncampuslogin.php this is a copy of the file login\index.php This file has been modified to get the details of the authenticated user via NTLM.

==See also==
*[http://moodle.org/mod/forum/view.php?id=42 Using Moodle: User authentication] forum
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=45887 NTLM Authentication] forum discussion
*[http://moodle.org/mod/data/view.php?d=13&rid=314 Download the NTLM Authentication Module]
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=80104 Merging AD NTLM SSO into auth/ldap] forum discussion

[[Category:Authentication]]

[[fr:Authentification NTLM]]

Capabilities/mod/scorm:savetrack

2007-12-06T23:11:58Z

Theforce:

*This allows a user to save SCORM/AICC tracks -- in other words, for their scores, etc. to be recorded in Moodle.

[[Category:Capabilities|SCORM]]
[[Category:SCORM]]

[[eu:Gaitasunak/mod/scorm:savetrack]]

Import course data

2007-09-20T03:04:02Z

Theforce: note re: userdata

{{Course admin}}

Course data may be imported from any other course for which the teacher has editing rights.
However, using the Import Course Data feature, will not import user data, such as forum posts and discussions; it will only import the structure of such activities.

1. Select the Import option from the Administration side-block.

2. Next, select the course you wish to import from and click the ''Use this course'' button.

3. You will be presented with a check box list from which you can select the type of activities or resources you wish to import.

4. Finally, click ''Continue'' when done to import that data.

NB: Selecting forums, for example, will import all forums from that course. Currently you cannot import individual items within a module type.

Groups can also be imported as a batch from a file.

Backups, especially in 1.6, offer other creative ways to bring in course material from other courses. See [[Course_backup]] or the backup link on the index.

[[Image:Import.jpg]]

[[Category:Teacher]]

[[fr:Importation]]

Enrolment/OSCommerce

2007-01-29T22:55:33Z

Theforce: added trivial description of work status

Work-in-progress for the OSCommerce enrolment plugin. See http://moodle.org/mod/forum/discuss.php?d=60259

So far, I'm using the Catalyst specific OSCommerce branch, which has some modifications to suit the enrolment plugin for Moodle. Most of the modifications either streamline the purchase process, or disable areas of OSCommerce which are not used in this setup.

The enrolment plugin has been upgraded to suit Moodle 1.7, but needs some checking to see if anything has been missed in the changes from Moodle 1.5 (custom branch, however; closer to 1.6) to 1.7.

More information will be added soon.

Development:Unit tests

2006-08-23T05:30:58Z

Theforce:

The purpose of unit testing is to test the individual parts of the program (functions, and methods of classes) to make sure that each individually does the right thing. Once unit testing has given you the confidence that each part works, then you should use other forms of testing to ensure that the different parts work together properly.

The unit testing framework is based on the [http://www.lastcraft.com/simple_test.php SimpleTest] framework. It was incorporated into Moodle by Nick Freear and Tim Hunt from [http://www.open.ac.uk/ The Open University].

== Running the unit tests in Moodle ==

=== Running the basic tests ===

# Log in with an admin account.
# Go to the admin screen.
# Click on the '''Reports''' link near the bottom of the page.
# Click on the '''Run the unit tests''' link.
# Wait for the tests to run.

=== Options for running the tests ===

At the bottom of the tests page, there is form that lets you adjust the options used when running the tests.

==== Show passes as well as fails ====

Normally, only details of the tests that have failed are printed. Turning on this options shows details of all the passes too.

==== Show the search for test files ====

The tests to run are found automatically be searching the codebase for files whose names match '''test*.php''' in directories called '''simpletest'''. Turning on this option will print a list of the folders searched and the test files found. This is sometimes useful for debugging.

This option is particularly useful when one of your test files has a syntax error. When this happens, you sometimes just get a blank page with no error message. Turning on the show search option lets you see which test file it was that gave the error. If necessary, you can enable this option manually by adding "showsearch=1" to the end of the URL.

==== Run a thorough test (may be slow) ====

If you turn on this option, then as well as looking for files called '''test*.php''', the search also looks for files called '''slowtest*.php'''.

To be useful, the full test run should find most bugs, but not take too long to complete. So if you have very, very detailed tests of an area of the code, it may be better to select a subset for everday testing, and only use the more detailed tests when a bug is reported, or you are doing new development in that area of the code.

This option is most useful when combined with the next option.

==== Only run tests in ====

Normally, tests from all parts of the codebase are run. However, when you are just doing development of one part of the code, that is a waste of time. You can type the name of a folder (for example '''mod/quiz''') or a particular test file (for example '''lib/simpletest/testdatalib.php''') and then only those tests will be run.

[[Image:RunOnlyTheseTests.png|right]] Instead of typing a path into this box, there is an easier way. Whenever a pass or fail is displayed, the name of the test file is printed. Each section of the path name is a link to run only the tests in that folder or file.

== Writing new tests ==

As an example, suppose we wanted to start writing tests for the functions in the file 'question/editlib.php'.

=== Where to put the tests ===

If you have read the first half of this page and were paying attention, you can probably work out that you should create a folder called '''question/testeditlib''', and create a file in there called something like '''testeditlib.php'''.

The skeleton of this file should look like:

<pre><?php
/**
* Unit tests for (some of) question/editlib.php.
*
* @copyright © 2006 The Open University
* @author T.J.Hunt@open.ac.uk
* @license http://www.gnu.org/copyleft/gpl.html GNU Public License
* @package question
*/

/** */
require_once(dirname(__FILE__) . '/../../config.php');

global $CFG;
require_once($CFG->libdir . '/simpletestlib.php'); // Include the test libraries
require_once($CFG->dirroot . '/question/editlib.php'); // Include the code to test

/** This class contains the test cases for the functions in editlib.php. */
class question_editlib_test extends UnitTestCase {
function test_get_default_question_category() {
// Do the test here/
}
}
?></pre>

That is, you have a class called something_test, and in that class you have lots of methods called test_something. Normally, you have one test method for each function you want to test, and you may as well called the test method '''test_name_of_function_being_tested'''.

=== Inside a test function ===

The inside of a test function tyically looks like this:

<pre>function test_get_default_question_category() {
// Set things up in preparation for the test.

// Call the function you want to test.

// Check that the result is what you expected.
}</pre>

For example:

=== Test data ===

TODO

=== setUp and tearDown methods ===

If all your test cases relate to the same area of code, and so need the same set of test data, then you can create a method called <code>setUp()</code> that sets up the test data. If present, this method will be called before each test method. You can write a matching <code>tearDown()</code> method if there is any clean-up that needs to be done after each test case has run.

If you have some test test cases the need one sort of setup, and some other test cases that need a different setup, consider splitting your tests into two separate classes, each with its own <code>setUp()</code> method.

=== Further information ===

The simpletest documentation is at: http://simpletest.sourceforge.net/.

== Changes to your existing code to make it work with unit testing ==

When code is being tested, it gets included from inside one of the simpletest library function. If the code is expecting to be run directly (for example, if it is a view.php or index.php function), you are likely to get errors becuase that expectation is no longer true.

=== Include paths ===

Includes like

<pre>require_once('../../config.php'); // Won't work.</pre>

won't work. Instead, the more robust option is

<pre>require_once(dirname(__FILE__) . '/../../config.php'); // Do this.</pre>

=== Access to global variables ===

Because your code was included from within a function, you can't access access global variables until you have done a global statement.

<pre>require_once(dirname(__FILE__) . '/../../config.php');
require_once($CFG->libdir . '/moodlelib.php'); // Won't work.</pre>

<pre>require_once(dirname(__FILE__) . '/../../config.php');

global $CFG; // You need this.
require_once($CFG->libdir . '/moodlelib.php'); // Will work now.</pre>

== More about unit testing in general ==

The best book I know about unit testing is '''Pragmatic Unit Testing in Java with JUnit'' by Andrew Hunt (no relation) and David Thomas. I know, this book is not called Pragmatic Unit Testing in PHP with SimpleTest. However, it is an excellent book - short, to the point, and very practical. Most of what it says is not specific to Java and JUnit and it is obvious how to apply it in our testing setup.

[[Category:Developer]]