Question
We are in the process of installing twiki on a ISP. We seem to have gotten it installed just fine, but we keep running into problems when we try to register a new account. Our problem is described on
http://twiki.org/cgi-bin/view/Support/UserExistsWhenDoesNot, but we are not using modperl.
We have tried moving the my'yfy ers around, to see if that was the problem, but to no avail.
We have deleted the so called duplicate registration, and the user home page that was created when we tried to set up a new user. Yet when we try to recreate the user, it still says the user exists.
Has anyone run into this problem before?
Thanks in advance for any ideas or suggestions you may have.
Environment
--
NilsHayden - 04 Sep 2003
Answer
Please provide the
TWiki.cfg
and
testenv
output as mentioned on
SupportGuidelines, in case that gives us some ideas - some
TWikiDebugging required, so I hope you are OK with Perl!
The relevant code is in
CVS:bin/register, around line 98 where it checks that the topic exists and that the user exists in
.htpasswd
. Hard to see how this can go wrong, but some
writeDebug
and other statements here (to print out the $wikiName and independently check whether it is the storeExists or htpasswd existence check that is causing this error) would help narrow down the problem.
You could also just comment out one or other condition in this
if
statement to see if that bypasses the problem. If it turns out to be the topic existence check, try some
writeDebug
statements in
CVS:lib/TWiki/Store.pm, in the
topicExists
function.
--
RichardDonkin - 04 Sep 2003
Here is our Testenv page. We altered it slightly so that it would fit our needs better. (regarding the script url path and the request uri)
http://www.spatialfocus.com/cgi-bin/twiki/bin/as_testenv
Im not very adapt at perl right now, still learning, but I do have help accessible that knows perl.
Thanks for the help, if you discover anything new, I'd like to hear what you have to say.
I also attached the .cfg file to the page. Thanks again!
--
NilsHayden - 04 Sep 2003
This is Nils' Perl support. The URL to our Main/WebHome is:
http://www.spatialfocus.com/cgi-bin/twiki/bin/view/Main/WebHome
It might be helpful to know that we had to install our own version of Perl on
Hurricane Electric in order to run TWiki, ergo the strange Perl pathnames on our testenv. Our server is running Perl version 5.004_01 at /usr/bin/perl.
We are using the testenv from
http://twiki.org/cgi-bin/view/Codev/CookbookActivePerlTestenv because our server does not set $ENV{ 'REQUEST_URI' }.
I put in some debugging code in /cgi-bin/twiki/bin/register. Lines 94 - 119 of register look like this:
# check if user entry already exists
#
# Debugging code inserted by SaraYurman 20030904
#
TWiki::Func::writeDebug( "topicExists - variables are: $webName, $wikiName, ". ( &TWiki::Store::topicExists( $webName, $wikiName ) ) );
#
# Debugging code ends
if( ( $wikiName )
&& ( ( &TWiki::Store::topicExists( $webName, $wikiName ) )
|| ( htpasswdExistUser( $wikiName ) )
) ) {
# PTh 20 Jun 2000: changed to getOopsUrl
$url = &TWiki::getOopsUrl( $webName, $topic, "oopsregexist", $wikiName );
TWiki::redirect( $query, $url );
return;
}
# check if required fields are filled in
my $x;
for( $x = 0; $x < $formLen; $x++ ) {
if( ( $formDataRequired[$x] ) && ( ! $formDataValue[$x] ) ) {
$url = &TWiki::getOopsUrl( $webName, $topic, "oopsregrequ", );
TWiki::redirect( $query, $url );
return;
}
}
The output looks like this (from ~/twiki/data/debug.txt, when I tried to register Joe Bonnaducci):
04 Sep 2003 - 12:30 topicExists - variables are: Main, JoeBonnaducci,
04 Sep 2003 - 12:30 User entry is :JoeBonnaducci:bkGkakCJOq1u6: before newline
04 Sep 2003 - 12:31 topicExists - variables are: Main, JoeBonnaducci,
NB: Joe Bonnaducci is an imaginary person from my childhood. We can add and delete him at will.
--
SaraYurman - 04 Sep 2003
Here's another angle -- we may have a couple of hiccups between ourselves and the server. I'm getting booted out of my ssh'ed shell every time I blink. Unless somebody sees something else we're doing wrong, I'll evaluate this again after the guys with the wonky router (not
Hurricane Electric, btw) fix their problem. The symptoms are very much like problems we've had with a
site that uses a proxy server. I believe a good connection may well fix it.
syurman@thewood:~$ ping spruce.he.net
PING spruce.he.net (216.218.159.210): 56 data bytes
64 bytes from 216.218.159.210: icmp_seq=1 ttl=243 time=88.6 ms
64 bytes from 216.218.159.210: icmp_seq=2 ttl=243 time=89.2 ms
64 bytes from 216.218.159.210: icmp_seq=3 ttl=243 time=88.6 ms
64 bytes from 216.218.159.210: icmp_seq=4 ttl=243 time=88.5 ms
64 bytes from 216.218.159.210: icmp_seq=5 ttl=243 time=88.5 ms
64 bytes from 216.218.159.210: icmp_seq=6 ttl=243 time=88.9 ms
64 bytes from 216.218.159.210: icmp_seq=7 ttl=243 time=89.2 ms
--- spruce.he.net ping statistics ---
9 packets transmitted, 7 packets received, 22% packet loss
round-trip min/avg/max = 88.5/88.7/89.2 ms
syurman@thewood:~$ ping spruce.he.net
PING spruce.he.net (216.218.159.210): 56 data bytes
64 bytes from 216.218.159.210: icmp_seq=0 ttl=243 time=88.1 ms
64 bytes from 216.218.159.210: icmp_seq=1 ttl=243 time=88.8 ms
64 bytes from 216.218.159.210: icmp_seq=2 ttl=243 time=89.4 ms
64 bytes from 216.218.159.210: icmp_seq=3 ttl=243 time=88.2 ms
64 bytes from 216.218.159.210: icmp_seq=4 ttl=243 time=88.4 ms
64 bytes from 216.218.159.210: icmp_seq=5 ttl=243 time=88.4 ms
--- spruce.he.net ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 88.1/88.5/89.4 ms
--
SaraYurman - 04 Sep 2003
Sounds like you are on the right track to diagnose this - let me know how it turns out. It would be good if you could attach the modified
testenv
since the aim is for this to work 'out of the box' in any environment.
--
RichardDonkin - 05 Sep 2003
We didn't alter the code, just renamed the script so we could see both the standard one and the one attached at
CookbookActivePerlTestenv and make sure we'd cleared all the warnings properly. It works out of the box just fine. And it's much appreciated. I'll probably look into using
SpeedyCGI to help overcome latency in general, and prevent questions like this one. I'm going to go ahead and move this to
AnsweredQuestions, with thanks.
--
SaraYurman - 05 Sep 2003