[EP-tech] Re: EPrints 3.3.12 Installation (from source)
Gilles Fournié
gilles.fournie at cirad.fr
Wed Mar 5 17:02:05 GMT 2014
Hi,
Thanks for your help.
The first log is identical to yours...
-------------------------------------------------------
redirect to
url={http://eprints-test.cirad.fr/cgi/users/login?login_check=1} with
opts=$VAR1 = {};
at /opt/www/eprints-3.3.12/perl_lib/EPrints/Plugin/Screen/Login.pm
line 68.
EPrints::Plugin::Screen::Login::finished('EPrints::Plugin::Screen::Login::Internal=HASH(0x688ae08)')
called at
/opt/www/eprints-3.3.12/perl_lib/EPrints/Plugin/Screen/Login/Internal.pm
line 119
EPrints::Plugin::Screen::Login::Internal::action_login('EPrints::Plugin::Screen::Login::Internal=HASH(0x688ae08)')
called at /opt/www/eprints-3.3.12/perl_lib/EPrints/Plugin/Screen.pm line 240
EPrints::Plugin::Screen::from('EPrints::Plugin::Screen::Login::Internal=HASH(0x688ae08)')
called at /opt/www/eprints-3.3.12/perl_lib/EPrints/ScreenProcessor.pm
line 310
EPrints::ScreenProcessor::process('EPrints::ScreenProcessor', 'session',
'EPrints::Repository=HASH(0x2f47af8)', 'screenid', 'Login::Internal',
'problems', undef) called at
/opt/www/eprints-3.3.12/perl_lib/EPrints/Apache/Login.pm line 43
EPrints::Apache::Login::handler('Apache2::RequestRec=SCALAR(0x6819770)')
called at -e line 0
eval {...} called at -e line 0
-------------------------------------------------------
The second one is different from yours.
First, it shows a bad redirect (I have restored the original
cgi/users/login to run without my "fix"... The $url is empty...)
I only have 12 lines in my cgi/users/login... Your log says "at line 13"
-------------------------------------------------------
redirect to url={} with opts=$VAR1 = {};
at /opt/www/eprints-3.3.12/cgi/users/login line 12.
ModPerl::ROOT::ModPerl::Registry::opt_www_eprints_2d3_2e3_2e12_cgi_users_login::handler('Apache2::RequestRec=SCALAR(0x6362ed0)')
called at
/opt/perl-5.18.2/lib/site_perl/5.18.2/x86_64-linux/ModPerl/RegistryCooker.pm
line 206
eval {...} called at
/opt/perl-5.18.2/lib/site_perl/5.18.2/x86_64-linux/ModPerl/RegistryCooker.pm
line 206
ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x688aca0)') called
at
/opt/perl-5.18.2/lib/site_perl/5.18.2/x86_64-linux/ModPerl/RegistryCooker.pm
line 172
ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x688aca0)')
called at
/opt/perl-5.18.2/lib/site_perl/5.18.2/x86_64-linux/ModPerl/Registry.pm
line 31
ModPerl::Registry::handler('ModPerl::Registry',
'Apache2::RequestRec=SCALAR(0x6362ed0)') called at -e line 0
eval {...} called at -e line 0
-------------------------------------------------------
I also captured the communication (with HttpFox extension).
I have a ?target= which doesn't appear in your capture. So I also tried
without this parameter and it makes no difference.
The result is similar to yours except for the last response header which
doesn't contain any "Location:" :-(
-------------------------------------------------------
(Status-Line) HTTP/1.1 302 Moved
Date Wed, 05 Mar 2014 16:46:04 GMT
Server Apache
Set-Cookie
eprints_session%3Aeprints-test.cirad.fr=760c61dbf83e67e68a7c982c158f5eaf; domain=eprints-test.cirad.fr;
path=/
Location http://eprints-test.cirad.fr/cgi/users/login?login_check=1
Content-Length 0
Keep-Alive timeout=5, max=100
Connection Keep-Alive
Content-Type text/plain
(Request-Line) GET /cgi/users/login?login_check=1 HTTP/1.1
Host eprints-test.cirad.fr
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101
Firefox/27.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language fr-fr,fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding gzip, deflate
DNT 1
Referer
http://eprints-test.cirad.fr/cgi/users/login?target=http%3A%2F%2Feprints-test.cirad.fr%2Fcgi%2Fusers%2Fhome
Cookie
eprints_session%3Aeprints-test.cirad.fr=760c61dbf83e67e68a7c982c158f5eaf
Connection keep-alive
(Status-Line) HTTP/1.1 302 Moved
Date Wed, 05 Mar 2014 16:46:04 GMT
Server Apache
Content-Length 184
Keep-Alive timeout=5, max=99
Connection Keep-Alive
Content-Type text/html; charset=iso-8859-1
-------------------------------------------------------
Do you have any other clue ?
Regards,
Gilles
Le 05/03/2014 15:27, Jan Ploski a écrit :
> Hi,
>
> I don't know - your fixes don't look valid to me. $url eq '' in
> cgi/users/login is also true in my setup, and it works.
>
> Try putting the following code into sub redirect in
> perl_lib/EPrints/Repository.pm:
>
> use Data::Dumper;
> print STDERR Carp::longmess("redirect to url={$url} with opts=" .
> Dumper(\%opts) ."\n");
>
> ...here is what the outputs should look like (it works here without your
> fixes):
>
> redirect to url={http://elib.localdomain/cgi/users/login?login_check=1}
> with opts=$VAR1 = {};
>
> at /opt/eprints/perl_lib/EPrints/Plugin/Screen/Login.pm line 68
>
> EPrints::Plugin::Screen::Login::finished('EPrints::Plugin::Screen::Login::Internal=HASH(0x7faca988a098)')
> called at /opt/eprints/perl_lib/EPrints/Plugin/Screen/Login/Internal.pm
> line 119
>
> EPrints::Plugin::Screen::Login::Internal::action_login('EPrints::Plugin::Screen::Login::Internal=HASH(0x7faca988a098)')
> called at /opt/eprints/perl_lib/EPrints/Plugin/Screen.pm line 240
>
> EPrints::Plugin::Screen::from('EPrints::Plugin::Screen::Login::Internal=HASH(0x7faca988a098)')
> called at /opt/eprints/perl_lib/EPrints/ScreenProcessor.pm line 310
> EPrints::ScreenProcessor::process('EPrints::ScreenProcessor',
> 'session', 'EPrints::Repository=HASH(0x7faca9aab778)', 'screenid',
> 'Login::Internal', 'problems', undef) called at
> /opt/eprints/perl_lib/EPrints/Apache/Login.pm line 43
>
> EPrints::Apache::Login::handler('Apache2::RequestRec=SCALAR(0x7facad1fc820)')
> called at -e line 0
> eval {...} called at -e line 0
>
> redirect to url={/cgi/users/home} with opts=$VAR1 = {};
>
> at /opt/eprints/cgi/users/login line 13
>
> ModPerl::ROOT::ModPerl::Registry::opt_eprints_3_2e0_2e5_cgi_users_login::handler('Apache2::RequestRec=SCALAR(0x7faca9a0da58)')
> called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
> eval {...} called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 204
>
> ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x7facad24d7e8)')
> called at /usr/lib/perl5/ModPerl/RegistryCooker.pm line 170
>
> ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x7facad24d7e8)')
> called at /usr/lib/perl5/ModPerl/Registry.pm line 31
> ModPerl::Registry::handler('ModPerl::Registry',
> 'Apache2::RequestRec=SCALAR(0x7faca9a0da58)') called at -e line 0
> eval {...} called at -e line 0
>
>
> Here is what the communication after POSTing the login form should look
> like (captured with wireshark):
>
> HTTP/1.1 302 Moved
> Date: Wed, 05 Mar 2014 14:11:06 GMT
> Server: Apache/2.2.16 (Debian)
> Set-Cookie:
> eprints_session%3Aelib.localdomain=3cfde222c19cc70f4001b82af1caed64;
> domain=elib.localdomain; path=/
> Location: http://elib.localdomain/cgi/users/login?login_check=1
> Content-Length: 0
> Keep-Alive: timeout=15, max=96
> Connection: Keep-Alive
> Content-Type: text/plain
>
> GET /cgi/users/login?login_check=1 HTTP/1.1
> Host: elib.localdomain
> User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:27.0)
> Gecko/20100101 Firefox/27.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> DNT: 1
> Referer: http://elib.localdomain/cgi/users/login
> Cookie: eprints_session%3Aelib.localdomain=3cfde222c19cc70f4001b82af1caed64
> Connection: keep-alive
>
> HTTP/1.1 302 Moved
> Date: Wed, 05 Mar 2014 14:11:06 GMT
> Server: Apache/2.2.16 (Debian)
> Location: /cgi/users/home
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 237
> Keep-Alive: timeout=15, max=95
> Connection: Keep-Alive
> Content-Type: text/html; charset=iso-8859-1
>
> Gilles Fournié wrote:
>> Hi,
>>
>> Thanks for your answer, Jan.
>>
>> I did not see anything about cookies. I compared with a test version we
>> were using before (it's a 3.3.11 installed from binaries).
>> Although the naming of the cookie has changed (in 3.3.12, the name
>> contains the hostname), it seems that they are correctly set.
>>
>> I tracked the login process with Data::Dumper and I managed to get the
>> connection working when using the admin account.
>>
>> But I had to modify (very lightly) two files.
>> And as I am very far from being an Eprints expert, I don't like it very
>> much...
>>
>> Here are the diffs (testing for empty strings in addition to the
>> original "defined" test) :
>>
>> > diff --git a/cgi/users/login b/cgi/users/login
>> my $repo = EPrints->new->current_repository;
>>
>> my $url = $repo->param( "target" );
>> -$url = "/cgi/users/home" if !defined $url;
>> +$url = "/cgi/users/home" if !defined $url || $url eq '';
>>
>> $repo->redirect( $url );
>>
>>
>> > diff --git a/perl_lib/EPrints/ScreenProcessor.pm
>> b/perl_lib/EPrints/ScreenProcessor.pm
>> sub process
>> {
>> $opts{screenid} = $opts{session}->param( "screen" );
>> }
>> - if( !defined $opts{screenid} )
>> + if( !defined $opts{screenid} || $opts{screenid} eq '' )
>> {
>> $opts{screenid} = "FirstTool";
>> }
>>
>> What do you think about that ?
>> Did this patch hide a bad config on our server ?
>>
>> Thanks
>> Gilles
>>
>>
>> Le 05/03/2014 13:00, Jan Ploski a écrit :
>>> I would start troubleshooting this by looking at Firebug's network panel
>>> and comparing the exchanged request/response sequences during login to a
>>> working configuration, paying particular attention to Host and
>>> Set-Cookie / Cookie headers. My guess is that due to some Apache
>>> misconfiguration (maybe a mismatch in hostname actually used by Apache
>>> and the one EPrints thinks it should use) cookies are not being
>>> exchanged correctly, so that you end up in some "half-logged in" state.
>>>
>>> Other than that, you can insert "use Data::Dumper; print STDERR
>>> Carp::longmess(Dumper($variable));" anywhere in the code to output a
>>> stack trace and $variable's content to Apache's log, and trace undefined
>>> values back to where they should be set.
>>>
>>> Gilles Fournié wrote:
>>>> Hi,
>>>>
>>>> We are fresh newcomers to the EPrints community (Cirad is a French
>>>> research centre working in the field of tropical agronomy, breeding, ...).
>>>>
>>>> The library team has made the choice of EPrints to manage the documents
>>>> produced by our research teams.
>>>>
>>>> So, I am trying to install EPrints 3.3.12 on the dedicated server (the
>>>> server is still in intranet zone, for now, so I can't post useful links) :
>>>>
>>>> * CentOS release 6.5 (Final)
>>>> LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarc
>>>>
>>>> * MySql 5.6.15
>>>> * Perl 5.18.2
>>>> * Apache 2.2.26 with mod_perl 2.0.8
>>>>
>>>> Installation of EPrints seems OK :
>>>>
>>>> * "epadmin create", to create the test repository + modification of
>>>> httpd.conf
>>>> * import of testdata
>>>> * generate_views
>>>> * "indexer start"
>>>>
>>>> But, I still get errors when running unit_tests...
>>>>
>>>> * one error on 30_search.pl
>>>> * fails (exists) on 84_sword.pl "1/27 Bailout called. Further
>>>> testing stopped: Failed to parse
>>>> http://-----.cirad.fr/sword-app/servicedocument :1: parser error :
>>>> Space required after the Public Identifier"
>>>>
>>>> And on the web interface I run through several problems :
>>>>
>>>> 1. When I try to login with the admin account created during "epadmin
>>>> create", I get a page "Moved" instead of the "Manage deposits"
>>>> page. I have found that another user reported the same problem
>>>> (http://www.eprints.org/tech.php/18174.html) but I didn't find any
>>>> answer to his mail.
>>>>
>>>> If I go back one page, I return to the home page and I can see
>>>> that the connection has been done. I am identified under the admin
>>>> account...
>>>>
>>>> 2. If I try to edit the user profile through the "Profile" link, I
>>>> get an error : "user does not exist. It may have been erased."
>>>>
>>>> The url of this page is
>>>> http://-----.cirad.fr/cgi/users/home?screen=Workflow%3A%3AView&dataset=user&dataobj=
>>>>
>>>> If I tweak this URL, adding "1" at the end, I obtain the profile
>>>> page...
>>>>
>>>> 3. On this profile page, if I click on "Edit", this produce a "500
>>>> Internal Server Error"
>>>>
>>>> The Apache log has a line related to this error : "Can't call
>>>> method "action_buttons" on an undefined value at
>>>> /opt/www/eprints-3.3.12/perl_lib/EPrints/Plugin/Screen/Workflow/Edit.pm
>>>> line 206."
>>>>
>>>> Note: if I don't click "Edit" but rather one of the links on field
>>>> titles (as Name or User Type), I get to the edit page
>>>> (http://-----.cirad.fr/cgi/users/home?screen=Workflow%3A%3AEdit&dataset=user&dataobj=1&userid=1&stage=default#name)
>>>> without a problem.
>>>>
>>>> 4. I get the same kind of problems when trying to edit documents.
>>>> From the "Manage deposits" page, I can view documents but not edit
>>>> them : same "500 Internet Server Error" but with a different line
>>>> in the error_log " Can't call method "render" on an undefined
>>>> value at /opt/www/eprints-3.3.12/perl_lib/EPrints/Workflow.pm line
>>>> 446.". As for the user editing, if I click on a title link from
>>>> the view page of a document, I correctly reach the edit page.
>>>>
>>>> 5. Last problem. When I try to search the repository
>>>> (http://-----.cirad.fr/cgi/search//simple or advanced), I get a
>>>> redirection error from firefox : "The page isn't redirecting
>>>> properly - Firefox has detected that the server is redirecting the
>>>> request for this address in a way that will never complete"
>>>>
>>>> Has anybody any clue or advices of things I should look at...
>>>>
>>>> With all my apologies for this long message...
>>>> Thank you for your assistance.
>>>>
>>>> Gilles
>>>>
>>>> * Anglais - détecté
>>>> * Anglais
>>>> * Français
>>>> * Espagnol
>>>>
>>>> * Anglais
>>>> * Français
>>>> * Espagnol
>>>>
>>>> <javascript:void(0);>
>>>>
>>>>
>>>>
>>>> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>>>> *** Archive: http://www.eprints.org/tech.php/
>>>> *** EPrints community wiki: http://wiki.eprints.org/
>>>> *** EPrints developers Forum: http://forum.eprints.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20140305/3db1a36c/attachment-0001.html
More information about the Eprints-tech
mailing list