https://github.com/lldap/lldap logo
Powered by
Vegard Hagen - I'm running LLDAP in a Pod in Ku...
# troubleshooting
v
I'm running LLDAP in a Pod in Kubernetes with an 
emptyDir
mounted as the 
/data
folder ([link to Deployment](https://github.com/vehagn/homelab/blob/main/k8s/infra/auth/lldap/deployment.yaml)). From what I undestand the 
key_seed
is randomly generated each time LLDAP start, but since I only use ephemeral storage I suppose this key isn't saved anywhere? I assume the only reason why it's working is that I use the bootstrap script to (re-)generate the passwords upon each restart. Should I explicitly set the 
LLDAP_KEY_SEED
value?
a
message has been deleted
j
Yes, you should set that (I think that's the one). There's also a JWT related seed, that you probably want to set as well.
v
Thanks. I'm already setting the JWT-secret.
I suppose I got confused by the wording in the 
lldap_config.docker_template.toml
file > Randomly generated on first run if it doesn't exist. and the fact that it's not configured in Evantage-WS' [example deployment](https://github.com/Evantage-WS/lldap-kubernetes/blob/main/lldap-deployment.yaml).
Just want to make sure I don't say anything too wrong in [an article I'm writing](https://gitlab.com/vehagn/blog/-/tree/ldap/content/articles/2025/01/lldap) 🙂
j
They might not have tried restarting yet 🙂 I'm pretty sure you need it to be able to read stored passwords on redeployment.
n
I would really encourage the key seed over the file, it's just more flexible
v
Since I'm running a [bootstrap-job](https://github.com/vehagn/homelab/blob/main/k8s/infra/auth/lldap/bootstrap.yaml#L16) on each reset the passwords are regenerated using the new seed. But if I add a new user and restart it I think that would break that new user's password.
n
Yep
That's why the key seed is more portable, especially for a HA setup
With that (and a separate db like postgres) you don't need state and can have multiple concurrent LLDAP instances
v
Cool! So LLDAP handles concurrent writes to the db?
n
The DB itself handles that
LLDAP properly uses transactions if that's what you mean
j
and LLDAP doesn't retain any state in-memory, so two instances can cooperate just fine with a postgres DB
v
Nice, that's what I hoped for
n
While we're here, a note on the article: it's possible but computationally expensive to brute force the passwords -> computationally prohibitive maybe?
v
Though I don't really need it for my homelab setup
I'll make a note to change it, thanks!
PreviousNext
Powered by