-
-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[fixed] LibreSign v8.0.0-rc5 fails configuration check on settings page #2327
Comments
I used a similar environment here using Docker with this settings:
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: 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: |
@vitormattos Yes, I'm using Redis. Here's the part of my config.php that relates to Redis:
PHP modules installed:
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 |
I will maintain open waiting by your tests about configuration check. |
Hi @vitormattos. Thank you for all your work. I will test your changes tomorrow. |
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
|
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. |
@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. |
I get the access, thanks, making tests now. |
Hi @DazeEnd
The insight that I got is about the environments of operational system. I need to investigate more and fix the problem. |
Hi @vitormattos Just so I am clear, do I need to install a java package on my server (using |
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:
I also tested installing Java on the operating system and in all cases with Java installed on the operating system it returns: Java8:
Java > 8:
Looking at Java code I found the follow comment: 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. |
More informations: #2327 (comment) Signed-off-by: Vitor Mattos <vitor@php.rio>
More informations: #2327 (comment) Signed-off-by: Vitor Mattos <vitor@php.rio>
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 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 |
Can you point me to the part of the code that creates the |
More informations: #2327 (comment) Signed-off-by: Vitor Mattos <vitor@php.rio>
This directory is created by internal function of Nextcloud: In my tests at your server, I created a file inside I also made the test to change the contnet of file <?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 I identified that your server is using |
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:
This will reproduce the problem. You can change 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. |
Thanks, I will check the new issue. |
Posting here for my future reference: When returning to this issue, test again after running In the SELinux User's and Administrator's Guide for RHEL 7 I found this entry for the
There is no corresponding documentation for RHEL 8, but I have confirmed that the |
I set the 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. |
Hi @DazeEnd Still in time, to build handmade before launch the new release, is necessary follow these steps:
|
I never made a setup using SELinux. This also is new to me. |
Hi @vitormattos. I will probably stop testing until you release a new RC. I need to reinstall the server and verify that it was actually the Thanks for all your help on this problem. |
I think that after we identify what happening and the solution, that would be good to identify if the environment have SELinux and present to sysadmin the solution of problem. |
I was wrong in my comment above. the
After executing the commands in step 3, java ran successfully and I was left with the shared library error. Note: The
|
Wow! Excellent! |
Maybe, but I'm not sure yet. I still have the "shared library" error: I am hopeful that the changes you made to Java will fix this issue, but I have my doubts. LibreSign worked correctly when SELinux was completely disabled, so I suspect that there is still some SELinux errors at work here. I am continuing to investigate. |
@vitormattos Ok. I think I have it. There are three different SELinux policies/permissions that had to be changed:
After making the necessary SELinux policy changes, I got the "Configuration check" section to work correctly: Here are the complete steps that I followed on my AlmaLinux 8 (RHEL 8) server to make the necessary SELinux policy changes:
I have not yet tested whether I can actually sign documents with this configuration. I've run out of time today, so I will try to find time tomorrow to test the signing process. |
@DazeEnd could you test again with the new release? |
@vitormattos Yes, I will. But it might have to wait until Monday. Today is the first of the month, and I have some other administrative/bookkeeping work that will be taking up most of my day. |
For the benefit of anyone who tries to set this up in the future, I have identified a fourth SELinux change that is required for RHEL/AlmaLinux 8. I needed to give Apache the SELinux |
I will maintain this issue open to check how we can identify if is a problem at SELinux side. |
I have this same issue whenever I try to sign a document, using arch linux.
and I also have the issue where the pdftk binary is not detected on the config check |
Hi @daniromome I think that your case isn't the same because the Java is working fine. Could you move to a new issue to we have a best interaction in a specific thread? |
Closing this issue, I created a fallback issue: |
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:
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'.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):
tail -f data/nextcloud.log|grep libresign
): No log entries contain the string "libresign".Additional context
N/A
The text was updated successfully, but these errors were encountered: