DocDB in AlmaLinux 9

[wgseligman]

I tried to upgrade my DocDB installation to run in AlmaLinux 9. I did not succeed. The main problem is that AlmaLinux 9 runs perl 5.32, which has some major differences vs. the perl 5.16 installation of CentOS 7.

I know that the CentOS 7 end-of-life is still about a year away, and from personal experience I know the codebase upgrade won't be easy. I'm primarily noting this issue so that when you're able to get to it, I'll receive a notification.

[pms967]

I'm running DocDB (8.8.7 + a few assorted patches) on Ubuntu 22.04, which has Perl 5.34
One of the most important modification I had to apply to make it work without too many changes to the code ( see Issue #107 ) was to add the following:

# fix for obsolete assumption of CWD in @INC
use FindBin 1.51 qw( $RealBin );
use lib $RealBin;

to all the Perl files where it was needed.

Other minor changes were needed as a consequence of the much newer CGI module, too.

P.S.: I have been running the same since Ubuntu (server) 16.04, and then all the subsequent LTS releases (18.04 and 20.04) up to now. Will see how it goes with the next one...

[wgseligman]

I figured that part out too, though my solution was dumber; I put the following at the top of all the scripts, use before require "DocDBGlobals.pm";

use lib ".";

While this worked, there were issues with perl hashes (perhaps due to the CGI module, as you said) that caused crashes that I could not debug. For example, when trying to upload a document, the 'submitter' and 'author' lists were blank; this could also have been a database issue, since I'm not facile with MySQL and moving databases between servers.

[pms967]

Make sure to apply this one, too: ( issue #13 )

ab18bbc

I'll check for other relevant mod I had to do and post here later.

[pms967]

This was required for the newer libCGI:

--- DocDBGlobals.pm.orig        2016-07-12 16:15:26.391099458 +0200
+++ DocDBGlobals.pm     2021-05-28 14:39:37.818916058 +0200
@@ -302,4 +302,18 @@
   $Tar = $GTar;
 }
 
+# Added by Paolo Saggese, Mar 21, 2017
+# fix for obsolete startform/endform
+package CGI;
+our %EXPORT_TAGS;
+$EXPORT_TAGS{':standard'} = [ @{$EXPORT_TAGS{':standard'}},
+                                  'startform', 'endform' ];
+sub startform {
+        &start_form;
+    }
+sub endform {
+        &end_form;
+    }
+
+
 1;

Edit: but no more - at least since DocDB 8.8.9 the relevant changes have been included in the official code.

[wgseligman]

I started from a fresh DocDB script installation and applied the changes you suggested. However, it did not solve my problems. Apart from difficulties in fully listing all the documents associated with authors and topics, uploading a new document was not possible; the Submitter and Author fields were blank, so I could not select a valid choice.

Unfortunately, there are no error messages associated with these problems in neither the main server logs, the web server logs, nor the MySQL logs. I can't trace anything.

It appears that there's something else that's funky about AlmaLinux 9, aside from the different perl version, that affects DocDB scripts.

[pms967]

You may try to add:

use CGI::Carp 'fatalsToBrowser';
use warnings;

to the scripts to help debugging.

[wgseligman]

Sigh This is turning into a massive project on the part of someone (me) who doesn't know these perl libraries. My main question stands: Does someone who knows the DocDB package plan to work on AlmaLinux 9 compatibility, given that both FNAL and CERN plan to switch to AlmaLinux 9 by the end of this year?

[pms967]

Issue #113 is one of the many that will likely affect AlmaLinux 9 too.

[wgseligman]

Yes, I had that problem too. However, the problems I had elsewhere (not all documents showing in lists, entry problems on the New Document page) seemed of higher priority.

[pms967]

Yes, I had that problem too. However, the problems I had elsewhere (not all documents showing in lists, entry problems on the New Document page) seemed of higher priority.

well, of course. You should provide at least the relevant log file errors to try to understand what's goin' on...

[wgseligman]

There are no errors in any of the logfiles. That's part of the problem.

You offered a way of generating diagnostics in a previous reply, but my position is the same: This leads me down a rabbit hole of tracing through uncommented Perl code. I'd rather that someone familiar with the package do this work.

I've already written to the Fermilab Computing Division. They are the ones who made the decision to switch to AlmaLinux 9 (a decision I agree with), and they also have many DocDB installations among all their experiments. I'm sure they'll figure something out, and I'll copy-cat their solution (even if it's to move to CERN's Indico).

I just want to know when that happens!

[pms967]

There are no errors in any of the logfiles. That's part of the problem.

could it be that you have the apache (or whichever web server you're using) logging options set too quiet?

You offered a way of generating diagnostics in a previous reply, but my position is the same: This leads me down a rabbit hole of tracing through uncommented Perl code. I'd rather that someone familiar with the package do this work.

indeed.

(even if it's to move to CERN's Indico).

LOL. I doubt it, Indico does a completely different job... :D

BTW, we do use Indico as well. For managing conferences, meetings, etc. But we use DocDB for storing our papers, reports, presentations and so on.

[pms967]

For the record: yet another problem which is relevant for AL9, too: Issue #114

[wgseligman]

With your changes in issues 113 and 114, my copy of DocDB on AlmaLinux 9 seems "closer" than ever. Lists of documents now appear to be correct. Unfortunately, there's still one big issue: adding new documents.

When I try to add a new document in the AL9 version with your changes, this is what I see:

https://www.dropbox.com/scl/fi/p02niaj7jy32wg87kdemr/DocDB-AddDocument-AL9.png?rlkey=365zq1q9lnzbcfabiv9v9aias&dl=0

In contrast, this is the page I see for the same database in the CentOS 7 version:

https://www.dropbox.com/scl/fi/27xvreeojuj11si28m5n2/DocDB-AddDocument-C7.png?rlkey=9z4t1yogzcp17ypjppt27d6qf&dl=0

On the AlmaLinux 9 page, I can try to type in my account name manually the "Submitter" and "Author" fields, but the when I click the "Submit Document" button I get:

There were fatal errors processing your request:
    You must supply a submitter for this document.
    You must supply at least one author for this document. 

Needless to say, this is not a problem on the CentOS 7 version of the page.

Do you see this same problem?

[pms967]

When I try to add a new document in the AL9 version with your changes, this is what I see:

In contrast, this is the page I see for the same database in the CentOS 7 version:

that's just a configurable option. Edit the file "DocDBGlobals.pm", and look for the following (which is the default on new installations):

$Preferences{Topics}{Selector}           = "tree";   # tree, multi, or single
$Preferences{Topics}{NColumns}           = 3;        # number of columns in the topic table
$Preferences{Authors}{Selector}          = "active"; # active, list, or field

To get the same as you had, you may want to change as follows:

$Preferences{Topics}{Selector}           = "multi";	# tree, multi, or single
$Preferences{Topics}{NColumns}           = 4;		# number of columns in the topic table
$Preferences{Authors}{Selector}          = "list";	# active, list, or field

On the AlmaLinux 9 page, I can try to type in my account name manually the "Submitter" and "Author" fields,

on my system, it automatically suggests a list of authors as soon as you start typing. Does it work that way on your AL9 system, too?

but the when I click the "Submit Document" button I get:

There were fatal errors processing your request:
You must supply a submitter for this document.
You must supply at least one author for this document.

Do you see this same problem?

If I choose the "active" selector, as you had, yes, I have some troubles too. But, fortunately, changing the selector to "list":

it does work just fine:

...yet another issue to submit. :-)