EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #10258

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] New site still inaccessible

Hi Will,

Just following up on your original email, (although its sound like they are no longer relevant to you), to make people aware more generally

Although EPrints can be run on other port number, the configuration in an archive's cfg/cfg.d/10_core.pl has to correspond with how Apache is configured.  If you want to run on port 8080, which Apache does not listen on by default, you will need to add that to Apache's configuration.  I believe the instructions say for Debian/Ubuntu create a file called /etc/apache2/sites-available/eprints.conf  If at the top of the file you add the following, then EPrints should work on port 8080:

Listen 8080

There are not explicit instructions of how to configure EPrints on a different port number, as it was felt that this would likely add confusion to the installation instructions.  Especially, as nowadays due to the ease of spinning up VMs, it is not something you would commonly need to do.

I believe that if you are on the server itself, if you request http://localhost:8080/ you will get the repository's homepage, as the repository will be the only VirtualHost setup on port 8080, so even if your 10_core.pl specifies the ultimate hostname, the curl command you specified should work.  However, if you configure to run EPrints on port 80, Apache may already have a default VirtualHost on port 80, so curl will get you the default Apache page rather than your repository's homepage.  You would need to find the VirtualHost config for this and remove it / comment it out.  Typically you can type in the following command as root to find this:

source /etc/apache2/envvars; apache2 -S

Ubuntu's /etc/hosts looks different from what I normally see on RHEL-based Linux.  The latter does not normally configure 127.0.1.1, it just uses 127.0.0.1.  However, I believe this should still work.  I assume "arcomtest" is the hostname configured in your archive's cfg/cfg.d/10_core.pl.  If so, EPRINTS_PATH/cfg/apache/ARCHIVEID.conf should have a line like:

ServerName arcomtest

I believe that a curl request for http://arcomtest/ should work.

You say you are using an EPrints tarball for 3.4.7, do you mean https://github.com/eprints/eprints3.4/archive/refs/tags/v3.4.7.tar.gz?  There is and will not be any system package for 3.4.7.  This is because there is no reliable way to upgrade with system packages without the risk of doing irreparable damage, so we decided it is best not to offer them.  

In theory, if you install by cloning from GitHub, then you can just do a git fetch and checkout of the new release version and then just run "EPRINTS_PATH/bin/epadmin update ARCHIVEID" to add any extra core fields.  However, I would still advise running both a pre-production and production repository and do the git fetch/checkout on the former first.  Then you can make sure any bespoke changes you have made to your archive's configuration (or even code) will not break.  If it does, you can fix these issues and make sure they can be quickly deployed when upgrading production.

EPrints' greatest strength and bigness weakness is how it can be almost endlessly customised.  Upgrades are when this weakness can cause the biggest problems.  As it is impossible to be certain that core changes will not impact how a heavily customised repository might behave.  If you have only made minor changes to repository, then generally upgrades through git fetch/checkout should be relatively simple.  However, if uptime is critical, then testing on pre-prod is strongly advised.

I have taken a look at you specific error and the code on line 74 of Rewrite.pm is:

EPrints->abort( __PACKAGE__."::handler was called before EPrints was initialised (you may need to re-run generate_apacheconf)" );

This fails as EPrints does not exists as an object.  This makes me think there is an issue with your Apache configuration.  It is worth trying running generate_apacheconf again but I don't think this is the issue.  You talk about:

PerlSwitches -I/opt/eprints3/perl_lib
PerlSetEnv PERL5LIB /opt/eprints3/perl_lib

These should not need to be configured in Apache. The only configuration that refers to Perl other than that put in place by installing mod_perl should be under EPRINTS_PATH/cfg/ (e.g. /opt/eprints3/cfg/).  If you create an HTTPS (port 443) VirtualHost that will need to add the following line at the end (but inside of) this HTTPS VirtualHost:

PerlTransHandler +EPrints::Apache::Rewrite

Let's assume for now you have not configured HTTPS.  Therefore, if you remove the PerlSwitches and PerlSetEnv lines I mentioned above, re-run generate_apacheconf just in case and make sure there is a symlink at /etc/apache2/site-enabled/eprints.conf which points to /etc/apache2/site-available/eprints.conf and this file contains the line:

Include /opt/eprints3/cfg/apache.conf

Then if you restart Apache you should have an EPrints repository, which the following Curl command downloads the repository homepage:

curl -o /tmp/index.html http://arcomtest/

Obviously, there may be other changes you have made that I am not aware.  If so, some more changes may be required.  I wrote the instructions for installing on Ubuntu and I have had several of my colleagues test this, as well as testing it myself.  They and I have generally been able to get EPrints running on Ubuntu without any real issues.  However, it is possible we can read between the lines and avoid a pitfall that someone following the instructions to the letter might experience.

Regards

David Newman

On 20/09/2025 11:55 am, Will Hughes wrote:
CAUTION: This e-mail originated outside the University of Southampton.
CAUTION: This e-mail originated outside the University of Southampton.

Subject:
EPrints 3.4.7: mod_perl “abort” method error after clean install (Internal Server Error)

 

 

Hi

 

I think my previous message can now be augmented with more detail.

 

I’m setting up a clean install of EPrints 3.4.7 on a local-only Ubuntu VM (Apache 2.4.58, mod_perl 2.0.13, Perl 5.38.2).
I’ve followed the standard installation steps and generated the Apache config using generate_apacheconf.
Apache is running as root (via systemd), and I’m using the default EPrints tarball (not a system package).

Key config details:

  • Apache is listening on port 80.
  • /etc/hosts maps arcomtest to 127.0.1.1.
  • My <VirtualHost *:80> block includes:
    • PerlSwitches -I/opt/eprints3/perl_lib
    • PerlSetEnv PERL5LIB /opt/eprints3/perl_lib
    • ServerName arcomtest
    • The standard EPrints handler and aliases.

Problem:
When I visit http://arcomtest/, I get an Internal Server Error.
The Apache error log shows:

Can't locate object method "abort" via package "EPrints" at /opt/eprints3/perl_lib/EPrints/Apache/Rewrite.pm line 74.

However:

  • /opt/eprints3/perl_lib/EPrints.pm does contain the abort method (I see three sub abort lines).
  • There is only one EPrints install on this VM.
  • Permissions on /opt/eprints3/perl_lib are correct and readable by Apache.
  • PerlSwitches and PERL5LIB are set globally and in the VirtualHost.
  • mod_perl is enabled and working for other test handlers.

 

Has anyone seen this before?
Is there a known issue with EPrints 3.4.7 and mod_perl, or something subtle I might have missed in the environment setup?

 

Any advice or troubleshooting tips would be much appreciated!

 

Thanks,

Will Hughes

 

 

From: eprints-tech-request@ecs.soton.ac.uk <eprints-tech-request@ecs.soton.ac.uk> On Behalf Of Will Hughes
Sent: 19 September 2025 15:04
To: EPrints.org Technical List <eprints-tech@ecs.soton.ac.uk>
Subject: [EP-tech] New site still inaccessible

 

CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Hi

 

I wonder is anyone can help me. I have set up a VM with Eprints 3.4.7 and all seems OK, except that I cannot access it through a browser on my PC. I have been srabbling around with ports.conf, eprints.conf, virtual hosts, and goodness know what. I recall that my real installation (3.4.5) was equally impossible to resolve by myself. I mistakenly thought that this one would be easier, having no requirement for https. No such luck!

To test the web pages, I have been trying curl inside the console, and seem unable to get beyond this:
curl -I http://localhost:8080/

curl: (52) Empty reply from server

Help, please!

 

Best wishes

 

Will   

 

Will Hughes

Emeritus Professor of Construction Management and Economics

School of the Built Environment     

University of Reading, PO Box 219, Whiteknights

Reading, RG6 6DF, UK

 


*** Options: https://wiki.eprints.org/w/Eprints-tech_Mailing_List
*** Archive: https://www.eprints.org/tech.php/
*** EPrints community wiki: https://wiki.eprints.org/