libresign
libresign copied to clipboard
LibreSign
[fixed] LibreSign v8.0.0-rc5 fails configuration check on settings page
Describe the bug After downloading Java, PDFtk, and JSignPdf, a status of "error" is shown in the "Configuration check" section of the LibreSign settings page.
To Reproduce
-
Start with fresh installation of Nextcloud 28.0.2
-
Copy libresign-v8.0.0-rc3.tar.gz to the apps directory, and uncompress it.
-
Fix ownership of libresign directory created in step 2:
sudo chown -R apache:apache libresign/ -
Log into Nextcloud as the admin and activate the LibreSign app.
-
Open the LibreSign Settings page. Under the "Configuration check" heading, every status is set to "error". I expected this since I haven't installed any binaries yet.
-
From the command line, install Java, PDFtk, and JSignPdf:
[ceperry@newton public_html]$ pwd
/var/www/newton-test.relanet.com/nextcloud/public_html
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --java
Downloading java...
46080826/46080826 [============================] 100%
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --pdftk
Downloading pdftk...
31928448/31928448 [============================] 100%
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --jsignpdf
Downloading JSignPdf...
19027694/19027694 [============================] 100%
-
Refresh LibreSign settings screen in the web browser. The status of Java, PDFtk, and JSignPdf are still set to "error".
-
Run
occ libresign:configure:check. Thestatus of Java, PDFtk, and JSignPdf are set to 'success'.
[ceperry@newton public_html]$ pwd
/var/www/newton-test.relanet.com/nextcloud/public_html
[ceperry@newton public_html]$ sudo -u apache php occ libresign:configure:check
--------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------
Status Resource Message Tip
--------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------
success java Java version: openjdk version "17.0.5" 2022-10-18
success java Java binary: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/java/jdk-17.0.5+8-jre/bin/java
success pdftk PDFtk version: 3.3.3
success pdftk PDFtk path: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/pdftk
success jsignpdf JSignPdf version: 2.2.2
success jsignpdf JSignPdf path: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/jsignpdf-2.2.2/JSignPdf.jar
error openssl-configure OpenSSL (root certificate) not configured. Run occ libresign:configure:openssl --help
--------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------
-
In the LibreSign settings page, click the "Download Binaries" button. After clicking, the button becomes "greyed out", the text of the button changes to "Downloading binaries", and a circular activity indicator begins spinning on the button.
-
After 15 minutes, the activity indicator on the button was still spinning, so I refreshed the settings page. After refreshing, the button text returned to "Download binaries", and all status listed under "Configuration check" were still set to "error".
Expected behavior After installing the binaries, I expected the status on the settings page to change to "success". I also expected the "Download binaries" button to either actually download some binaries, or give an indication that the binaries have already been downloaded.
Screenshots See above.
Environment information (please complete the following information):
- OS: AlmaLinux 8.9
- PHP: 8.2.15
- Apache: 2.4.37
- Browser: Chrome
- LibreSign Version: 8.0.0-rc3
- Nextcloud Server Version: 28.0.2
- Logs (get the entries from nextcloud.log related with LibreSign i.e
tail -f data/nextcloud.log|grep libresign): No log entries contain the string "libresign".
Additional context N/A
I used a similar environment here using Docker with this settings:
- OS: Debian GNU/Linux 12
- PHP: 8.2.16
- Apache: Apache/2.4.57
- Browser: Version 121.0.6167.184 (Official Build) (64-bit)
- LibreSign Version: 8.0.0-rc3 (from here: https://github.com/LibreSign/libresign/releases/download/v8.0.0-rc3/libresign-v8.0.0-rc3.tar.gz)
- Nextcloud Server Version: 28.0.2
I think that the differences at this point isn't the problem.
Could you provide the list of extensions that is installed at your PHP? You can use this command: php -m
Did you have redis or memcache configured in your setup?
The output of "Configuration settings" at admin page is made with output of this command: occ libresign:configure:check, the difference between the places is a bit strange.
@vitormattos Yes, I'm using Redis. Here's the part of my config.php that relates to Redis:
'memcache.local' => '\\OC\\Memcache\\Redis',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => 'localhost',
'port' => 6379,
),
PHP modules installed:
[ceperry@newton public_html]$ php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
igbinary
imagick
intl
json
libxml
mbstring
msgpack
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
random
readline
redis
Reflection
session
shmop
SimpleXML
sockets
sodium
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib
[Zend Modules]
Zend OPcache
If you need any additional information, please let me know. I can also give you an account on the server if that would help. (This is a test server with nothing else on it.)
Hi @DazeEnd Thanks a lot by your contribution. After a hard work, I think that the problem was fixed. I will create a new RC with this fix to be more easy to make the tests from your side.
Hi @vitormattos. Thank you for all your work. I will test your changes tomorrow.
https://github.com/LibreSign/libresign/releases/download/v8.0.0-rc4/libresign-v8.0.0-rc4.tar.gz
Hi @vitormattos I installed RC4 and did some testing. Unfortunately, all the problems we discussed yesterday still appear in my tests. Please see my testing log below for details.
Testing: LibreSign v8.0.0-rc4 Date: 2024-02-22 Testing Steps:
-
Uncompress libresign directory from libresign-v8.0.0-rc4.tar.gz and move to Nextcloud apps directory
-
sudo chown -R apache:apache libresign/ -
Enable Libresign app in Nextcloud
- Install Java, PDFtk, and JSignPdf:
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --java
Downloading java...
46080826/46080826 [============================] 100%
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --pdftk
Downloading pdftk...
31928448/31928448 [============================] 100%
[ceperry@newton public_html]$ sudo -u apache php occ libresign:install --jsignpdf
Downloading JSignPdf...
19027694/19027694 [============================] 100%
-
Refresh Settings > Administration > LibreSign
Configuration check shows that each line has a status of "error".
-
Examine nextcloud.log. The log file is empty.
-
Examine [DocumentRoot]/data/appdata_ocnb4cjpki06/libresign. Everything seems to be there.
[root@newton libresign]# pwd
/var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign
[root@newton libresign]# ls -al
total 49792
drwxr-xr-x. 5 apache apache 4096 Feb 22 09:26 .
drwxr-xr-x. 10 apache apache 4096 Feb 22 09:25 ..
-rw-r--r--. 1 apache apache 115 Feb 22 09:25 checksums_java_17.0.5_8.txt
drwxr-xr-x. 3 apache apache 4096 Feb 22 09:25 java
drwxr-xr-x. 5 apache apache 4096 Feb 22 09:26 jsignpdf-2.2.2
-rw-r--r--. 1 apache apache 19027694 Feb 22 09:26 jsignpdf-2.2.2.zip
drwxr-xr-x. 2 apache apache 4096 Feb 22 09:25 openssl_config
-rwx------. 1 apache apache 31928448 Feb 22 09:26 pdftk
- Run
occ libresign:configure:checkfrom commandline. The commandline reports success.
[ceperry@newton public_html]$ pwd
/var/www/newton-test.relanet.com/nextcloud/public_html
[ceperry@newton public_html]$ sudo -u apache php occ libresign:configure:check
--------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------
Status Resource Message Tip
--------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------
success java Java version: openjdk version "17.0.5" 2022-10-18
success java Java binary: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/java/jdk-17.0.5+8-jre/bin/java
success pdftk PDFtk version: 3.3.3
success pdftk PDFtk path: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/pdftk
success jsignpdf JSignPdf version: 2.2.2
success jsignpdf JSignPdf path: /var/www/newton-test.relanet.com/nextcloud/public_html/data/appdata_ocnb4cjpki06/libresign/jsignpdf-2.2.2/JSignPdf.jar
error openssl-configure OpenSSL (root certificate) not configured. Run occ libresign:configure:openssl --help
--------- ------------------- ---------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------
-
In LibreSign Administration settings, generate a root certificate. It succeeded.
-
In LibreSign Administration settings, under "Identify factors", change the "Account" signature method to "click to sign".
-
Create a new regular user in Nextcloud.
-
As the admin user, upload a PDF file and request a signature from the regular user created in step 11.
-
In a new Chrome "incognito" window, log in as the regular user created in step 11.
-
As the regular user, begin signing the document sent in step 12.
-
Click the "Define your signature." button, draw a signature, and click the "Save" button.
-
On the "Confirm your signature" dialog, click the "Save" button. The signature was successfully saved.
-
Click the "Sign the document." button, to bring up the confirmation dialog.
-
Click the "Confirm" button on the confirmation dialog. After clicking, an error message appears that reads "Internal error. Contact admin."
-
Check nextcloud.log. There are now exactly three lines in nextcloud.log. All three lines include the string "libresign".
[root@newton data]# cat nextcloud.log
{"reqId":"ZddfLGascv3Z@2LdPnEU6wAAAAA","level":3,"time":"2024-02-22T09:50:20-05:00","remoteAddr":"152.117.79.26","user":"[email protected]","app":"PHP","method":"POST","url":"/ocs/v2.php/apps/libresign/api/v1/sign/uuid/8ad5748f-2f99-4a28-8116-c3b480b86f78","message":"Undefined array key \"profileElementId\" at /var/www/newton-test.relanet.com/nextcloud/public_html/apps/libresign/lib/Helper/ValidateHelper.php#306","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36","version":"28.0.2.5","data":{"app":"PHP"}}
{"reqId":"ZddfLGascv3Z@2LdPnEU6wAAAAA","level":3,"time":"2024-02-22T09:50:20-05:00","remoteAddr":"152.117.79.26","user":"[email protected]","app":"libresign","method":"POST","url":"/ocs/v2.php/apps/libresign/api/v1/sign/uuid/8ad5748f-2f99-4a28-8116-c3b480b86f78","message":"OCA\\Libresign\\Service\\SignFileService::forceSaveFileOfDifferentUser(): Argument #2 ($content) must be of type string, bool given, called in /var/www/newton-test.relanet.com/nextcloud/public_html/apps/libresign/lib/Service/SignFileService.php on line 550","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36","version":"28.0.2.5","data":{"app":"libresign"}}
{"reqId":"ZddfLGascv3Z@2LdPnEU6wAAAAA","level":3,"time":"2024-02-22T09:50:20-05:00","remoteAddr":"152.117.79.26","user":"[email protected]","app":"libresign","method":"POST","url":"/ocs/v2.php/apps/libresign/api/v1/sign/uuid/8ad5748f-2f99-4a28-8116-c3b480b86f78","message":"[{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":550,\"function\":\"forceSaveFileOfDifferentUser\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":392,\"function\":\"getPdfToSign\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Service\\/SignFileService.php\",\"line\":281,\"function\":\"getFileToSing\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Controller\\/SignFileController.php\",\"line\":111,\"function\":\"sign\",\"class\":\"OCA\\\\Libresign\\\\Service\\\\SignFileService\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/apps\\/libresign\\/lib\\/Controller\\/SignFileController.php\",\"line\":80,\"function\":\"sign\",\"class\":\"OCA\\\\Libresign\\\\Controller\\\\SignFileController\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/lib\\/private\\/AppFramework\\/Http\\/Dispatcher.php\",\"line\":230,\"function\":\"signUsingUuid\",\"class\":\"OCA\\\\Libresign\\\\Controller\\\\SignFileController\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/lib\\/private\\/AppFramework\\/Http\\/Dispatcher.php\",\"line\":137,\"function\":\"executeController\",\"class\":\"OC\\\\AppFramework\\\\Http\\\\Dispatcher\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/lib\\/private\\/AppFramework\\/App.php\",\"line\":184,\"function\":\"dispatch\",\"class\":\"OC\\\\AppFramework\\\\Http\\\\Dispatcher\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/lib\\/private\\/Route\\/Router.php\",\"line\":315,\"function\":\"main\",\"class\":\"OC\\\\AppFramework\\\\App\",\"type\":\"::\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/ocs\\/v1.php\",\"line\":65,\"function\":\"match\",\"class\":\"OC\\\\Route\\\\Router\",\"type\":\"->\"},{\"file\":\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/ocs\\/v2.php\",\"line\":23,\"args\":[\"\\/var\\/www\\/newton-test.relanet.com\\/nextcloud\\/public_html\\/ocs\\/v1.php\"],\"function\":\"require_once\"}]","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36","version":"28.0.2.5","data":{"app":"libresign"}}
If you need me to do additional testing, or if you would like to schedule a call, please let me know. I am free all day.
Hi @DazeEnd did you removed the user libresign from your instance? I tried logging without success
Hi @vitormattos. Sorry about that. I deleted the old Nextcloud installation/database and started over fresh when I installed RC4. I thought that it would make for a cleaner test.
I have recreated your admin account so that you can log in. Just use the same credentials that I sent you before. (I used your "contact" email address as the recovery email address in case you need to reset the password.)
Can still repro the pdftk error using 8.0.0-rc4 released after #2331 was merged.
Did download 3 times, each time deleting the binary pdftk file, in case it was a corrupted download.
EDIT : Server is arch64, downloaded binary is only available for x86_64.
Hi @Aeris1One, your case is different, I will move your comment to a new issue and will fix at next release.
@DazeEnd looking at your environment just using the web interface, I can't identify what is happening.
Would it be possible to put my ssh public key on your test server? I think it will be easier to identify the problem. If possible, follow my public key: https://github.com/vitormattos.keys
@vitormattos I replied to the email you sent from your librecode.coop email address with details about logging in. Please let me know if you have any trouble.
Hi @DazeEnd After a lot of tests I get a light over the problem. When I execute a command using Java from a request by http, your environment don't work, if the request is made by CLI, work fine. Investigating the problem, I changed the way to execute java because the default way is ignoring errors. When I removed the code to don't display errors or warnings, I got the follow error:
error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
The insight that I got is about the environments of operational system. I need to investigate more and fix the problem. I think that this is a very specific case but solving this will help a lot the project and other sysadmin to don't get the same problem.
Hi @vitormattos Thanks for your work on this problem.
Just so I am clear, do I need to install a java package on my server (using dnf) in order to get the libjli.so shared library? Or are you going to make changes to LibreSign that should fix the problem?
This .so already exists at java folder that is downloaded by LibreSign. Only at context that the execution of PHP is made by HTTP server, this library isn't loaded.
Install java at your server maybe will solve the problem but is a handmade work. LibreSign have an appsetting to store the path of java. Now, LibreSign download a zip with Java, extract this into appdata/libresign folder and use this java to don't have problems with compatibility.
The objective of "configure check" at administration settings is to remove the necessity to run commands at server side, or, at specific cases, to provide instructions to solve what's necessary. I'm looking if have a way to fix the problem or to give a tip to sysadmin with instructions to solve the problem handmade (maybe installing java at server).
Ok. Since it sounds like you can fix this on your side, I will wait until the next RC and then test that.
I tested it with several versions of java and got the same result when trying to run it through a request made to the http server. In all cases, via the command line it works fine.
In all cases with a standalone version of Java (from a compressed file), when running java it returns:
java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
I also tested installing Java on the operating system and in all cases with Java installed on the operating system it returns:
Java8:
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007faa09000000, 2555904, 1) failed; error='Permission denied' (errno=13)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 2555904 bytes for committing reserved memory.
Java > 8:
Failed to mark memory page as executable - check if grsecurity/PaX is enabled
Looking at Java code I found the follow comment: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L4394-L4405
It sounds like it is a block made by your operating system that does not allow the JVM to work.
Could you use another Linux distribution on your server?
On the LibreSign side, what I will do is check that when running Java, the version does not return and if it does not return, I will add a tip to test with another base Linux distribution for the server.
Hi @vitormattos. Your comment above led me to the problem, I think. It appears that the problem is related to SELinux, which runs by default on distributions that are derived from Red Hat (such as the AlmaLinux distribution I use). When I disable SELinux on the server and then start over (deleting and reinstalling Nextcloud and LibreSign v8.0.0-rc4), then install the extra binaries using occ libresign:install --java, occ libresign:install --pdftk', and occ libresign:install --jsignpdf`, then the Configuration check webpage shows "success":
Unfortunately, disabling SELinux in a production server isn't really feasible. SELinux is there for a reason. I want production servers to be security hardened.
I have to end my testing for today, but I suspect that this issues may be related to how the /data/appdata_ocnb4cjpki06/libresign directory was created. Before deleting Nextcloud, I saw that its SELinux context was different. I think that if the directory is created somewhere else (perhaps /tmp), and then copied into place as user apache, it might fix the problems. I will explore this idea more on Monday.
Can you point me to the part of the code that creates the /data/appdata_ocnb4cjpki06/libresign directory? Is that directory moved into place, or is it created (perhaps using PHP's mkdir)?
I suspect that this issues may be related to how the /data/appdata_ocnb4cjpki06/libresign directory was created
This directory is created by internal function of Nextcloud: https://github.com/LibreSign/libresign/blob/main/lib/Service/InstallService.php#L86 and the content of this folder is created by this: https://github.com/LibreSign/libresign/blob/main/lib/Service/InstallService.php#L93-L112. Isn't good to create by another way because Nextcloud have a cache of the contents of this folder and files created by another way, don't will be visible to Nextcloud.
In my tests at your server, I created a file inside java/bin folder to check if PHP can execute the file. Worked fine.
I also made the test to change the contnet of file java/bin/java to this simple script:
<?php
echo 'hi';
I made this to check if was something related to content of java file and also worked fine. I also replaced the content of this file by content of other Linux command (the command date) and worked fine too, returning the current date.
Linux have a command called ldd that list the dependencies of a file. With the file java/bin/java at context that PHP is executed from a request of http server, the command ldd don't return nothing, executing the PHP code from CLI work fine.
I identified that your server is using php-fpm and I think that SELinux at your server use anything like a chroot (i don't know if is exactly this) to limit the process to access memory spaces that the JVM need to be executed and because of this the JVM don't work in your environment when is executed from a process started by the php-fpm and work fine when is started directly by php at cli.
I think that is necessary to check the policies of SELinux to identify what policy is affecting the execution of JVM.
A very simple way to reproduce the problem and make more tests is:
- Open the
index.phpat root folderof Nextcloud. - Replace the begin of index.php by
<?php declare(strict_types=1); exec('/path/to/bin/java', $output); echo implode("\n",$output); die(); - Access the url of your server
- See the source code of current page
CTRL+Uto see the output with line breaks - Refresh the page that will open every when you change the content of index.php file
- After your tests, return the original content of index.php
This will reproduce the problem.
You can change /path/to/bin/java by any linux command.
Now is necessary identify what policy is blocking the execution of JVM
I published a new RC with a small fix that I identified at your environment about the infinity loop when checking the setup status after click at the button.
This RC don't have the fix about SELinux. Will be necessary more tests in your server to identify the policy that is blocking the execution of JVM.
I found this that could help:
https://stackoverflow.com/questions/2231735/selinux-prevents-java-from-running
Could you you enable again SELinux to be possible check if this police will solve the problem?
Hi @vitormattos. I just submitted a new issue #2356 that prevents documents from being signed even when SELinux is disabled. I am going to pause my efforts to fix this issue (#2327) until #2356 is resolved. I figure that it doesn't make much sense to try to get things working with SELinux when I can't even get them working without SELinux. Once #2356 is resolved, I will return to this issue.
Posting here for my future reference: When returning to this issue, test again after running sudo setsebool -P httpd_execmem on.
In the SELinux User's and Administrator's Guide for RHEL 7 I found this entry for the httpd_execmem SELinux boolean:
httpd_execmem
When enabled, this Boolean allows httpd to execute programs that require memory addresses that are both executable and writable. Enabling this Boolean is not recommended from a security standpoint as it reduces protection against buffer overflows, however certain modules and applications (such as Java and Mono applications) require this privilege.
There is no corresponding documentation for RHEL 8, but I have confirmed that the httpd_execmem boolean still exists in RHEL/AlmaLinux 8.
I set the httpd_execmem boolean by running sudo setsebool -P httpd_execmem on, and that seems to have fixed the problem of Apache not being able to run java. But it also seems to have uncovered another problem.
Now the "Configuration check" section is reporting that it cannot find the java shared libraries. I have never tried to get Java to run on an SELinux system, much less allow Apache to run Java on an SELinux system, so it's not clear to me if this is a library path problem when Java is executed by Apache, or if it is anther SELinux access control problem.
I will keep researching.
EDIT: This was not actually the command the cleared the error. (I tried a lot of things during testing, and attributed the "fix" to the wrong command. See my update below.