moodle 1.9.12 gone rogue

moodle 1.9.12 gone rogue

by Jason Metz -
Number of replies: 5

I have been tasked with getting an old moodle system that is no longer working properly....to work properly. The current setup is an install of moodle 1.9.12+ with two courses each containing 3 quizzes. The admin user has no ability to administer roles, getting "Sorry, but you do not currently have permissions to do that (Assign roles to users)" and is not able to export course materials. Here is a screenshot of admin menu with editing turned on:

Admin user has no access to course admin and cannot update enrollment key. New user accounts can not be created, as the email to confirm their registration is never sent. The enrollment key for previous course offering does not work. In short, I have a database that is possibly corrupted, an insecure and outdated code base, and I am not a Moodle expert.

I have tried updating the code base to 1.9.19+ with a copy of the database, and though the upgrade completed without error, the admin user can no longer log in getting "invalid login" and if I try to reset password via forgot password get "Incorrect sesskey submitted, form not accepted!". I have tried to manually reset admin password using md5 generator and phpMyAdmin, but still "invalid login"....

Any suggestions on how to proceed? How difficult would it be to manually reconstruct the courses from the database into a moodle 2.6 clean install?

Average of ratings: -
In reply to Jason Metz

Re: moodle 1.9.12 gone rogue

by Ken Task -
Picture of Particularly helpful Moodlers

Could try this:

Gonna require some backend mysql trickery am afraid.
Have to use some tool where one can view/edit the DB - phpmyadmin/webmin's MySQL tool, or other (see you have said you have phpmyadmin)

First, do a query like:

select * from mdl_user where id like "2"

The 1st user created is the guest account.   The 2nd user created was the initial admin account - if they didn't change things.

The passwords are MD5 hashed and gen'd by Moodle with some 'formula', but if one knows another users password, one could copy the md5 password of the known login to the password field of the admin user.   Then login with admin credentials using the known password.

To get around the sessions issue, edit the config.php file of the Moodle and insert
the following line:

$CFG->dbsessions=0;

That turns off using the DB for sessions and tells noodle to use files instead.
A 'sessions' folder should be created in moodledata and contained therein session files per user that has logged on.

If the sessions folder is not automatically created, you might have to create one manually and make sure it's readable/writeable by the apache user/group.

Since you've attempted upgrading to 1.9.19+ one might be thrown into upgrading upon initial access.   Am assuming you set the ownerships/permissions on all Moodle files correctly when upgrading.

Manually re-construct courses ... well, guess you could ... but think I'd try regaining control first. 

Once in make no user backups of the courses.   Those will restore to a 2.6 although one will have legacy files for those.  1.9 users won't restore to a 2 via Moodle UI.

'spirit of sharing', Ken

Average of ratings: -
In reply to Ken Task

Re: moodle 1.9.12 gone rogue

by Jason Metz -

Thanks for your suggestions Ken!

I tried resetting the admin password (user 2) in the 1.9.19 upgraded version manually to a known good hash, the hash from the admin user in the rogue 1.9.12 version. I can log in with the exsiting password on the rogue 1.9.12 install, but with the truncated admin menu and limited access noted in my first post. After upgrading the code base to 1.9.19, pointing it at a copy of the database and completing the upgrade, I cannot log in with the same password. The password hash for user 2 in mdl_user table is the same as the one in the 1.9.12 database, but login attempts return "login invalid".

With $CFG->dbsessions=0; added to my config.php file, line 35 after $CFG = new stdClass(); forgot my password is still returning "Incorrect sesskey submitted, form not accepted". The sessions folder has been created under the uploaddata directory and I can see session files being logged there (though I have not been able to log in). So going to an upgrade of moodle to resolve existing issues does not seem to be working, it seems to be creating a login issue.

With the 1.9.12 version, I can log in as admin, but the issue is that all the course management permissions that should be available to user 2 are not. What I need is to be able to backup the 2 courses with their content (not users or their results) so that I can import into a working moodle 1.9.latest and then hopefully upgrade to 2.2 then 2,6 without issues.

Does anyone know of any documentation on reconstructing a course backup in 1.9 manually from the database? Or at least some guide as to how course data is structured in the database and where the course backup function lives in the core files for 1.9?

Average of ratings: -
In reply to Jason Metz

Re: moodle 1.9.12 gone rogue

by Ken Task -
Picture of Particularly helpful Moodlers

Line 35?!!!  That's kinda a long config.php file for a 1.9, me thinks.

In 1.9.x, previous admins could have changed user ID 2 such that that user ID is no longer admin or the role of the user could have been modified.

If you can login, how about trying going directly to some of those admin areas:

http://yoursite/admin/roles/assign.php?contextid=1&roleid=1

Ok, then ... how about this ... can you see a course ID?   Example below for course ID 11.

Maybe you can get to the backup form for the course by going directly ...

http://site/backup/backup.php?id=11

In mdl_user are there any users that have been disabled?

Other stuff to check:

In mdl_role_capabilities table moodle/site:config and moodle/site:doanything role ID is 1

Have you checked the data folder and course ID folders to see if there is a backup in backupdata?

From the data directory: ls ./?/backupdata/backup*.zip

They might be old, but it's something!

Documentation for reconstructing a 1.9 course manually ... don't think it exist.

But, one still might be able to recover documents/files that were uploaded by manually moving files out of those course ID folders.

An unzipped 1.9 backup looks somewhat (could look - depending upon what modules, etc. used) like this:

drwxrwxrwx 4 root root   4096 Jun 16  2008 course_files
drwxrwxrwx 2 root root   4096 Jun 16  2008 group_files
drwxrwxrwx 8 root root   4096 Jun 16  2008 moddata
-rw-rw-rw- 1 root root 121338 Jun 16  2008 moodle.xml
drwxrwxrwx 4 root root   4096 Jun 16  2008 user_files

The key file is moodle.xml - it maps everything to be contained in the backup.

Still there are other things I'd try ... might be corrupted tables in need of repair:

mysqlcheck -u root -p$password --analyze --databases $db

If there are some tables that report they are in need of repair ...

mysqlcheck -u root -p$password --repair $db $table

One could also force the fix of all by pretending to have just upgraded MySQL using --force:

https://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html

Running out of suggestions ... sorry.

'spirit of sharing', Ken

 

Average of ratings: -
In reply to Ken Task

Re: moodle 1.9.12 gone rogue

by Ken Task -
Picture of Particularly helpful Moodlers

Last thoughts ... shots ...

Did you clear local browser of any cache/cookies related to site/sites?

In mdl_sessions2 looks like session information is stored.  Could truncate that table ... ie, remove all records but leave the table.  On a 1.9 to which I have access and which is set to use files (not DB) that table contains no records.

In mdl_role_assignments

select * from `mdl_role_assignments` where `roleid` like "1"

roleid 1 is admin user
there is a userid column in that table.
One can also manually set 'confirmed' by setting 1 for the confirmed column.

Those userid values do match the id of mdl_user that are admin levels in a 1.9.19+ am looking at to research this.

Now ... I am out of suggestions/things to try. :\   Best of luck!

'spirit of sharing', Ken

Average of ratings: -
In reply to Ken Task

Re: moodle 1.9.12 gone rogue

by Jason Metz -

Thanks again Ken for all your suggestions, unfortunately I have not progressed any further by trying them:


http://site/admin/roles/assign.php?contextid=1&roleid=1
Sorry, but you do not currently have permissions to do that (Assign roles to users)

http://site/backup/backup.php?id=2
You need to be a teacher or admin user to use this page.

In mdl_role_capabilities table, moodle/site:config and moodle/site:doanything rows, roleid is 1.
In mdl_role_assignments userid 2 has roleid 1.

No backups for courses in files under uploaddata or anywhere else.

No mysql tables reported needing repair.

All dead ends...

Looking at mdl_role_allow_assign table there are no rows for roleid 2 with allowassign 1 or 2, is this right? Not entirely sure if allowassign is referring to role 1 and 2, but notice that roleid 1, which should be guest, but for which there is no row in mdl_user table (ie. first row is userid 2), has allowassign 1 and 2 tuples.



If I can't get permissions sorted out to allow course backup I will be manually rebuilding course quizzes from question entries in database...ugh. brutal.

Average of ratings: -