I totally agree.

To remove the deb leaving the files intact:

- vim /var/lib/dpkg/info/eprints.postrm to remove any step (comment out everything)
- mv /usr/share/doc/eprints /usr/share/doc/eprints.back
- apt remove --purge eprints
- mv /usr/share/doc/eprints.back /usr/share/doc/eprints

as usual, analyze and do backups, but this should help you to move out from debs.

Another problem with deb is that upgrading from a distribution to another, dependencies changes, so apt will try to remove eprints (for example upgrading from stretch to buster) because the dependencies are not satisfied.

Hi James,

I generally discourage people from using the DEB or Yum repositories for EPrints, as managing upgrades is difficult, as there will almost always be some change, even for a new minor version that does not work out of the box and would be difficult to script within the DEB/RPM installer.  Especially due to how much an EPrints repository can be customised. 

The main reason I continue to produce new DEBs and RPMs is that this allows for a generic and quite prescriptive method for someone with minimal EPrints knowledge to install a new EPrints repository that should work pretty much out of the box.  However, the intention is that people would just want this so they can try out EPrints before deciding if they wanted to create their own production EPrints repository.  (However, I can appreciate how using a OS package repository make seem like the more official/robust way to install an application).  Installing from source (tarball or Git) can be more difficult, although with the dependencies listed on the wiki pages [1] [2] but it comes with significant advantages when it comes to upgrading.

My general advice for installing EPrints, if you are reasonably experienced, is to install from GitHub.  This allows you to install a specific version using a tag.  It also then allow you to see any core code files you might have modified before trying to upgrade.  Although, I would advise against doing a "git fetch -> git checkout NEW_TAG" on a live repository without backing up and having allocated a decent length at-risk period, (e.g. 2 hours or more if your repository is quite bespoke), where users either cannot access or are advised against trying to use your EPrints repository.  An important part of the upgrade is to check for any new dependencies or changes (e.g. [3]) that may mean your upgraded repository does not work straight out of the box.

I wrote some instructions for upgrading between 3.4.x versions [4] but only got as far as writing the schedule for upgrading using a source tarball, which I think could still be improved.  I will try to find time to write the schedules for the other two.  However, I suspect the one for the upgrading a Linux package will be either don't do this or if you do follow a similar approach to using Git to checkout a new released version tag.

Regards

David Newman

[1] https://wiki.eprints.org/w/Installing_EPrints_on_Debian/Ubuntu
[2] https://wiki.eprints.org/w/Installing_EPrints_on_RHEL/Fedora/CentOS
[3] https://wiki.eprints.org/w/EPrints_3.4.4
[4] https://wiki.eprints.org/w/Upgrading_between_EPrints_3.4_versions

On 14/11/2022 9:21 am, James Kerwin wrote:

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

Morning David, and the rest of the list I forgot to remove from my reply on Friday,

Once you helped me understand that I'd actually done an upgrade everything became much easier and was generally a positive experience.

In my initial panic I reverted to eprints default templates and _javascript_. Disabled all custom plugins etc to take it right back to default. Adding the new fields to the database fixed a lot of problems. Manually copying over some _javascript_ and images (plus.png, warning, loading bar images etc) to my local archive fixed everything else. Then I sequentially re-enabled plugins, local _javascript_ and templates/citations etc then everything was fine.

I'll not be in a rush to do this again, but not the disaster I thought it was on Friday.

Thanks,

James

On Fri, Nov 11, 2022 at 2:59 PM David R Newman <drn@ecs.soton.ac.uk> wrote:

Hi James,

Yes you were correct with you amendment to the flavours/pub_lib/inc.  Based on the added fields this sounds like a 3.4.3 to 3.4.4 upgrade.  Therefore, check for information at:

https://wiki.eprints.org/w/EPrints_3.4.4

However, the fix I suggested is the only know new dependency on a 3.4.3 -> 3.4.4 upgrade.  However, if you do find any others let me know and I will update this wiki page.

The issue you look to be reporting now seems to be a permissions one.  I guess there is a chance that the OS package upgrade has changed the permissions on some directories which  prevents files from being copied.  This is not something I have noted before but it is worth checking the /usr/share/eprints/archives/liverpool_rdm/html/en/style/images/ directory and its ancestor directories.  Alternatively, it could be an SELinux file contexts issue.  However, that seems unlikely, as if you knowingly had SELinux enabled, you would probably know that on any upgrade you need to check the audit log of any thinking SELinux may be now blocking.  The EPrints OS packages do not contain their own SELinux policies.  Mainly due to how much EPrints can be customised, (e.g. Bazaar plugins, ingredients and bespoke code for the archive).  This would be near impossible to write an SELinux policy that would cover all bases, whilst also not be being overly lax.

Regards

David Newman

On 11/11/2022 14:32, James Kerwin wrote:

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

To spare the wider list of my woes I'll send this to you.

I've added:

ingredients/prototypejs

to inc.

Though I still appear to be having problems. I'll keep at it today to see where I get.

Thanks,

James

On Fri, Nov 11, 2022 at 2:23 PM James Kerwin <jkerwin2101@gmail.com> wrote:

Hi David,

Thank you so much for your response.

The files were weird. In my logs I had:

Can't copy /usr/share/eprints/lib/static/style/images/bar_24px.png to /usr/share/eprints/archives/liverpool_rdm/html/en/style/images/bar_24px.png: Permission denied

I went through and copied each one and they vanished from my error list in Chrome inspector. Not the end of my problems.

Doing the dry run of UPDATE yielded:

Dry run: Fixed subject__rindex.field collation
Dry run: Fixed eprint__rindex.field collation
Dry run: Added additional_recipients to dataset saved_search
Dry run: Fixed saved_search__rindex.field collation
Dry run: Added upload_url to dataset document
Dry run: Fixed document__rindex.field collation
Dry run: Fixed user__rindex.field collation
Dry run: Fixed request__rindex.field collation
Dry run: 0 datasets added
Dry run: 2 fields added
Dry run: 0 counters were added

So it's adding two new fields when I run it properly? upload_url in Document and additional_recipients to saved_search?

Now on to inc. I currently have:

flavours/pub_lib
ingredients/bazaar
#ingredients/jquery
#site_lib

At risk of sounding incredibly stupid, what do I need to do to add prototype here? I have seen a prototype.js file somewhere today. Do I need to point it to that?

Thanks,

James

On Fri, Nov 11, 2022 at 1:15 PM David R Newman <drn@ecs.soton.ac.uk> wrote:

Hi James,

"appeared to be some eprints updates amongst them."

Do you mean you have EPrints installed as an OS (RPM or Deb) package?  If so there may be a number of issues if EPrints source code has been updated.  The first thing I would do is check to see if there are any updates required to the database:

bin/epadmin update_dry_run REPOID

If these looks sane then run "epadmin update REPOID" to actually do the update.

If you are getting Internal server error messages you can usually see them in the webserver error log files. As I assume you have HTTPS enabled this will likely be in the ssl_error_log or a similarly named file. (Check what you have set in your archive's ssl/securevhost.conf file).

It may be that you need to tinker with the ingredients included fro EPrints.  One requirement of upgrading an existing EPrints 3.4 repository to 3.4.4 is to add the prototypejs ingredient to flavours/pub_lib/inc.  This the first step in trying to make EPrints _javascript_ API agnostic and ultimately replace EPrints underlying _javascript_ library (Prototype) either with a more commonly used JS library or just to use native JS.

I am not sure what would be causing PNG images to give internal server errors that does seem very odd.  Hopefully the error messages in the webserver log files will explain.

Regards

David Newman

On 11/11/2022 12:55, James Kerwin via Eprints-tech wrote:

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

Hi All,

I've just applied some Ubuntu updates and to my horror noticed there appeared to be some eprints updates amongst them.

Now the page where I login to edit an eprint or upload files etc. is messed up. All of the tabs (Preview, Details, Actions, Messages, History and Issues) show all of their content under each tab. Eg. under details I see the preview, details, actions and so on. Same if I click on another tab.

It is also not allowing me to upload files. I can go through the motions of adding a file, but when I click "upload" the page appears to refresh and do nothing.

My guess is that this has introduced some _javascript_ problems. Irritatingly I think I've fixed this same problem previously.

Can anybody offer some advice on where to look? If I "inspect" the page in Crome I can see that we can't access minus.png, plus.png, warning.png etc giving a "500 (internal server error)".

Thanks,

James

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

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