Moodle

This problem is starting to widespread: we currently have three Moodle sites out of service due to this issue

Andrea, were these sites that used to work? Did they break in an upgrade?

Donal, any suggestions?

Need more info about this. Donal, can it be closed?

MD: I believe so but I'd like more feedback from Andrea.

I have two moodle checkouts, on the same server (distinct folders, data directories and databases). Both sites have the same configuration (both are enabled for publish and subscribe).

On one site, in admin->networking->enrolments, under column courses I see "5 - enrol". Clickin on 'enrol' I get a list of courses available on the other site. Doing the same thing on the other site gives me the error "RPC enrol/mnet/available_courses:ERROR 1:Payload not encrypted".

On the same first site, I have the "courses" block shown on front page. Clicking on a course available on the second site, I get the error "RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:1:Payload not encrypted" from the second site (so I am "changing site").

I tried the same thing with a fresh checkout, and both sites are working as expected. I don't know what to think: either some cruft was left over in the database or this is a mandelbug of some sort...

I can reproduce this error almost on demand (but not quite)...

I traced this down to /mnet/xmlrpc/xmlparser.php, line 89, where $data is empty, somehow, sometimes. If data is empty, $this->cipher is obviously empty too, thus breaking the rest of the code. I don't know what's causing $data to be empty there, but there appears to be something saved about it in the database that makes it permanent: if you wipe your tables, then it will work again (data will be received again). Though I don't suggest wiping your tables, as it will break the rest of mnet... (for one thing, you won't be able to replace the public key for your host).

My (wild) guess is there's a sequence that stuff should be done in ... like if the peer is in "community hub" mode when you first add it, it will work.. but if it's not otherwise prepared to accept this new peer, it won't work. (This sequence is what some documentation recommends, iirc, but if it's this critical, it should really be enforced by the system!)

This bug is made worse by the fact that it's impossible to really delete a peer.. so you can't really start over (actually, it's more like "nearly impossible" - I'm being told there might be a timeout happening at some point here, after which hosts do disappear for real)

We solved the problem in upgrading php.
regards Peter

php update solved the problem