Forums | Mahara Community

Support /
Big Problem - Please help!

Mike Korn's profile picture
Posts: 51

02 September 2010, 10:49 PM

Hello All,

I am running the latest version of Mahara on an Ubuntu server using MySQL. I am facing a catastrophe with my Mahara site. My organization recently had to change IP addresses and domain names and it has turned into a big mess. My users are connecting to Mahara through Moodle and all was working well until the name change. We lost our old IP so we had to create a new connection from Moodle to Mahara. I though all was working well so I deleted the old connection from Moodle and replaced it with the new one.

But I messed up. All the old user data is there, but when someone logs in from Moodle they are treated as a new user. For example - When I log in, my Mahara ID is michaelk1 instead of michaelk.

All my old data is there, but I cannot access it unless I log in as admin.

My questions are - is there a way to solve this problem? Can I merge the 2 instances for each user? Can I import the data form the old instance into the new for each of my users?

Please help and thank you in advance.


anonymous profile picture
Deleted user
Posts: 214

03 September 2010, 7:26 AM

Hi Mike,

It sounds like, when you updated your domain name, you created a new authentication instance, or a new institution rather than modifying the existing authentication instance - perhaps you have 'Auto-register all hosts' turned on in the Networking page?

There are actually a few of ways you could go about  fixing this. I'd really suggest closing your Mahara site and taking a backup before you do anything else to prevent creation of further duplicate users and provide you with a reversion path should things go awry.

The suggestions I make below assume you've got an additional auth instance. If you have an additional institution, then you'll need to remove/modify it's auth instance and correct the old institution's auth instance.

There are a few points to note here:

  • you can't have two users using the same auth instance with the same username; and
  • you can't remove an auth instance which has users associated with it;
  • you can't remove an institution with users associated to it.
All of the ways I suggest below will leave the new users hanging around and so you may want to do some housekeeping once you've sorted things out.

Correct the old auth instance

This leaves two options:

  • You can remove the new auth instance from Mahara, and adjust the old auth instance. This will require disassociating all users of the new auth instance from it.
  • You could adjust the new auth instance, and then adjust the old auth instance to have the correct details. This won't require disassociating users first. This is the option I'd probably go for I think... Once you've done some housekeeping and removed the new users, you can then remove this auth instance. This option is more immediate to getting things moving again.
Both of these options would be handled with the Manage Institutions, and selecting to Edit that institution.

Change all users to use the old auth instance

As an administrator, Site Administration -> Manage Users -> find michaelk and changing the authentication instance to the correct instance.

However - if a user has logged in to Mahara with the new authentication instance, and therefore received a second Mahara account with the same SSO username, then you will need to remove that authentication instance from that user. That's to say that each authentication instance must have a unique SSO username.


Let us know how you get on and remember take a backup.

Mike Korn's profile picture
Posts: 51

05 September 2010, 8:53 PM

Thank you for your detailed adavice Andrew,

The problem here is that I mistakenly deleted the old instance. Any way around that?

Thanks again,


anonymous profile picture
Deleted user
Posts: 808

05 September 2010, 10:51 PM

Mike, you probably didn't delete the old instance unless you did it at the database level.

But in any case you should get into the database and have a look at the 'auth_remote_user' table, and the 'authinstance' column of the 'usr' table. 

auth_remote_user should list all the moodle usernames and tell you which mahara user record corresponds to each one.

Hopefully in auth_remote_user you'll find stuff like this:

authinstance  remoteusername  localusr
5 michaelk 456
6 michaelk 789

Meaning the michaelk user from the Moodle with authinstance 5 logs in as the Mahara user with id 456 (michaelk), and the michaelk user from the Moodle with authinstance 6 logs in as the Mahara user with id 789 (michaelk1).

Once you find the ids of the old and new authinstances you should be able to look in the 'auth_instance' table, and that will tell you which institution and authinstance type goes with each of those ids, and you should be able to go into the admin section as Andrew suggested, find the old users and change their authinstance over to the new one.

Mike Korn's profile picture
Posts: 51

05 September 2010, 11:10 PM

Thanks Richard,

I tried to follow your advice. Yes, The records are still in the database as you said, but when I switch the authentication method, this is what I get:

Mahara: Site unavailable

A nonrecoverable error occured. This probably means you have encountered a bug in the system

Any further advice?

thanks again


anonymous profile picture
Deleted user
Posts: 808

06 September 2010, 1:03 AM

Firstly, the site unavailable message indicates a bug that we should fix (there should be more information in your apache log that will help to work out what happened).

You'll need to make sure that the users are in the correct institution first, and as Andrew said, also keep in mind that you can't have two users with the same username and the same authinstance.  So I'd guess this won't work for the users who have already duplicated themselves.   Try it first (assuming you have a backup) with old users who haven't logged in again since the Moodle switchover.

Mike Korn's profile picture
Posts: 51

08 September 2010, 2:46 AM

Yes! thank you so much for your help. Sorry for the delay in my confirmation. Our organization had to through the nightmare of changing our domain, sub-domains and all IP addresses.


All good now.



7 results