Comparisons and advocacy

 
 
Picture of Daniel Brouse
Successful implementations Moodle 2.2+
 

Often the forums are filled questions and comments regarding Moodle noe working as expected. I have enjoyed many years of Moodle installations that I have administered that outperform my college's "official" LMS implementation.

I am planning on migrating to the newest version of Moodle soon. Lack of PHP 5.3+ has been a limiting factor on my hosted site.

I am curious about the different successful soltutions for Moodle 2.2+ that are being used. I am particularly interested in stable small Moodle sites that are inexpensive (I am an instructor and pay for all the costs associated with my site) but would be interested to learn about medium sized and larger implementations also. If you are willing to share can you list:

1) The size of your Moodle installation:

  a) Active courses

  b) Average course size

  c) estimated maximum number of concurent users

2) Your server solution

  a) Example options: Self managed server, Managed Dedicated Server, VPS, Shared hosting, ect.

  b) If you managed the physical server, what hardware and environment stack do you use?

  c) If you have a managed solution - who manages it? What is your monthly/yearly hosting cost?

3) Features/activities of Moodle that are significantly used.

  a) core features/activities that are utilized by your site

  b) plugins and/or complementary programs that are used.

 
Average of ratings:Useful (1)
Picture of Daniel Brouse
Re: Successful implementations Moodle 2.2+
 

I'm going to reply to demonstrate what I am hoping for and to share my Moodle implementation. I am currently using Moodle 2.0.7 but part of this post is to gather information on how I would like to setup a site using the most current version of Moodle.

1) The size of your Moodle installation:

  a) Active courses - 5 that are used daily. Another 6 are available from recent classes for students to use as reference.

  b) Average course size - 34 students/virtual classroom

  c) estimated maximum number of concurent users - ~15 taking quizzes at the same time

2) Your server solution

  a) Example options: Self managed server, Managed Dedicated Server, VPS, Shared hosting, ect. - Shared Hosting

  b) If you managed the physical server, what hardware and environment stack do you use? - NA

  c) If you have a managed solution - who manages it? What is your monthly/yearly hosting cost? Bluehost Pro-Hosting ~$200/year

3) Features/activities of Moodle that are significantly used.

  a) core features/activities that are utilized by your site - The self registration to the site and enrolment password to the classroom, including the captcha are heavily used. The assignment activity, discussion forum activity, quiz activity, and multimedia functionality are also heavily used. My lectures are recorded via Camtasia Studio and then rendered to swf and posted in a metacourse for students to view and/or review. I would like to use the Workshop tool and the wiki as tools to encourage collaborative learning. Past uses have provided mixed results but I am looking forward to using the rewritten versions.

  b) plugins and/or complementary programs that are used - None, although several look appealing. In particular Gong/Nanogong (http://gong.ust.hk/features_nano.html) and Mahara (https://mahara.org//) interest me.

 

Thank you, Daniel

 
Average of ratings: -
Picture of Monica Bokos
Re: Successful implementations Moodle 2.2+
 

Hi,

Just a small note on nanogong, it seems to be a great tool exept if you record in a WYSIWYG. What happens is that the recording is stored in course nr 1, and you can't delete it directly from Moodle even if you delete the resource. So imagine having 100 recordings and having to identify them on your server...

 
Average of ratings: -
Picture of Daniel Brouse
Re: Successful implementations Moodle 2.2+
 

Monica,

Thank you for the note regarding nanogong. I did not know that. Is there a work around to prevent the problem with storing the file?

Thanks,

Daniel

 
Average of ratings: -
Picture of Visvanath Ratnaweera
Re: Successful implementations Moodle 2.2+
Group Particularly helpful Moodlers
Moved from the "Hardware and Performance" forum to "Comparison and Advocacy".
 
Average of ratings:Useful (1)
Picture of Daniel Brouse
Re: Successful implementations Moodle 2.2+
 

Thank you Visvanath. I'm still not sure why this discussion would be more appropriate for Comparison and Advocacy but I know that you are a significant contributor to Moodle.org so I'll trust your judgement. Thanks again.

 
Average of ratings: -
Picture of Visvanath Ratnaweera
Re: Successful implementations Moodle 2.2+
Group Particularly helpful Moodlers
Hi Daniel

Only now I read your post, I'm not subscribed to "Comparisons and advocacy".

My reason for shifting was that your original post has no reference to high performance. If you are convinced that "Hardware and performance" or any other forum is the right place, pl. go ahead. You need to send a message to Helen Foster, I don't have the rights.
 
Average of ratings: -
Picture of Andrew Nicols
Re: Successful implementations Moodle 2.2+
Group DevelopersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers
This is the details for a site I'm currently working on. The site is currently in pilot and will go live to all users in September/October this year (2012).

1) The size of your Moodle installation:
a) Active courses: 175
b) Average course size: 45
c) estimated maximum number of concurent users: 1,500

2) Your server solution
a) Example options: Self managed server, Managed Dedicated Server, VPS, Shared hosting, etc: Self-managed infrastructure
b) If you managed the physical server, what hardware and environment stack do you use?

Virtualised using VMWare on Dell blades with SAN as underlying storage
db server: Debian Stable (Squeeze at time of writing), Postgres 9.0, pgpool2, 4 cores, 2GB RAM
frontends: Debian Stable, Apache 2.2, APC, 4 cores, 8GB RAM
cron server: Debian Stable, 2 cores, 1GB RAM

We plan to:
* add additional frontends (possibly with lower RAM each)
* increase memory to the DB server
* add a software load balancer + ssl terminator using haproxy + apache 2.2

c) If you have a managed solution - who manages it? What is your monthly/yearly hosting cost?
We manage this solution on a customer's infrastructure

3) Features/activities of Moodle that are significantly used.
a) core features/activities that are utilized by your site
Files, Pages, Lessons, URLs

b) plugins and/or complementary programs that are used.
Custom written authentication plugin (cosign + LDAP)
Custom repository plugin to interrogate a flash media server
Email notification of calendar events, recent activity on courses, etc.
RightAnswers integration to allow searching of institution-specific help content
Talis Aspire
Integration with institution-specific student data systems to automatically create courses, create users, assign users, archive courses, etc.


We also integrate with Mahara and intend to do some additional development work on Mahara including adding the Email to Journal functionality that I proposed at MaharaUK 2011.


Andrew
 
Average of ratings: -
Picture of Daniel Brouse
Re: Successful implementations Moodle 2.2+
 

Andrew,

Thanks for the information. It looks like you are developing an elegant solution.

Daniel

P.S. I was an exchange student to Lancaster University and lived in Fylde College in 1992-3

 
Average of ratings: -
Picture of pablo saldivia
Re: Successful implementations Moodle 2.2+
 

MISTER Andrew Nicols, i see you configuration for moodle HA , i have a question . My implementation is

Barracuda load balancer

9 apache web server

1 pgpool2

2 BBDD postgresql 9.0, tue system work fine. When install moodle 1.9 work great but with moodle 2.4 not connect with the database configuration like this <ip_bbdd:9999> ok no problem change port in pgsql_native_moodle_database.php to 9999 not work, install over ddbb server 1 and after backup and restore in server2, in config.php change this

$CFG->dboptions = array(
    'dbport'    => '9999',
); but show the same error

but appears error when create a new course like Error writing to database , error/moodle/dmlwriteexception.

list the data inserted in database and the data is the same only is diferent the id for example 6 for server1 and 7 for server 2 (the data is different)

Any help please

 

 

 

 

 
Average of ratings: -
Picture of Ryan Foster
Re: Successful implementations Moodle 2.2+
 

The part of your post that particularly interests me is the "Custom written authentication plugin (cosign + LDAP)".  Could you elaborate on that?

Thanks!

 
Average of ratings: -
Picture of Andrew Nicols
Re: Successful implementations Moodle 2.2+
Group DevelopersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Yup, sure.

Our institution uses Cosign for all web-based authentication - see http://weblogin.org but it's essentially a centralised authentication service. I believe our rationale for using it is that we don't want people getting used to typing their password into any old login screen assuming that it's safe. We provide a single login page, etc. It's a bit like Shibboleth I guess.

However, Cosign only provides authentication. It doesn't provide any of the directory data, or authorisation. It just provides a "Yes, this person has authenticated. They validated with this username against that domain".

So to find out the user's other details - name, email, department, phone, etc., we do an LDAP query for them.

To do all of this, we've written a custom auth plugin which handles the cosign side, and the LDAP side. It also does a CLI sync to pull all users from our (horrendously complicated) tree and pre-create them in Moodle.

Our LDAP backend also supports multiple identities for the same person, so we've recently modified our plugin to handle this. If a user logs in with *any* of their usernames, it will canonicalise it to their existing username and log them in with that.

Any specific questions on our plugin?

Andrew

 
Average of ratings: -
Picture of Ryan Foster
Re: Successful implementations Moodle 2.2+
 

Our institution also uses Cosign for all web-based authentication, and my department is looking to leverage that with a Moodle installation that I maintain. To my knowledge, on other sites at our university, once a user is authenticated, we also perform LDAP queries to get information on the user.

It sounds like your auth plugin pretty much does what we need it to do, hence my interest.  Does it still work with newer 2.x versions of Moodle?  Any chance I could convince you to provide me with a copy?

The multiple identities thing sounds interesting.  Could you explain in more detail?

 
Average of ratings: -
Picture of Andrew Nicols
Re: Successful implementations Moodle 2.2+
Group DevelopersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Hi Ryan,

I'm not sure whether I'd be able to share our code on this one - I'd have to check with my superiors but I'll let you know.

In order to get it to work, we use the existing Apache2 cosign filter, and protect a single directory within our installation. In our case, we've opted to:

  • protect /login
  • unprotect but use SetHandler cosign on /cosign/valid

For the most part, the basic plugin is just standard plugin boilerplate. We define a list of userfields (things like firstname, lastname, email, department, etc), a constructor to grab config and set the authtype value, and a few other bits.

We've defined a function 'get_cosign_username' which retrieves the username from the $_SERVER variable and passes it through strtolower. This checks that that AUTH_TYPE is 'Cosign' and that a remote user value is set before return that REMOTE_USER. We also have a function to check whether the account is a friend account (we allow these but they exist in a different LDAP tree to our core users).

The interesting bits come when we look at the loginpage_hook() and user_login() functions.

In loginpage_hook(), we check that we have a valid username, and then add that username to the existing global $frm. $frm is used on the login page for the username and password (and a few other bits). As I recall, loginpage_hook() is called as a user is being logged in. By setting the username based on get_cosign_username(), and a fixed password (we obviously don't have access to the real passwords but have to provide something so we make something up), this means that when the Moodle login functions are processed, we have a username and password already filled in. If they correspond to a user in Moodle, then login should be successful.

Again, the user_login() function is interesting. It's called as part of the login process and must return true for a valid user. We confirm again that we were supplied with a username by cosign (get_cosign_username() again). We then check whether the user has been created in Moodle yet - if not, we create the user and redirect them back to the /login page where they get automatically logged in. Otherwise, we return truthfully.

We also have a logoutpage_hook() to ensure that when a user logs out, we log them out of Cosign, and redirect them to the cosign logout page (set via a config option on our plugin).

The only remaining bit really is pretty much copied from the ldap plugin - without looking into that part of the plugin, I couldn't tell you exactly how it works. Will try and do so when I get a chance. We call the ldap functions from the user_login function, but I forget the details of how we do so. We've also substantially rewritten how we do this recently to cater for our specific requirements.

This is a 2.X plugin only - we're running 2.5 having started with Moodle 2.2 on our Moodle pilot 2 years ago.

The multiple identities thing is an interesting one and came about as a result of some other changes we made recently.

To start with, we sometimes have a requirement to allow cosign friends into Moodle so, as I mentioned before, we have a function to check whether a user is a cosign friend, and if so we access a different LDAP tree for user profile retrieval.

We also have a separate tree for our applicants, and for short-term user accounts which are provided to one or two day courses that some departments run. Again, we have corresponding functions in our plugin which detect these based on the cosign realm (again, provided in $_SERVER).

All in all, this means that we just query different parts of the tree based on the type of Cosign user.

The magic bit came about because some of these users (e.g. Applicants) migrate from being in one tree to another (our standard user accounts). We needed to be able to detect this, and update their user profile accordingly. Thankfully, our identity system (I wouldn't go so far as to call it an IDM and it's entirely custom-written and hooks into all sorts of areas of other software) ties all of these accounts together inside a single user record. It has the facility to present these to LDAP with all relevant details as the relevant user accounts in the relevant trees. Thusly, a single person may have as many accounts as they like. Helpfully, it adds a custom LDAP attribute to help us to tie them all together. The ownerCID field will be the same for each of these users. We store that CID field against a Moodle user id in a separate table (auth_cosign_cid_mapping). That means that when a user logs in, we retrieve their ownerCID, look for it in that table, retrieve the user account details associated with that particular mapping, and in the loginpage_hook(), we set the username to the username against this record. We do this with a function called get_canonical_user() (or something like that - this is from memory). Wherever we get a username from cosign, we now call get_canonical_user() and use the username field that it returns instead of the account that the user was authenticated against. This means that whichever account they authenticate against, as long as the CID matches, they can log in with.

This does have some limitations - you cannot merge accounts so you need to make sure that they're all valid; and it has the effect of preventing login if the username and CID do not match for a username in use in Moodle. We actually see this as a feature funnily enough - we re-use our usernames a year after a user has been removed (which is 9 months after they leave the institution). As a result, we need to make sure that we soft delete old users so that their usernames can be reused without risk of data breach. This provides us with an additional backstop to make sure we don't hit that kind of issue.

The CID matching also means that we run a CLI sync script (similar in nature to the LDAP script found in auth/ldap/cli). This fills Moodle with all of the users in our main LDAP tree, as well as all of those in one of our other trees but not those cosign friend accounts. This isn't strictly necessary, but it does mean that all valid user accounts are available to be used by staff when they want to enrol a user. This is also where we handle account deletion (soft delete), account restoration (if a user comes back several years later and is given a user account, all of their previous data is restored to them), account renames (usernames can change), account migrations (a user changes tree for some reason), and the like.

We only do a soft delete because the idea of removing data scares the bejesus out of me. A full user_delete() also removes a lot of other data. IIRC it removes things like grades and enrolments. Quite frankly, I'd really rather this didn't happen from a cron job. So we set the user deleted field, rename the user as user_delete() would, and can the e-mail address in the same way too. The user account is 'deleted', but the data associated with it is not.

So yeah, in a nut-shell, that's what we do. I'll see whether I'm allowed to release our plugin. It may be that we can release an older version without the user identity tomfoolery. As I say, some of the changes we've made have made it very specific to our setup.

Andrew

 
Average of ratings: -
Picture of Ryan Foster
Re: Successful implementations Moodle 2.2+
 

By setting the username based on get_cosign_username(), and a fixed password (we obviously don't have access to the real passwords but have to provide something so we make something up), this means that when the Moodle login functions are processed, we have a username and password already filled in. If they correspond to a user in Moodle, then login should be successful.

I've got some questions about this.

  1. What is the reason for having to provide Moodle with a fake password?  Does it require one even with external authentication handlers?  This fake password wouldn't actually allow a user to login, would it?
  2. Do corresponding Moodle user accounts have to be manually created to match Cosign accounts, or do you have a process for this (user-based or automated)?

Your multiple identity setup sounds pretty similar to what we use.  We allow users to registers for a Cosign Friends account (such as for prospective students before they get issued a full Cosign account).  When the student graduates, they can apply for a Cosign Friends account with the same username as their full Cosign account.  I'm not sure if our identity system views these as separate accounts tied to the same university ID (though, I don't think that owners of Cosign Friends accounts actually receive university IDs), if it deactivates one as the other is activated, or if there is it does something else.  The Cosign/LDAP realms are separate for full Cosign accounts versus Cosign Friends accounts.  I do also believe that there are some situations where students using our Moodle installation may only end up with a Cosign Friends account, but I'm not 100% sure on that.

As far as I know, we never delete user records.  User accounts are deactivated and archived forever at our university.  If a person who previously held an account returns to the university, their old account is reactivated.  Thus, we never reuse usernames for accounts.

I'm very interested in seeing how well this plugin would apply to our system.  If it fits in well, it may save me the trouble of having to write my own and adding another Cosign auth plugin to the pool.

 
Average of ratings: -
Picture of Andrew Nicols
Re: Successful implementations Moodle 2.2+
Group DevelopersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Hi Ryan,

Disclaimer: I didn't write the original implementation of this, Dan Poltawski did.

1: Moodle needs users to have a password. We just provide a string as a fake password. Since the user's auth plugin is set to cosign, they can't use it for normal login. AIUI, even external auth handlers require something. There was a proposal a while ago to change this so that the password belongs to the authentication plugin rather than the user, but I don't think any progress was made on that.

2: User accounts must exist in Moodle for a user to log in. Even those relating to external authentication. We made the cosign plugin create users on login (there's a flag IIRC).

I'm still trying to find out about releasing the plugin smile

Andrew

 
Average of ratings: -
Picture of Ryan Foster
Re: Successful implementations Moodle 2.2+
 

Doesn't Moodle use an auth order preference that allows authentication fallbacks?  Wouldn't that allow a user to somehow use their specified account password?  Or have I misunderstood that feature?  Admittedly, I'm not really sure how that feature works.

 
Average of ratings: -