Hi Vijay,
Vijay Sankar wrote on Sun, Apr 25, 2010 at 09:31:14AM -0500:
When using ypldap, if I
cd /var/yp
make
Executing Makefile.yp(8) will generate YP maps from static files.
There is no way how that could fetch information from LDAP.
So i do not think you want to update your maps in this way
when using ypldap(8).
I am not able to regenerate the YP maps and can't figure out what
I am doing wrong. Here is what I get
# cd /var/yp
# make
===> foretell
couldn't find /etc/ethers
Again, here you see that your command is trying to build maps
from files in /etc. Is that what you want?
updated netid
yp_master: clnt_call: RPC: Can't decode result
Judging from /usr/src/usr.sbin/ypserv/ypinit/Makefile.yp,
the command being executed here is probably
/usr/sbin/yppush -d foretell netid.byname
Judging from /usr/src/usr.sbin/ypserv/yppush/yppush.c,
that program is trying to call
yp_master(Domain, ypmap, &master);
In case of ypldap(8), the call yp_master(3) doesn't appear to
make much sense. After all, logically, there is no YP master
server, instead, the LDAP server is kind of a master. So i guess
Pierre-Yves did not implement support for that call in ypldap(8) -
though i did not explicitely check the source.
Besides, yppush(8) does not make much sense in the ypldap(8)
context. You want to pull from LDAP, not manually push some map
onto the server.
Rebooting seems to regenerate the maps.
Of course, because the ypldap(8) server restarts, so it can't
help loading new maps from LDAP.
I tried yppoll as follows:
# yppoll -d foretell -h 127.0.0.1 passwd
yp_order: clnt_call: RPC: Procedure unavailable
Looks like ypldap(8) does not implement yp_order(3) - again,
i did not check the source. Perhaps it doesn't make much sense.
Are you sure LDAP has a concept of YP version numbers in the
first place? Otherwise, it can't tell you...
No such map passwd. Reason: Can't communicate with ypbind
But ypbind is running and pf is off.
Oh well, don't get me started on RPC and YP error messages.
Frankly, that's not the best part of error messages in OpenBSD.
Last year, i did tiny bits of cleanup near the edges of that
heap of *, but unfortunately, it is a large heap and probably
won't be cleaned up fully this decade.
The problem is that the the very design of SUN RPC error messages
is questionable at best, but changing it today is not easy.
You don't want to break interfaces without a good reason.
Basically, YPERR_YPBIND (see /usr/src/lib/libc/yp/yperr_string.c)
can happen when... something went wrong. So the second message
you are seeing is less important than the first one.
Are commands like yptest usable when ypldap is used instead of
ypserv?
Oh, unlike ypldap(8), yptest(8) is not rocket science.
It is just a straightforward hack to issue a few YP client calls.
When you have an uncommon setup, typically part of it will work
and part of it won't. Count ypldap(8) as one particular example
of an uncommon YP setup.
# yptest
[...]
Test 4: yp_master
yp_master: clnt_call: RPC: Can't decode result
Here you see again that yp_master(3) doesn't appear to be supported
by ypldap(8).
Also wanted to mention that killing ypldap and ypbind and then
restarting them manually also allows me to see the new user.
Sure, restarting ypldap(8) will certainly reload the maps from LDAP,
how else could the new daemon get at them?
Restarting ypbind(8) almost certainly has nothing to do with it.
According to the ypldap.conf(5) manual, you can specify in the
configuration file how often ypldap(8) shall pull the directory
from LDAP. The relevant function for pulling the maps appears
to be client_configure() in /usr/src/usr.sbin/ypldap/ldapclient.c.
My impression is that it is only called on startup and then
periodically, and you can't trigger it manually.
In /usr/src/usr.sbin/ypldap/ypldap.c, SIGHUP appears to be
ignored, even though comments indicate there were plans to
implement it.
Thus, i guess your options are
- wait for the next periodic update
- or kill and restart ypldap(8) in case you are impatient
Oh, and in case Pierre-Yves speaks up, listen to him, not to me. ;-)
Yours,
Ingo
