Loading...
 
Architecture / Installation

Architecture / Installation


Migration of trac users to tiki

posts: 11 Germany

Hello,
I have to migrate a Project on Trac to Tiki. I have managed to migrate the wiki-pages and the files are also stored in a file gallery. So far so good.
The problem I have now is that I have to migrate the registered Useraccounts to tiki. On the old trac instance, the passwords were stored as an MD5 hash (htdigest), but as far as I know tiki only supports blowfish since release 9.
So my question is: How can I store the old MD5 hashes in the user_user table? Does anyone have an idea?

PS: I want the users to change their passwords afterwards, since MD5 is not the state of the art anymore. But there is no possibility to contact them all first.

posts: 11 Germany
I already tried to store it in the table users_users, once with no prefix, so the plain hash, and once with the php specific prefix $1$. Both did not work, only the unsuccessful_login var raises ;)
posts: 11 Germany

OK, since noone can help me, I am considering to move away from tiki since this is the real dealbreaker for me: Making it possible to use the old accounts from trac. Maybe with an option to send a new password or anything else, so that it will be stored in the database of tiki properly.

Maybe someone will find this usefull to migrate, these are (partly) the steps I did to migrate. I used a dump of the database of trac for this, than created the tables users_users, users_usergroups and tiki_user_preferences, than exported them as a .csv and imported them into the tiki database:

INSERT INTO users_users ('login', 'lastLogin')
SELECT sid AS login, last_visit AS lastLogin
FROM session;

UPDATE users_users
SET email=( SELECT value
FROM session_attribute
WHERE name='email' AND
session_attribute.sid=users_users.login);



DROP TABLE IF EXISTS temp.a;
CREATE TABLE temp.a (
"user" TEXT,
"prefName" TEXT,
"value" TEXT
);
INSERT INTO temp.a (user)
SELECT login FROM users_users;
UPDATE temp.a
SET prefName='realName';
UPDATE temp.a
SET value=(SELECT value
FROM session_attribute
WHERE name='name' AND
temp.a.user=session_attribute.sid);

INSERT INTO temp.a (user)
SELECT login FROM users_users;
UPDATE temp.a
SET prefName='user_information',
value='private'
WHERE prefName is NULL;

INSERT INTO temp.a (user)
SELECT login FROM users_users;
UPDATE temp.a
SET prefName='email is public',
value='n'
WHERE prefName is NULL;

INSERT INTO temp.a (user)
SELECT login FROM users_users;
UPDATE temp.a
SET prefName='mailCharset',
value='utf8'
WHERE prefName is NULL;

INSERT INTO temp.a (user)
SELECT login FROM users_users;
UPDATE temp.a
SET prefName='allowMsgs',
value='n'
WHERE prefName is NULL;

INSERT INTO temp.a (user)
SELECT login FROM users_users;
UPDATE temp.a
SET prefName='display_12hr_clock',
value='n'
WHERE prefName is NULL;

INSERT INTO temp.a (user)
SELECT login FROM users_users;
UPDATE temp.a
SET prefName='show_mouseover_user_info',
value='n'
WHERE prefName is NULL;

INSERT INTO tiki_user_preferences (user,prefName,value)
SELECT user,prefName,value
FROM temp.a
ORDER BY user ASC;

DROP TABLE temp.a;

+++++++++++++++++++++++++++++++++++++++++++++++++

Die Gruppenzugehörigkeit wird bei tikiwiki in der Tabelle users_usergroups gespeichert, bei Trac in der Tabelle permission:

+++++++++++++++++++++++++++++++++++++++++++++++++

INSERT INTO users_usergroups (userId,groupName)
SELECT username AS userId, action AS groupName
FROM permission;

UPDATE users_usergroups
SET userId = (SELECT userId
FROM users_users
WHERE users_usergroups.userId=users_users.login);

In der Tabelle permission ist noch authenticated, admin und anonymous aufgeführt. Diese Einträge müssen gelöscht werden.

DELETE FROM users_usergroups
WHERE userId is NULL OR userId='1';


posts: 11 Germany
Markus Beckschulte wrote:

Hello,
So my question is: How can I store the old MD5 hashes in the user_user table? Does anyone have an idea?

Ok, in tiki, the function validate_user_tiki performs the password check. If you take a look at this function, you will see that there are mechanism for supporting old hashes of deprecated versions of tiki, namely md5 - so nearly what I need.
To also support the old htdigest md5's, I added the following:
$realmtrac = ':oldRealm:';
if (! empty($pass) && $res'hash' === md5($user.$realmtrac.$pass)) {
$this->set_user_password($res'userId', $pass);
return USER_VALID, $user;
}
With this you can store the plain hashes, without any prefix, in the table users_users in the collumn hash.
Hopefully this will help someone, I am really a bit disappointed of the community of tiki that they couldn't even give me a little hint to this specific function. I can not immagine that no one did not know about it.

Edit: the function can be found in the userslib.php, line 1875


posts: 11 Germany

But if at least someone would show some interest in this task, maybe I could write a small tool for others.
There should be a large group of trac users who are looking for an alternative because the latest stable version is using python 2, that is deprecated. And the coming release will need svn 1.14, but not many distros have this in there repositories.


posts: 11 Germany
Thanks a lot!! Seams like this forum wasn't the right way to get this specific type of information :-)

posts: 126885 United Kingdom

Sorry, i don't know what trac is, and i'm afraid i don't have time to investigate properly....

Markus Beckschulte wrote:
PS: I want the users to change their passwords afterwards, since MD5 is not the state of the art anymore. But there is no possibility to contact them all first.


Can't you just set all the users to need to change their passwords when they next log in? Hmm, looks like you can only really do that if you reset their password at the same time... and so would need to share that new password with them... this happens in \UsersLib::change_user_password

Can you not just get them to reset their passwords (via a link to their email)? I guess not rolleyes

The only other thing i can think of is you add some code (locally) in \UsersLib::validate_user_tiki when their password fails, to check if their password matches using MD5, and then trigger the "must change password" code if so...

Tricky one! HTH

posts: 11 Germany
Jonny Bradley wrote:
Sorry, i don't know what trac is, and i'm afraid i don't have time to investigate properly....

From the website of trac.edgewall.org:
"Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management"
It was mainly used to share scientific data in my case, so no programming at all..

Jonny Bradley wrote:
The only other thing i can think of is you add some code (locally) in \UsersLib::validate_user_tiki when their password fails, to check if their password matches using MD5, and then trigger the "must change password" code if so...

As you can see in my previous post, this is what I did in the end. But I didn't force them to change their password, I only re-hashed the old password (set_user_password)..

posts: 11 Germany
Jonny Bradley wrote:
and then trigger the "must change password" code if so...


would it be possible to tell me how to trigger this? I am pretty new to tiki and couldn't find anything..

posts: 11 Germany
Markus Beckschulte wrote:
would it be possible to tell me how to trigger this? I am pretty new to tiki and couldn't find anything..

According to the function is_due(), you only have to set pass_confirm in the table users_users to "0". After successful login you will be prompted to change your password.


posts: 84436

Hi Markus

Welcome to Tiki. Sorry, you didn't get the help you wanted. In the future, if you need help with how Tiki is coded, the user forums aren't the right place. You need to reach the developers for something like that.

Not sure what to say since it seems as though you have figured out the issue. You have right?

By the way, what is Trac? I quick search online didn't reveal anything useful.

posts: 11 Germany
drsassafras wrote:

Hi Markus

Welcome to Tiki. Sorry, you didn't get the help you wanted. In the future, if you need help with how Tiki is coded, the user forums aren't the right place. You need to reach the developers for something like that.


Thanks, seams like that I got the reason for that forum wrong lol

drsassafras wrote:
Not sure what to say since it seems as though you have figured out the issue. You have right?


Yes that's right, so I was wondering how my findings could help others in the future :-)

drsassafras wrote:
By the way, what is Trac? I quick search online didn't reveal anything useful.

"Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management."
But you can use it for other thinks too, like in my case. It was only used for documentation and my job is to migrate to another platform, and I chose tiki.

posts: 1630 Canada
Markus Beckschulte wrote:
But you can use it for other thinks too, like in my case. It was only used for documentation and my job is to migrate to another platform, and I chose tiki.


Yup, and Tiki is great for this use case. However, we don't yet cover the software development use case with integration with source control.

It's great that you are sharing everything you learnt from the migration, as there will no doubt be others. However, migrations scripts are by their nature very tricky to maintain. No one has the sustained interest to maintain them, so they don't keep up with changes in Tiki and the other app. They are usually orphaned (no one is maintaining them)

My company (EvoluData) offers professional services for Tiki and we do help with data migration and Open Source the code for everything we can, but I don't remember anyone ever asking us for a Trac migration. In general, most who want to migrate do not have a budget.

I welcome of course that someone would volunteer to maintain a Trac to Tiki migration tool. But with my time and team, I'd rather we invest our energy on things that make Tiki better. And if we do work on importers to grow the Tiki community, it will be from apps that are

  1. More popular and/or
  2. A more direct replacement

MediaWiki and WordPress fit those categories.

We are training some junior developers and any learning task is great (Gary made the suggestion that this could be one of them). However, this seems too much work for a junior dev that is new to Tiki. This means learning two different apps at the same time, each in its own programming language. And given the uniqueness of the use case, it's not easy to get quick help from senior developers.

Best regards,

Marc


Upcoming Events

1)  21 Mar 2024 18:00 GMT-0000
Tiki Roundtable Meeting
2)  25 Mar 2024 17:00 GMT-0000
29th anniversary WikiBirthday (With Ward Cunningham)
3)  18 Apr 2024 18:00 GMT-0000
Tiki Roundtable Meeting
4)  16 May 2024 18:00 GMT-0000
Tiki Roundtable Meeting
5)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
8)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9) 
Tiki birthday
10)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting