Ingo Schwarze wrote:
quoted text
> 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
> 

Thank you very much for the detailed reply and your thoughts on this as 
well as for pointing out the ypldap.conf settings for interval. Setting 
the interval to 30 instead of the 3600 I had in ypldap.conf makes this 
very usable.

Can't believe what a great idea this is! Thank you aschrijver@ and pyr@.

Thanks again Ingo,

Vijay



-- 
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6
Phone: (204) 885-9535, E-Mail: vsankar@foretell.ca