Dear David, dear Chris

Thanks for your input. 😊

So, as I understand your comment («[…]  I cannot remember finding any EPrints specific problems (i.e. where the code is broken, deprecated, etc.) but there were a few things that I needed to do differently to RHEL/Centos7 […] ») it seems to be a normal « New » installation problem, concerning all the depencies of libs etc.

Agree to you David, we’re not big fans of using RPMs in production environment. So actually we’re using the 3.3.16 sources with local changes on RHEL7 and MariaDB.
Probably it’s just a setup of libs and transfering our code to the new RHEL8 server(s). Nothing RHEL8 specific therefore – except the Apache performance tuning?!

Kind regards
Jens

Hi Chris,

Yes, my EPrints SELinux module does seem to be forever expanding.  A lot of that is down more to monitoring (i.e. NRPE) and other stuff I want to do.  I am happy to share if anyone is interested.  One of the odd things I have at the moment is that Apache keeps saying it needs self:capability for net_admin.  I am not sure why Apache needs to be able to touch network configuration.

I have written some Ansible playbooks for automation but those are mainly to apply improvements/fixes on top of the initial Rocky Linux 8 image template, which already has EPrints installed. I then use this image template to build new EPrints VMs.

Although I still maintain and produce the EPrints RPM and Deb packages for new versions of EPrints 3.4, I am not a big fan of using them to upgrade production repositories.  EPrints is not really the sort of software, (because it can be extensively configured), which can be upgraded without there likely being issues.  This is because you cannot account for every configuration scenario.  So even if vanilla EPrints is tested and upgrades nicely, that may not be the case for your repository.  An initial install using a standalone RPM, is easier than installing from source and at least does not leave you at risk of upgrading through the package manager without realising.  However, upgrading in place is quite difficult.  I would always advise upgrading a pre-production instance of your EPrints repository to make sure you won't have any issues or at least have a plan if you do, before upgrading your production repository.

Regards

David Newman

Oh, I've recently done a puppet setup for EPrints on RHEL8. That's a server automation tool. It included all the faff for SELinux.

The interesting bits are in manifests/ and templates/

manifests/init.pp sets up the server, and repository.pp is a pattern to set up each repository, with the config from a git repository.

the EPrints RPM and the default flavour are bundled as they were a pain in the upgrade.

 

On 23/05/2022 09:08, Jens Witzel via Eprints-tech wrote:

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

Dear EP-Tech Group

 

Does anyone here have experience with the transition from RHEL7 to RHEL8 and the consequences of the new security policy in combination with Eprints3.4? What pitfalls are to be expected?

 

Every hint is welcome
Thanks
Jens

 

--
Jens Witzel
Zentrale Informatik
Universität Zürich
Stampfenbachstrasse 73
CH-8006 Zürich

mail:  jens.witzel@uzh.ch
phone: +41 44 63 56777
http://www.zi.uzh.ch

 

*** 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/

-- 

Christopher Gutteridge <totl@soton.ac.uk> 

You should read our team blog at http://blog.soton.ac.uk/webteam/

(I live near Highfield Campus, so in person, outdoor and socially distanced meetings are an option)

*** 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/