Https3

From EPrints Documentation
Revision as of 14:31, 15 June 2007 by Mans0954 (talk | contribs)
Jump to: navigation, search

Introduction

Setting up EPrints3 to work with https is a little tricky. There seems to be a few bugs to be worked round. This How To considers the following scenario:

  • Two repositories, repos1 and repos2, being served by virtual hosts repos1.FQDN:80 and repos2.FQDN:80
  • A single https domain, at eprints.FQDN:443 (so that only one certificate is needed). Secure pages for repos1 and repos2 will be accessed at eprints.FQDN:443/repos1 and eprints.FQDN:443/repos2 respectively.

This How To should work with EPrints 3.0 or 3.0.1. It was developed on Ubuntu Server 6.06, but should work on other systems without significant changes. The instructions can be adapted for an arbitrary number of repositories.

It is assumed that EPrints is installed in /opt/eprints3/.

Getting started

Install EPrints 3.x following the appropriate instructions.

Run bin/epadmin create twice to create repos1 and repos2.

Edit /opt/eprints3/archives/repos1/cfg/cfg.d/10_core.pl to read:

 $c->{host} = 'repos1.FQDN';
 $c->{port} = 80;
 $c->{aliases} = [];
 $c->{securehost} = 'eprints.FQDN';
 $c->{securepath} = '/repos1';


Make secure versions of the templates:

 cp /opt/eprints3/archives/repos1/cfg/lang/en/templates/default.xml /opt/eprints3/archives/repos1/cfg/lang/en/templates/secure.xml

Repeat these steps for repos2.

Generate the Apache configuration:

 /opt/eprints3/bin/generate_apacheconf

Add 'Include /opt/eprints3/cfg/apache.conf' to the Apache configuration (for Ubuntu / Debian, can replace everything in /etc/apache/sites-avaliable/default with 'Include /opt/eprints3/cfg/apache.conf'). Apache should now be correctly configured to serve the non-secure pages.

Secure Apache Configuration

Next, we want to configure Apache to serve the secure pages. However, generate_apacheconf hasn't created a secure.conf file in /opt/eprints3/cfg/ so this needs to be done manually. Some configuration has been generated for us in /opt/eprints3/archives/repos1/var/auto-secure.conf and /opt/eprints3/archives/repos2/var/auto-secure.conf, but there are some problems with this:

  • Some sections of the configuration overlap;
  • The EPrints_ArchiveID and PerlSetVar EPrints_Secure variables have not been set.
We'll therefore create our own configuration. Create a new file called cfg/secure.conf:
 #cfg/secure.conf:
 NameVirtualHost *:443
 <VirtualHost *:443>
   ServerAdmin itsupport@FQDN
   ServerName  eprints.FQDN
   
   SSLEngine On
   SSLCertificateFile /etc/apache2/ssl/apache.pem
   
   ErrorLog /var/log/apache2/error.log
   
   # Possible values include: debug, info, notice, warn, error, crit,
   # alert, emerg.
   LogLevel warn
   
   CustomLog /var/log/apache2/access.log combined
   ServerSignature On
   
  DocumentRoot "/var/www/eprints"
   
   <Directory "/opt/eprints3/cgi/users">
     AuthName "User Area"
     AuthType "Basic"
     PerlAuthenHandler EPrints::Apache::Auth::authen
     PerlAuthzHandler EPrints::Apache::Auth::authz
     require valid-user
    
     SetHandler perl-script
     PerlHandler ModPerl::Registry
     PerlSendHeader Off
     Options ExecCGI FollowSymLinks
   </Directory>
   <Directory "/opt/eprints3/cgi/users/awstats">
     PerlSendHeader On
   </Directory>
   
   <Directory "/opt/eprints3/cgi">
     SetHandler perl-script
     PerlHandler ModPerl::Registry
     PerlSendHeader Off
     Options ExecCGI FollowSymLinks
   </Directory>
   
   PerlTransHandler EPrints::Apache::Rewrite
   
   Include /opt/eprints3/archives/repos1/var/manual-secure.conf 
   Include /opt/eprints3/archives/repos2/var/manual-secure.conf
 </VirtualHost>

Not the line 'DocumentRoot "/var/www/eprints"'. Create an index.html file in /var/www/eprints/ with a welcome message and links to the home pages of the repositories. Also note that we need to create a manual-secure.conf file for each repository. The contents of this file are as follows:

 #/opt/eprints3/archives/repos1s/var/manual-secure.conf
 
 <Location "/repos1">
   PerlSetVar EPrints_ArchiveID repos1
   PerlSetVar EPrints_Secure yes
   PerlSetVar EPrints_Dir_SecuredCGI /opt/eprints3/cgi/users
   PerlSetVar EPrints_Dir_Documents /opt/eprints3/archives/repos1/documents
   PerlLogHandler EPrints::Apache::LogHandler
 </Location>
 
 Alias /repos1/cgi/accounts/confirm /opt/eprints3/cgi/confirm
 Alias /repos1/cgi/accounts/register /opt/eprints3/cgi/register
 Alias /repos1/cgi/accounts/reset_password /opt/eprints3/cgi/reset_password
 Alias /repos1/cgi/accounts/set_password /opt/eprints3/cgi/set_password
 Alias /repos1/cgi/users/ /opt/eprints3/cgi/users/
 Alias /repos1/ /opt/eprints3/archives/publications/html/

For completeness, we'll also want to add the welcome page to http: Add the following lines to /opt/eprints3/cfg/apache.conf

 <VirtualHost *:80>
   ServerName eprints.FQDN
   ServerAdmin itsupport@FQDN
   DocumentRoot "/var/www/eprints"
 </VirtualHost>

Add 'Include /opt/eprints3/cfg/secure.conf' to the Apache configuration.

One thing remains. In /opt/eprints3/archives/repos1/cfg/cfg.d/misc.pl and /opt/eprints3/archives/repos2/cfg/cfg.d/misc.pl change the line

 $c->{cookie_domain} = $c->{host}; 

to read

 $c->{cookie_domain} = $c->{securehost}; 

Restart Apache. At this point it should be possible to access the repositories at http://publications.modhist.ox.ac.uk and http://oxhistonline.modhist.ox.ac.uk and log in to the secure area.

Debian / Ubuntu specific SSL instructions

Create a file called ssl in /etc/apache2/sites-available/ssl and add the line 'Include /opt/eprints3/cfg/secure.conf'. Run the commands:

 a2ensite ssl
 a2enmod ssl
 apache2-ssl-certificate
 echo "Listen 443" >> /etc/apache2/ports.conf


Bugs

Links which call Perl cgi scripts are broken – e.g. Under Manage Deposits, click New Item. Select an Item Type and then click Next. You will be returned to the Manage Deposits page, rather than to the next step in the workflow. This appears to be because the form action is pointing to http://publications.modhist.ox.ac.uk/cgi/users/home#t rather than /publications/cgi/users/home. As far as I can see, this is a bug, rather than a configuration mistake, though I'm happy to be advised otherwise.

The workaround I have for this bug is to install patch 252, which can be downloaded from http://files.eprints.org/252/

The patch seeks to resolve the problem by introducing a configuration variable users_url in 20_baseurls.pl. The use of perl_url has been replaced with users_url for all links to scripts in cgi/users. For insecure use, users_url can be set to perl_url. When https is requires, it can be adjusted appropriately.

Apply the patch to the EPrints 3.x source (patch -d eprints-3.0/ -p0 < users-url.patch) and re-run configure and install.pl. Add the following lines to /opt/eprints3/archives/repos1/cfg/cfg.d/20_baseurls.pl :

 $c->{secure_urlpath} = $c->{securepath};
 $c->{secure_url} = "https://".$c->{securehost}.($c->{secureport}!=443?":".$c->{secureport}:"").$c->{secure_urlpath};
 # Mod_perl scripts for users scripts
 # If not using https, make this the same as perl_url
 # Otherwise make it  $c->{secure_url}."/cgi"
 #$c->{users_url} = $c->{perl_url};
 $c->{users_url} = $c->{secure_url}."/cgi";

Similarly for /opt/eprints3/archives/repos2/cfg/cfg.d/20_baseurls.pl. Restart Apache. It should now be possible to upload documents, step through workflows etc.

However, some bugs with image urls remain.

Troubleshooting

Some common problems and solutions:

File does not exist: /htdocs

In the log file you may see messages like:

File does not exist: /htdocs

This may be generated by https pages with invalid links to images (e.g. /images instead of /repos1/images) if no DocumentRoot is set for the https virtual host. Note that if we had only one repository per https address we could use DocumentRoot to point to DocumentRoot /opt/eprints3/archives/ARCHIVEID/html/en/ (as suggested by Peter Schober) but this wont work on a per repository base as you can’t put DocumentRoot in a Location block.

EPrint 1 has no directory set

If you get the message “EPrint 1 has no directory set. This is very dangerous as EPrints has no idea where to write files for this eprint. This may imply a buggy import tool or some other cause of corrupt data.” it probably means that you forgot to set Apache to run as eprints:eprints (or alternatively, add the Apache user to the eprints group).

Other

Remember to check that the EPrints_Dir_SecuredCGI and EPrints_Dir_Documents variables are set and cookie_domain is securehost not host.