[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