Error reading modules directories with ZFS #150
Comments
|
It looks like you don't have the modules installed in their directory. Can you check the presence of the *so files in the |
|
Also when you say |
|
On June 26, 2020, at 12:25 PM, Nicolas Mora ***@***.***> wrote:
init-core.sqlite3.sql only creates the core tables, not the modules tables, neither initializes the data, so you shouldn't use it to initialize your environment.
Hmmm... Not to argue with the creator but there are a few insert instructions in the sql files. In fact, this is how admin user is added.
It looks like you don't have the modules installed in their directory. Can you check the presence of the *so files in the *_module_path values referenced in the config file?
The modules are in the module path. We double checked. We have the full path names, and confirmed the the user (an admin) has full access to the path hierarchies.
…—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
[ { ***@***.***": "<a href="http://schema.org">http://schema.org</a>", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "<a href="#150 (comment)">https://github.com/babelouest/glewlwyd/issues/150#issuecomment-650269994</a>", "url": "<a href="#150 (comment)">https://github.com/babelouest/glewlwyd/issues/150#issuecomment-650269994</a>", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "<a href="https://github.com">https://github.com</a>" } } ]
|
|
Downloaded the debian-buster.tar.gz file, extracted the contents, and dpkg -i the .deb files.
…On June 26, 2020, at 12:25 PM, Nicolas Mora ***@***.***> wrote:
Also when you say Install Glewlwyd using your favorite method., what method is it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
[ { ***@***.***": "<a href="http://schema.org">http://schema.org</a>", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "<a href="#150 (comment)">https://github.com/babelouest/glewlwyd/issues/150#issuecomment-650270212</a>", "url": "<a href="#150 (comment)">https://github.com/babelouest/glewlwyd/issues/150#issuecomment-650270212</a>", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "<a href="https://github.com">https://github.com</a>" } } ]
|
Oh no, please do ;)
In the So by initializing your database with the The problem lies where this error message comes from: For some reason, your glewlwyd instance doesn't loads the modules properly. Can you post your full glelwwyd log? |
|
Hi, We followed the instructions give here Install Glewlwyd on Debian Buster but changed the version numbers to match the latest release v2.3.1. The full installation log, and the glewlwyd console log is attached. We are using sqlite3 for this test; so we recreated the database using init.sqlite3.sql only. |
|
It seems that you follow the install procedure correctly, yet something's not right, I still don't know what yet. In your logs, the interesting part is missing. The glerwlwyd logs you display are those: I need what's before that in the glewlwyd.log file to try to understand what's wrong. In your first message, you mention these error messages: That's the kind of error message I need |
|
This is why I asked if there is an order to how sql files are installed.
then we get this
If this order,
or
PS: We are happily enjoying v2.2.0 -Works Great! Thank you. |
|
There is no order to run the sql files because there is only one sql file to run, in your case it's the file docs/database/init.sqlite3.sql. What I see in your log output is that glewlwyd loads no plugin at all. Normally, your log output should look like that: Can you check that the module paths in your config file are correctly filled, and point to a directory where the module files are present are accessible to the user running glewlwyd? |
|
Thanks @babelouest. Can you please point me to the routine that attempts to load the plugin modules, or walk me through the process of loading the modules from the database? strace is showing that the .so files are there but read from the database? |
|
More information.
Should those not return the list of modules after a fresh installation, or are we barking up the wrong tree? |
|
We are getting warmer - we think.
We got an error -
So, glewlwyd is probing the directory but is refusing to load the files. Strace does not show glewlwyd trying to read the directory entries. In fact chmod 0000 on the files does not make a difference to glewlwyd. |
|
Eureka! (We think) We use SmartOS internally for various functions and reasons. If you look carefully at the man pages for readdir Unfortunately, ZFS does not return DT_REG. All is not lost, It would be wonderful if lines 1626 , 1886, 2135, and 2397 in glewlwyd.c are modified to also test for DT_UNKNOWN. I am only a C program reader (not a programmer) so the fix could be a simple DT_REG || .. DT_UNKNOWN test. However, according to this SO question. If d_type is DT_UNKNOWN you need stat to learn anything about whether the directory entry is itself a directory or whatever. I do not believe that this use case is that complex. It will be my pleasure to help with testing when you are ready. |
|
Ah, that's very interesting. Indeed I only test I'll add an else case with DT_UNKNOWN according to the documentation, I'll let you know when there will be a version to tests. |
babelouest
changed the title
|
Ah, the beauty of open source software:) |
|
A quick search through glewlwyd code base shows DT_REG is used in glewlwyd.c only. My conclusion after a simple analysis of that file makes me believe that a simple |
|
That may work in your case, but if the |
|
You are right. Of course you are right - Reason I did not want to argue with the creator:)
The two directories "." and ".." proved to be a source of annoyance but the modules are loaded and we can carry on with our testing. We will patiently wait for a fix by a true professional. |
|
Works like a charm.
We will run this version until your next release. |
|
All right then, release 2.3.2 will be out soon I guess, I have a couple more of little updates to add and it'll be ready. Until then, if you have other bugs, don't hesitate. Thanks for the bug report @a1730 ! |
Describe the issue
Glewlwyd gives wrong diagnostics on missing data. ERROR: load_client_module_instance_list
To Reproduce
Install Glewlwyd using your favorite method.
Initialize sqlite3
sqlite3 $db < init.sqlite3.sqlTry to start Glewlwyd:
`2020-06-26T15:33:24Z - Glewlwyd INFO: Starting Glewlwyd SSO authentication service
2020-06-26T15:33:24Z - Glewlwyd ERROR: load_user_module_instance_list - Error module database not found
2020-06-26T15:33:24Z - Glewlwyd ERROR: load_client_module_instance_list - Error module database not found
Screenshots
N/A
System (please complete the following information):
cat /etc/os-release gives
Additional context
First, and most important, THANK YOU for this project. We hope PRs like this will help to strengthen the project.
Now, the interesting part is we are able to start Glewlwyd if we overlay init-core.sqlite3.sql
Resulting in >
2020-06-26T15:51:12Z - Glewlwyd INFO: Starting Glewlwyd SSO authentication service
2020-06-26T15:51:12Z - Glewlwyd INFO: Glewlwyd started on port 4593, prefix: api, secure: false, bind address: 192.168.0.77
However, one gets invalid credentials on initial admin login.
Do we still need to run init-core.sqlite3.sql? If not, what are we missing? strace does not show any missing library dependency.
Thanks again.
The text was updated successfully, but these errors were encountered: