pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-systemd
hmpffff_ has joined #nixos-systemd
hmpffff has quit [Ping timeout: 256 seconds]
andi- has quit [Ping timeout: 272 seconds]
andi- has joined #nixos-systemd
hexa- has quit [Quit: WeeChat 2.7.1]
hexa- has joined #nixos-systemd
hexa- has quit [Client Quit]
hexa- has joined #nixos-systemd
hexa- has quit [Client Quit]
hexa- has joined #nixos-systemd
hmpffff_ has quit [Quit: Bye…]
hmpffff has joined #nixos-systemd
<Mic92> aanderse: I don't think that would solve your issue.
<Mic92> Are users not created before that?
<Mic92> Or does network manager depends on nslcd as well?
<aanderse> running on a server with no network manager....
<Mic92> how do you depend on ldap for tmpfiles?
<Mic92> I would rather not want to make more services depending on network. It's a broken concept anyway
<Mic92> What if your network goes down right after that.
<Mic92> Or if your ldap server is down
<Mic92> I would be better if your service running tmpfiles would retry if it cannot reach ldap
<Mic92> And not force this dependency on others that don't use ldap because it makes things slow.
<aanderse> hmm not sure i understand the point about ldap making other stuff slow for users who aren't using ldap
<aanderse> if the nslcd service wants/after network-online.target that would only have any impact if people are using ldap
<Mic92> aanderse: nslcd would be only usable once network manager/systemd networkd have at least one connection up.
<Mic92> And we need nslcd for many things.
<aanderse> but nslcd is only usable once the network is up, is it not?
<Mic92> hold on. I mixed it up with nscd
<aanderse> oh, yes, not nscd
<Mic92> Ok. Forget about it.
<aanderse> that would be an insane change :D
<aanderse> Mic92: for the record i'm not 100% sure i'm correct on this, but it seems logical to me
<Mic92> aanderse: I don't have any ldap shell logins configured right now.
<aanderse> so i'm happy to talk this through and close the PR if you don't agree
<aanderse> yeah well ldap shell logins work fine the way it is
<aanderse> so i'm doing something pretty dirty... promise not to poke me too hard about it :)
<aanderse> it was the "best" solution i could get people at my workplace to agree on
<Mic92> So what happens if you don't have this dependency in?
<aanderse> i setup some phpfpm pools running as an actual user on dev boxes
<aanderse> that way people can ssh into the server and do all their dev work, gets served over the web
<aanderse> works well for them with vscode remote ssh server stuff
<aanderse> but all these users are using ldap accounts
<aanderse> so when phpfpm starts ... it starts before ldap users exist, then it fails
<aanderse> i thought it would be nice to simply add an after nslcd.service to fix this
<aanderse> that doesn't consistently work... sometimes the ldap user exists, sometimes not
<aanderse> viewing log files
<aanderse> i can see when this fails that nslcd doesn't have a network connection yet, because network-online.target hasn't been reached yet
<Mic92> Does maybe nscd kills the request earlier?
<aanderse> nslcd.service is useless without a network connection so it made sense to me to make it depend on that explicitly in systemd
<aanderse> there are a number of ways for me to solve this problem
<aanderse> phpfpm pools could be set to restart on fail with a 1s delay
<aanderse> i could add the after network-online.target and nslcd.service to phpfpm pools
<Mic92> It might be useless, but it would be also interesting to fix the root cause.
<Mic92> Because than it also works in the failure case
<aanderse> so the ldap here used to be real flakey
<Mic92> If your ldap is flaky but your local dhcp is fine, this fix won't help you.
<aanderse> the load balancer folks fixed that a few months ago, n omore problems
<aanderse> but back when ldap was flakey... i never had user login problems
<aanderse> i checked logs
<aanderse> and nslcd would try again automatically
<aanderse> it was able to run multiple attempts and eventually succeed
<aanderse> so i never had any complaints from users about logging in
<aanderse> i'm left with the assumption there is no big underlying problem
<Mic92> ok. So it fails if it cannot find a route to the ldap server?
<Mic92> Or if it cannot resolve the hostname?
<aanderse> not exactly sure, i never investigated the problem too deeply
<Mic92> I agree for the majority `wants = [ "network-online.target" ];` is fine, just some smaller setups won't need it when the server is running on the same box.
<aanderse> hmm i suppose that is a use case for some people
<aanderse> (btw i'm not using slapd)
<aanderse> Mic92: every time you paste a link its the same link to my PR....
<Mic92> aanderse: I embedded a diff in it.
<Mic92> aanderse: there is an option called policy = "hard_init";
<aanderse> i haven't tried hard_init
<aanderse> ok, i think you've convinced me this doesn't provide enough generic value
<Mic92> aanderse: if hard_init fixes it though, we can document it better.
<Mic92> I would not make the default. I think some people might want to have it degrade.
<aanderse> yeah that makes sense
<aanderse> thanks for talking this through with me then :)
<Mic92> aanderse: you might want to test if you can still log in as root if your ldap server is down.
<aanderse> Mic92: only developer accounts are using ldap
<aanderse> no sysadmin accounts
<aanderse> sysadmin accounts managed via nixops
<aanderse> sysadmin turnover is very low, so not a big win to manage via ldap
<Mic92> aanderse: ok. just make sure your root login does not perform any user queries.
<Mic92> looking up root should be still fine.
<aanderse> by default nixos configuration won't cache passwords with nslcd so not appropriate for that type of account
<Mic92> because passwd is a higher priority
<aanderse> easy enough to pull the virtual network plug and concretely test...
<aanderse> i think sssd has easy ability to cache passwords and do networkless logins for ldap accounts, but i didn't end up going down that path (seemed more involved)
<Mic92> Yeah, sssd had some issues on NixOS if I recall correctly
<aanderse> :(
<aanderse> ok, well, just to be completely sure
<aanderse> i yanked the networking on a machine
<aanderse> logged in as local users (including root)
<aanderse> no issues
<aanderse> everything picked up when network plugged back in
<aanderse> all good
<aanderse> will try to find some time/energy to try hard_init today
<Mic92> ok. If it works we can update the ldap module option
<Mic92> description
hmpffff has quit [Read error: Connection reset by peer]
hmpffff has joined #nixos-systemd
hmpffff has quit [Quit: nchrrrr…]
hmpffff has joined #nixos-systemd
globin_ has quit [Ping timeout: 260 seconds]
globin_ has joined #nixos-systemd