https://github.com/lldap/lldap logo
Powered by
flyingfufu68 - Hello, I've installed succefully...
# troubleshooting
f
Hello, I've installed succefully LLDAP few days ago. Now looking to transfert info to _FILE variable. Unfortunately, I always get the following error ``> Starting lldap.. Loading configuration from /data/lldap_config.toml Error: Could not open /secrets/JWT_SECRET from config value jwt_secret_file: Permission denied (os error 13) in 
LLDAP_
environment variable(s) > Setup permissions.. Error: Could not open /secrets/JWT_SECRET from config value jwt_secret_file: Permission denied (os error 13) in 
LLDAP_
environment variable(s)``
a
message has been deleted
n
What's the variable definition and value?
f
Secrets have the correct permission (600) for the right user. Any idea what could be wrong ?
g
And the directory has 700?
f
In the compose: `` volumes: - /xxx/Lldap/data:/data - /xxx/Lldap/secrets:/secrets`` and in the .env : ``LLDAP_JWT_SECRET_FILE=/secrets/JWT_SECRET LLDAP_KEY_SEED_FILE=/secrets/KEY_SEED``
n
Ah, it's a bit confusing that the file is literally named JWT_SECRET 😄
If you run 
cat /secrets/jwt_secret
from inside the container, with the right user, does it work?
f
Had 600 for the folder. Changing to 700 resulted to the following : ``Error: The private key has changed. It used to come from KeySeed(EnvironmentVariable("`LLDAP_` environment variable(s)")), but now it comes from KeySeed(EnvironmentVariable("`LLDAP_` environment variable(s)")). Caused by: The private key encoding the passwords has changed since last successful startup. Changing the private key will invalidate all existing passwords. If you want to proceed, restart the server with the CLI arg --force-update-private-key=true or the env variable LLDAP_FORCE_UPDATE_PRIVATE_KEY=true. You probably also want --force-ldap-user-pass-reset / LLDAP_FORCE_LDAP_USER_PASS_RESET=true to reset the admin password to the value in the configuration.``
Guess it is not reading the content from the env _FILE the same way as when in the compose
n
Before I ask any more questions, what do you think of the error message? What do you think happened, and what should you do?
f
Guess it is not reading the content from the env _FILE the same way as when in the compose.
As I have only few users at this stage, will go through and reset the various password 😉
n
Wait
If you haven't changed the seed, it should work
Make sure you don't have a trailing newline in your file or something
f
Well, just xchecked again, and both have the exact same content, with not trailing space or new line...
I think it comes from having some special characters not read the same way in the compose as from the file.
n
So, before it was 
LLDAP_KEY_SEED=XXX
and now it's a file containing exactly "XXX"?
f
correct
n
You didn't have quotes or escape characters?
f
=XXX not ='XXX' to be precise
n
Hmm
Can you open an issue? I'd like to double-check and see if I can reproduce and understand what's happening
f
Sure, will do. I will then go back to the .env use instead of the secrets for some time, in case there is a quick fix possible 🙂
Already big thanks for the tip of checking the folder permission !
n
Thank @greven for that 😉
I just have it a try, and for the simplistic key seed of "abc" it worked
So it must be a question of special characters and how they're interpreted
Maybe in your docker compose, you can override the command/entrypoint to print the secret instead of running LLDAP? So you see how it's interpreted in the environment
f
``8fH9*k6e3T#qB5eMhys%6zG8TY^6sT6xnTYhJUsxEgfi#tZd2fsOeBKg7RTvS23&`` Here an exemple. I only replaced the Characters by others compare to the one I use. All special ones are the same, at the sampe position.
This is the JWT, I'll do the same in few seconds with the other one
n
I tried with 
abc*#%^&
and it worked as well
I didn't use a .env file and docker though
f
Here the KEY_SEED ``gTR!kP9ed7H!TlSv@WYH*u7zfF1KDySNhaocys9syc$mtsjf8ERST%&B3hexRmpgZ``
Still learning docker... right now, not sure how to do that. Any hint ?
n
Copy code
entrypoint: /bin/bash
command: -c 'cat /secrets/KEY_SEED'
Or something like that
f
So, here the results: The command show the correct value output for both KEY_SEED and JWT_SECRET.
However, if I have only the JWT_SECRET value passed over secrets, the server start good, but hang with the previous mentioned fault message as soon as I try to get the KEY_SEED one
n
Right, we don't check the consistency of JWT secrets, since they're temporary anyway. It just forces people to log back in
f
It seems it is something (a given characters or combination) in my KEY_SEED value that does not go through
n
And if you run 
cat -e the_key_seed_file
, you have a % at the end of the value?
f
No, get the exact value as in the KEY_SEED file. No % at the end
n
Ah, that's the thing: you do have a trailing newline
Try using 
echo -n 'KEY_SEED_VALUE' > key_seed_file
And see the difference it makes with 
cat -e
(or maybe it's all just a different shell setting; if your prompt is stuck on the same line after the display instead of on a newline, then you're already good. Though 
cat -e
should show a dollar if you have a newline? Idk)
Ah yeah, 
cat -e
shows a dollar if you have a trailing newline
So if you don't have a dollar at the end, you're good
f
struggling a bit here. Should I use it as a command ?
Sorry, for the silly question...
n
I don't think it's the issue, but I guess it's worth trying
Yeah, as a command, replace the value and the file with the actual values
f
get ``/bin/echo: /bin/echo: cannot execute binary file`` tried : ``command: echo -n 'real key seed value' > /secrets/KEY_SEED``. Is this correct ?
n
You can (should?) do that from outside
Oh, the secret is managed by docker
Duh
f
correct
n
Okay, as long as you confirm that from inside, 
cat -e /secrets/KEY_SEED
does NOT end with a $, we're good
Then I don't know, but it's still specific to your setup
If you go back to the env version, and you print the value from inside the container, do you get the same thing?
f
I do confirm. Nothing more at the end compare the the key value I've set in the file
yes
n
Then /shrug
If you manually put the value in a file, and mount that file in the container, and use that path as a key_seed_file, does it work?
f
Will try and post back the result
Tried and got the same result unfortunately.
PreviousNext
Powered by