-
-
Notifications
You must be signed in to change notification settings - Fork 169
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
Error: This error results from an error during password verification #86
Comments
So it was sort of a permissions issue - originally I was getting a different error that lldap couldn't write to |
I see. And you didn't have issues with the I'll try to add a more explicit (and fatal) error if we can't write to the server key. |
No. The order of events was:
Then everything starts up just fine because it can create files in |
So now I'm trying to run it as a different user (via docker-compose
It's interesting because it says its loading the configuration, and it has permissions to read that file, but it's using what appears to be the default value for Edit: looks like the issue here is that |
This also explains the original error I was seeing - the problem is that |
I, too, am also stuck on the
thing (not just Tried like 50000 different things (including different directories and permissions) :/ |
And given how severe this issue is (it's preventing me from even spinning up the container in the first place) and given that nobody apparently complained about this before us, I'm guessing it's a somewhat recent regression. If that's the case, when would be the last "safe" image? |
@JaneJeon what you are describing seems like a configuration/permissions issue, not a container issue. Once I set proper write permissions on the data directory (e.g. I do think, though, that the way the container is set up is prone to confuse users because permissions handling is fairly opaque. It would probably be better overall to make it compatible with docker-compose |
As I have mentioned above, I have run those commands that you mentioned and it still doesn't work. I've ran it within the container and I thought maybe the issue is that I"m mounting the data directory from the outside (i.e. I'm mounting from a host folder to Either way, I'm ready to throw in the towel. I host like 7 different docker containers that I mount a host directory onto, and lldap seems to be the only one absolutely screeching at it. |
btw @nitnelave I'm pretty sure I found where the actual error message came from: https://docs.rs/opaque-ke/0.5.0/opaque_ke/errors/enum.ProtocolError.html#variant.VerificationError Dunno if it helps, but |
Is that the error message you're seeing? Your comment mentioned the other error. If you're getting the password verification error it's probably the same thing I saw - whatever you've put in the I also mount a host directory ( |
Okay, just checked again. I had generated a valid pem key but it looks like having any key in there triggers the error you mentioned above. Deleting it seems to work, but it's still... idk, quite dirty of a solution imho |
Yeah, I'm aware that the permissions stuff is not super well handled right now. I think I'll build on #89 and introduce better user support, including the docker-compose |
I'm happy to work on that next after we close #89! |
That would be of great help, thanks! |
So what linuxserver.io does in their containers, is create a user called You could do something similar here, though you don't have busybox But if we fix the initial server_key write bug, you could just use docker's built in user parameter. What I'd propose is to change the default for This way, the initial config can get written there no problem if you don't set the user, or if you set I did a quick test and it seems to work just fine, and by doing |
Rather than change the defaults in the source code, how about this: the start script checks if /data/lldap_config.toml exists, otherwise it creates it (copying from the template). That way we can make sure that the folder is writeable even before we start lldap. |
I think thats a good idea in general, but it doesnt quite solve the permissions problem. The problem is you're running the Maybe the "right" thing to do here is actually fix the "bug" - we don't actually want |
But... It does wait until the config is loaded. It's just that in the cases mentioned above, there was no (readable) config to load, so it reverted to the defaults. I think it's better to make sure there's a config, and if it's copied from the template it'll have the correct location for the server_key file |
I'm new to rust, so its very possible I'm reading the code wrong, but this is my understanding of configuration.rs
This creates the configuration, which starts with a call to The initial Macro: So the result is that After the defaults are loaded as described above, user-supplied values get merged in, and then there's another call to This lines up with the behavior I observed - the config file was properly mounted and readable just fine, but if i changed Please let me know if my rust understanding is off :D |
Don't sell yourself short, you're one up on me on this one :D
I'll fix that when i get the chance. |
Awesome! I bet that, along with maybe some more explicit info on permissions in the docs should solve most of the issues |
Just pushed a fix, feel free to try it, you can add |
This is fixed on my end. Thanks! |
If its not obvious by now I've been slowly trying to get this up and running all night XD
I'm now stuck on the following error:
Error: This error results from an error during password verification
Couldn't find that error text in the repo so I guess its a dependency? I'm wondering if it's a permissions problem because the image is built depending on being run as uid 10001
My compose file is:
and my config is
The text was updated successfully, but these errors were encountered: