Loading...
 
Skip to main content

Features / Usability


Intertiki config

Okay I've read this documentation:

http://doc.tikiwiki.org/IntertikiQuestion

And scoured the forums etc as best I can - if the answer is in there some where my search fu isn't up to the task of finding it. Found plenty of other stuff but that hasn't provided the enlightenment I'd hoped for either.

So here I am, trying to set up intertiki as it would be if I'm understanding it all correctly an ideal thing for what I'm looking for (one log in for multiple wikis). But I can't get it to play.

I'm on shared hosting (lunarpages in case that helps in any way), got a dedicated ip there because it was need for other things, running tiki wiki 2.2.

for the sake of simplicity lets call my tiki's tikimaster and tikislave. Tikimaster being where I want people to register, tikislave being anohter tiki where I'd like people to be able to log into after registering at tikimaster.

Both tiki's I'm trying are on the same hosting, I've tried using my dedicated ip and 127.0.0.1 and neither has an effect. On the tikimaster I just can't get the tiki to save my setting for intertiki-slave mode as anything other than:

'tiki-master as master'

when I'm pretty certain it should be:

'no'

Neither have I figured out where in the database tables that little gem might be stored so if needs be I can hack it to the right value.

I've experimented with Path, access log file and error log file as I might not how those entries should be structured. See both mastertiki and slavetiki are on secondary domains in my account so via ftp their path is

$account_home/public_html/mastertiki
$account_home/public_html/slavetiki

so my gut instinct is those file paths should simply be:
/remote.php
/mycreatedlogsdirectory/error.log
/mycreatedlogsdirectory/access.log

But the docs again aren't clear on this so it might that they need to point to the folder the domain sits in, i.e.:

/mastertiki/remote.php

or even further up the directory tree. Can't imagine it'd go further than that but without a solid understanding I'm floundering around here making small tweaks to the config at both mastertiki and slavetiki, trying to log in at slavetiki and getting told I've an invalid username for an account I've registered on mastertiki.

Yes slavetiki has login set to web server. Mastertiki doesn't, should it?

And as a final nail in the coffin my error and access logs have at all times remained empty suggesting to me that slavetiki isn't getting very far at all with trying to check another tiki for user info.

So now I'm properly lost. It feels like there is something simple I'm missing, any suggestions for things I can try/places to look/settings to twiddle etc would be real handy. Especially if you happen to have a working set up and can share with me some details about the settings and circumstances of how it is working....

Cheerio for now,

Alan

Hi Alan

I am on siteground but could not get intertiki working too..I installed some tikis there, managed to make the basic intertiki settings following the documentation but client tikis don't recognise the master tiki key (i get error saying the key is wrong, although it is set correctly). I am not sure if it is something with the settings of the siteground or with tiki, would need some time to test locally.

Please post if you managed to get it working,
cheers,
Gezza


log can be where ever you want - need only to be writeable but the server. For instance /var/log/tiki/intertiki_access.log.

Depending how you access your main if it is http://main.tw.orgQuestion, then the path must be /remote.php.
If you access like http://tw.org/mainQuestion. Then the path must be /main/remote.php.

Check also your server log to see remote.php is called. If no your key must be incorrect.


Thank you for the input - muchly appreciated.

I've managed to catch up with gezza and get the error message he is getting by deleting server/client details and re-entering them. I noticed a descrepancy between names and profile entry names that I thought might upset things which is why I did that and it seems I was about right.

But still no cigar.

I've changed the code in a few places to dump out as much debugging information as I could on the client side and found out that everything is about what I expected it to be and all seems to be set up correctly - the key being sent is right, the names/ip addresses/domains and remote.php locations all look spot on.

My conclusion is that the problem is happening at the server end of the process. My problem there is I'm not sure how to get similar debugging information from the server. What I suspect is happening is the either the server is retrieving the wrong key for comparison or the comparison itself is flawed somehow. If someone could help me out by pointing me in the direction of the files where the key calls and comparisons actually take place that would be a massive help. Traversing the directory structure of tiki-wiki to follow program calls is tricky when you can't use a nice development environment.

The sad thing is if I can't get this working in a day or so I'm going to have to give up on it and launch some sites with each requiring a seperate log in. It isn't the end of the world but having one log in for all the sites would have been soooo much better and this quite clearly works for some people...


okay, I'm about out now. This is sucking up too much time for not enough progress. Maybe this will help someone else figure out what might be causing the issue - I'd be happy to hear more suggestions for things to try.

Important files to look at:
/lib/pear/xml/rpc.php
/lib/userlib.php
/remote.php
/tiki-login.php

I appended a print_r of $prefs to the error string and output it to screen so I could look at what values were getting passed, here is the highlights:

feature_intertiki => y
feature_intertiki_server => n
feature_intertiki_slavemode => n
interlist => Array ( bob => Array ( name => bob host => http://somesiteorother.comQuestion port => path => /remote.php groups => ) )
feature_intertiki_mymaster => bob
feature_intertiki_import_preferences => n
feature_intertiki_import_groups => n
known_hosts => Array ( 0 => )
tiki_key => 456
intertiki_logfile =>
intertiki_errfile =>
feature_intertiki_sharedcookie => y

I find the bits I've bolded to be somewhat suspect. This was from the client site so I'm wondering why it isn't an intertikie slave - I'd have thought that should be set to 'y', why the log file references are empty I'm not sure but I'll chalk it up to not being able to establish a connection to the master site. I wouldn't have though known hosts should be empty either.

I tried changing those values but either put in wrong values to get it through the validation process or the problem runs deeper than that.

I don't suppose someone who has got this working would take a look at this on their system and see what values are in their $prefs?


Hi izombieyou!

Some good news from me: today I tested locally and managed to get it working quite easily! 😊

I decided to start from scratch: fresh mysql, php5 and apache (all with default settings), 2 instances of Tiki 3.1 with default profile (All this on Vista)

I just simply enabled the things needed for Intertiki, made the configuration and voilá, it worked! New users registered in the Tiki31a instance got authenticated in the Tiki31b instance without problems 😊

So at least now we know that the feature CAN work, now we need to find out where is the problem..In the next days I will play around to see if there is something with the webhosting provider settings (apache, php, etc) or something within Tiki (maybe another feature or setting makes the trouble)

So dont give up, there is light at the end of the tunnel - and it is not the train.. 😊

Cheers,
Gezza


more good news: managed to get intertiki working on hosting environment too (@ siteground.com)

I have updated the documentation describing the correct settings (it was a settings issue after all..)

http://doc.tikiwiki.org/IntertikiQuestion

cheers,
Gezza


Cheers for getting back into it and reporting your results but I still can't get it to play for me. Maybe it is because I'm on 2.2 not 3.0. Sadly that isn't something I can test with 3.0 requiring php5 - at least not until all the other software on my sites (well okay that just means the shop) have been updated to php5 also...

Guess this is something I'm going to have to come back to at a later date.