I can configure ypldap.conf in the fairly obvious way, so that
Of course, NIS is a little bit slippery (all those port and domain shenanigans), so I'm not 100% sure I'm making a correct test, nor what the precise nature is, of the 'NIS lookups fail', but it is looking as if ypldap isn't behaving as expected. Now, ypldap isn't what you'd call chatty in its logs, so I can't see any obvious evidence of failures, and the server doesn't crash, or do anything as entertaining/debuggable, so I'm a bit stuck, short of hacking a custom version which chatters in a got-here way to its logs.
(Why am I doing this? I'm helping a colleague move away from NIS, and volunteered to make a custom ypldap which would produce a modified (linux-friendly) passwd line, which I was rather looking forward to sharing. So I'm OK poking around inside the code, but don't really want to go too close to the main event loop. Also, my NIS-debugging skillz have somewhat atrophied in the last couple of decades, which I'm not unhappy about.)
A separate odd thing is that the
That seems to include a dependency on ypserv, but as the ypldap(8) manpage very intelligibly notes, 'ypldap has the same role as ypserv(8) and the two daemons are exclusive.' So there's something else funny going on here.
I note that ypldap has (unsurprisingly) seen very little real development work in the last few years, and probably also rather little actual use, so I'm guessing a change in one or other base version has broken something here. But that might have been a while ago, since the only online commentary I can find is at [1], from 2016, which seems to be reporting similar behaviour.
Any ideas?
Norman
[1] https://groups.google.com/g/muc.lists.freebsd.stable/c/nO0NMaSbD7o
ypldap -dv works, in the sense that I can do expected NIS lookups against it, manifestly getting data from my LDAP server, and I see all sorts of reassuring chatter as it does its work. Hooray, etc. But when I relaunch the server the normal way, so that it daemonises, the same NIS lookups fail.Of course, NIS is a little bit slippery (all those port and domain shenanigans), so I'm not 100% sure I'm making a correct test, nor what the precise nature is, of the 'NIS lookups fail', but it is looking as if ypldap isn't behaving as expected. Now, ypldap isn't what you'd call chatty in its logs, so I can't see any obvious evidence of failures, and the server doesn't crash, or do anything as entertaining/debuggable, so I'm a bit stuck, short of hacking a custom version which chatters in a got-here way to its logs.
(Why am I doing this? I'm helping a colleague move away from NIS, and volunteered to make a custom ypldap which would produce a modified (linux-friendly) passwd line, which I was rather looking forward to sharing. So I'm OK poking around inside the code, but don't really want to go too close to the main event loop. Also, my NIS-debugging skillz have somewhat atrophied in the last couple of decades, which I'm not unhappy about.)
A separate odd thing is that the
/etc/rc.d/ypldap script includes
Code:
ypldap_precmd()
{
force_depend ypserv nis_server || return 1
}That seems to include a dependency on ypserv, but as the ypldap(8) manpage very intelligibly notes, 'ypldap has the same role as ypserv(8) and the two daemons are exclusive.' So there's something else funny going on here.
I note that ypldap has (unsurprisingly) seen very little real development work in the last few years, and probably also rather little actual use, so I'm guessing a change in one or other base version has broken something here. But that might have been a while ago, since the only online commentary I can find is at [1], from 2016, which seems to be reporting similar behaviour.
Any ideas?
Norman
[1] https://groups.google.com/g/muc.lists.freebsd.stable/c/nO0NMaSbD7o