14 December 2016, 13:31

We setup a Mahoodle system with Mahara as master and Moodle as slave, connected via MNet. Normally, users login to Mahara and go to Moodle from there.

Recently, we moved Mahara to a new server and tried to connect it with the given Moodle installation again, but that did not work for any reason until now and we need time to find out how to solve the problem.

Because there is an urgent need for students to use the Moodle system in the meantime until we fix the connection problem (exam works!), we had the idea that users can directly login to Moodle with their Mahara accounts, i.e. without going via Mahara. This actually works, but my question is, if this may result in some trouble later when we manage to solve the described problem and re-establish the former Mahoodle connection. Could there arise some database inconsistencies, account duplication, loss of content etc.?

Thank you for your help!

Regards. Juergen

14 December 2016, 19:45

Hi Juergen,

How were your users created in Mahara? Was this an LDAP sync, manually, csv upload, etc?

Some of the issues that may arise (off the top of my head):

• The users may get out of sync - if they update their user details in Moodle, it will not be reflected in Mahara. Once the sites are integrated again, most likely Mahara will overwrite the user details.
• If an administrator deletes a user in Moodle - not sure what will happen once integration is happening again.
• ??? something else ??? - not really sure.

Make sure you don't do any processing on your users in Mahara - i.e. stop LDAP sync, don't suspend users, etc.

 

As for your Moodle / Mahara integration, you may need to reset your Mahara public key (in Administration > Configure Site > Networking). Then, I find it easy to just copy that public key and paste it into Moodle (Site admininstration > Networking > Peers > Mahara site - then past into the Public key field).

 

Not sure if this helps... Let me know if you need anything else.

Thanks,

Ghada

 

 

15 December 2016, 1:50

Hi Ghada,

Thanks for your rapid answer. It helps us a lot.

Users were created by csv upload.
Considering user data sync: We can give users advice not to change their data until integration is working again.
We also can make sure that admins do not change, suspend or delete any users.

Thanks also for the advice to solve our integration issue. We will try to reset the Mahara public key and copy/paste it into Moodle. I'll report back if it works.

Thanks again
Juergen

17 December 2016, 12:03

Hi Ghada,

Resetting the Mahara public key and copy/paste it into Moodle did not work in our case. The reason might be that our Moodle version was quite old (2.6) whereas the Mahara version was 15.04. And besides we moved both to a new server and this had updated OS, PHP, web server etc.

Therefore, we setup a new version of Moodle, loaded the existing Moodle database, and connected it to the given Mahara system. That worked and everything is fine.

Lessons learnt: Upgrade systems more often. :-)

Thanks again for your support
Best regards
Juergen

19 December 2016, 11:25

Hello Juergen,

MNet wasn't changed much (except on the Moodle side with some deprecations as far as I know) over the years and thus connecting a 2.6 to a Mahara 15.04 should still work. If you have any error messages to share that would help to find out what was going on.

What I'm interested in is to know how your users logged into Moodle rather than Mahara when they had MNet set up from Mahara to Moodle. Did you change anything on the SSO direction in Mahara and Moodle?

Cheers

Kristina

 

20 December 2016, 10:03

Hello,

as I'm involved in the administration of said setup, I'd like to answer.

In fact the SSO connection between Moodle 2.6 and Mahara 15.04 worked flawlessly until we moved Mahara from an old server (Debian 7) to a new server (Ubuntu 16.04). I suspect that some of the major differences between the software used on those systems somehow broke the networking connection (perhaps OpenSSL, but I'm just guessing).

In Mahara, any attempt to log in to Moodle would fail with an error saying that the MNet connection failed (I haven't got the exact messages at hand right now). In the Moodle networking settings this error was shown: "The public key you are holding for this host is different from the public key it is currently publishing. The currently published key is: ..." So I assume that due to some misconfiguration the keys were not generated or exchanged correctly.

Cheers
Jan

20 December 2016, 11:19

Hi Jan,

Just something to watch out for...

Ubuntu 16.04 comes with PHP7 by default. Moodle 2.6 is not compatible with this version of PHP. You may find parts of it failing - please check your log files. I'd highly recommend upgrading to the latest Moodle 3.2 - which is compatible (or 3.1 - also compatible).

You may also have issues with Mahara 15.04 with that version of PHP. The latest version of Mahara (16.10) is supposed to be compatible but there are a still a few minor issues that we are finding - and fixing.

I'm not saying that the SSO issues were caused by this. But, you will find other parts of Moodle and Mahara failing.

 

Cheers,

Ghada

 

24 December 2016, 4:32

Hi Ghada,

thank you for the heads up. We have upgraded Moodle to version 3.2. Mahara 15.04 currently works for us with PHP7, but we will upgrade it soon, too.

Cheers
Jan

20 December 2016, 11:51

Hello Jan,

Can you please post the specific error messages that you received?

In addition to the info that Ghada already provided:

The first Mahara instance that was tested with PHP7 is Mahara 16.10. Older versions would be spottier in its support.

One simple thing to try when getting a key mismatch between Moodle and Mahara is to regenerate the keys on both ends. You will need to add the new Moodle key into the MNet auth instance on Mahara as it's not being picked up automatically directly. Also ensure that the wwwroot is correct. On Moodle, also enter the new Mahara key and save the page. If you get an error message along the lines of:

‘The key is not a valid SSL key. (4: The subject of the certificate:
[url]
does not match the host it came from:
[url].
)’

take a very close look at the URLs. Are they truly identical and correct or is one missing characters at the beginning / end? If you have a very long URL for Mahara, it may be truncated as only 64chars are allowed. That's been fixed in Moodle for later versions. See https://tracker.moodle.org/browse/MDL-52766 for the full bug report.

We have a patch in review to fix this issue in Mahara: See https://reviews.mahara.org/#/c/7333 You can backport it if it affects you.

Cheers

Kristina

 

24 December 2016, 4:54

Hi Kristina,

thank you. I did regenerate both keys, but it did not help. Also the URLs were absolutely correct.

We received the following errors on the Moodle screen while trying to log in via SSO:

"Ooops! Your MNET communication has failed! Here's that error message to pass on to your administrator: remote server error: code: , message: A nonrecoverable error occurred. This probably means you have encountered a bug in the system"

"Ooops! Your MNET communication has failed! Here's that error message to pass on to your administrator: XML Parse error in payload: SYSTEM or PUBLIC, the URI is missing At line number: 1 Which reads:"

The Mahara error log contains these (I can't tell if they are directly related to the aforementioned errors, but they must have occurred approximately at the same time):

[Mon Dec 12 22:17:32 2016] [error] [client 127.0.0.1] [INF] 22 (api/xmlrpc/lib.php:1085) Signature verification for message from http://xxx.xxx.xxx.xx/epos-moodle failed, checking to see if they have a new signature for us
[Mon Dec 12 22:17:38 2016] [error] [client 127.0.0.1] [INF] 22 (api/xmlrpc/client.php:128) Remote application has sent us a new public key
[Mon Dec 12 22:17:39 2016] [error] [client 127.0.0.1] [INF] 22 (api/xmlrpc/client.php:142) New key has been imported. Valid until 2017/01/09 10:16:47
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1] [WAR] 22 (api/xmlrpc/client.php:157) Undefined index: faultCode
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1] Call stack (most recent first):
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * log_message(string(size 26), integer, true, true, string(size 52), integer) at /var/www/docroot/epos-2/htdocs/lib/errors.php:515
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * error(integer, string(size 26), string(size 52), integer, array(size 21)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/client.php:157
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * Client->send(string(size 33)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/lib.php:1089
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * xmldsig_envelope_strip(object(SimpleXMLElement)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/server.php:97
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1] [WAR] 22 (api/xmlrpc/client.php:157) Undefined index: faultString
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1] Call stack (most recent first):
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * log_message(string(size 28), integer, true, true, string(size 52), integer) at /var/www/docroot/epos-2/htdocs/lib/errors.php:515
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * error(integer, string(size 28), string(size 52), integer, array(size 21)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/client.php:157
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * Client->send(string(size 33)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/lib.php:1089
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * xmldsig_envelope_strip(object(SimpleXMLElement)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/server.php:97
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1] [WAR] 22 (api/xmlrpc/client.php:157) Unknown error occurred: :
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1] Call stack (most recent first):
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * Client->send(string(size 33)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/lib.php:1089
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]   * xmldsig_envelope_strip(object(SimpleXMLElement)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/server.php:97
[Mon Dec 12 22:17:41 2016] [error] [client 127.0.0.1]
[Mon Dec 12 22:17:50 2016] [error] [client 127.0.0.1] [WAR] 4e (api/xmlrpc/lib.php:183) No such session exists
[Mon Dec 12 22:17:50 2016] [error] [client 127.0.0.1] Call stack (most recent first):
[Mon Dec 12 22:17:50 2016] [error] [client 127.0.0.1]   * user_authorise(string(size 40), string(size 40)) at Unknown:0
[Mon Dec 12 22:17:50 2016] [error] [client 127.0.0.1]   * call_user_func_array(string(size 14), array(size 2)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/lib.php:111
[Mon Dec 12 22:17:50 2016] [error] [client 127.0.0.1]   * api_dummy_method(string(size 33), array(size 2), string(size 14)) at Unknown:0
[Mon Dec 12 22:17:50 2016] [error] [client 127.0.0.1]   * xmlrpc_server_call_method(resource(#73), string(size 346), string(size 14), array(size 1)) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/dispatcher.php:178
[Mon Dec 12 22:17:50 2016] [error] [client 127.0.0.1]   * Dispatcher->__construct(string(size 346), true, true) at /var/www/docroot/epos-2/htdocs/api/xmlrpc/server.php:126
[Mon Dec 12 22:17:50 2016] [error] [client 127.0.0.1]

The last message is repeated multiple times (presumably upon each login attempt).
Unfortunately no server logs are available on the Moodle side because debugging was turned off.

Today I tried to reproduce the problem by setting up a Mahoodle link between the original Moodle running on the Debian 7 server and a fresh Mahara install on Ubuntu 16.04. There was no problem at all.

Cheers
Jan