mirror of
https://github.com/lldap/lldap.git
synced 2026-04-26 00:36:01 +03:00
[GH-ISSUE #371] Unable to log in after bootstrapping #144
Labels
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lldap-lldap#144
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ViViDboarder on GitHub (Nov 15, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/371
I've been debugging this for a while and hitting a dead end. I can't tell if I'm just missing something or what.
I saw some other user had issues due to it loading the wrong file initially and creating the admin user, so I moved my admin user to environment variables. I've set the following:
When I look in my logs I see that the config is understood when it prints out my configuration. I can also see it set up the rest of the server:
So it looks like it's created the user just fine. I can also verify this and the user shows up in the sqlite database.
When I try to log in, I get an error message saying the user or password is incorrect and the following in my logs:
Any ideas how I can debug further?
@nitnelave commented on GitHub (Nov 15, 2022):
The admin password is only used when creating the admin user for the first time. My guess is that you ran the server a first time with a (potentially default) password, the admin was created with this password, and then you changed it in the config: that doesn't change the admin password. If you haven't done anything else (creating users and so on), the simplest is to just delete the database and restart the server. That'll create the admin password with the right password.
@ViViDboarder commented on GitHub (Nov 15, 2022):
No. I've been deleting the whole data dir every time I've tried and verified that it creates the user with (I'm assuming) the password provided at user creation.
@ViViDboarder commented on GitHub (Nov 15, 2022):
Oh. Interesting... When I connect over ldap I see more logs:
So maybe the user has no password.
@ViViDboarder commented on GitHub (Nov 15, 2022):
When I query the database with sqlite, the password hash seems to be blank. The user even shows up if I query
select * from users where password_hash is null;@ViViDboarder commented on GitHub (Nov 15, 2022):
One strange thing I'm noticing on startup is that, after cleaning out the data dir and starting again the logs show:
So it looks like it starts twice?
Looking at
main.rsfor the sever, it seems to be creating the user, but failing to set the password, crashing, and then restarting, finding the user (not checking the password), then not-finding the groups (because it crashed at pass assigment) and creating them in the second go.I'm not sure why there is no error or anything on stdout or stderr for what appears to be a crash.
@ViViDboarder commented on GitHub (Nov 15, 2022):
Though I'm not sure why I never see
warn!("Could not get admin user, trying to create it: {:#}", e);shown anywhere in my logs either as it seems like it should be logged right before the creation.@ViViDboarder commented on GitHub (Nov 15, 2022):
Ok, figured it out! Looks like it was getting killed by my scheduler due to OOM. That explains the abrupt cutoff in my logs with no stack trace.
I figured it out by
execing into the container, deleting the data, and running the entrypoint. There it ended withKilled. Only then, my scheduler showed an OOM event!Increased the memory and it's good.
@nitnelave commented on GitHub (Nov 15, 2022):
Ah, yes, the "password hashing" process is quite memory intensive (and CPU
intensive as well). It's intentional in order to make brute force attacks
impractical in case the server gets hacked and the DB leaks.
On Tue, 15 Nov 2022, 22:24 Ian, @.***> wrote: