Re: How to refresh a map when using ypldap?
Ingo Schwarze wrote: 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 p...@. 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: vsan...@foretell.ca
Re: How to refresh a map when using ypldap?
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
Re: How to refresh a map when using ypldap?
Vijay Sankar wrote: When using ypldap, if I cd /var/yp make 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 updated netid yp_master: clnt_call: RPC: Can't decode result yp_master: clnt_call: RPC: Can't decode result yp_master: clnt_call: RPC: Can't decode result . . YP server for domain foretell not responding, still trying YP server for domain foretell not responding, still trying Rebooting seems to regenerate the maps. I am saying that because if I add a user to the LDAP database and do a getent passwd I do not see it listed. If I reboot the test system and do a getent passwd, I see the user I added to LDAP before the reboot. I tried yppoll as follows: # yppoll -d foretell -h 127.0.0.1 passwd yp_order: clnt_call: RPC: Procedure unavailable No such map passwd. Reason: Can't communicate with ypbind But ypbind is running and pf is off. # rpcinfo -p program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 142 udp806 ypserv 142 tcp 1009 ypserv 172 udp874 ypbind 172 tcp727 ypbind Are commands like yptest usable when ypldap is used instead of ypserv? What else can I use to figure out where I have made a mistake? I am unsure as to where to look for this type of information. When I try it, I get the following: # yptest Test 1: yp_match localhost hosts.byname yp error: No such map in server's domain Test 2: yp_first yp error: No such map in server's domain Test 3: yp_next Test 4: yp_master yp_master: clnt_call: RPC: Can't decode result yp_master: clnt_call: RPC: Can't decode result yp_master: clnt_call: RPC: Can't decode result Any clues or help will be much appreciated. Thanks very much, Vijay Also wanted to mention that killing ypldap and ypbind and then restarting them manually also allows me to see the new user. Avoids a reboot but I am still wondering whether that is the correct way to regenerate the maps. Thanks for any suggestions. -- Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited 59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6 Phone: (204) 885-9535, E-Mail: vsan...@foretell.ca
How to refresh a map when using ypldap?
When using ypldap, if I cd /var/yp make 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 updated netid yp_master: clnt_call: RPC: Can't decode result yp_master: clnt_call: RPC: Can't decode result yp_master: clnt_call: RPC: Can't decode result . . YP server for domain foretell not responding, still trying YP server for domain foretell not responding, still trying Rebooting seems to regenerate the maps. I am saying that because if I add a user to the LDAP database and do a getent passwd I do not see it listed. If I reboot the test system and do a getent passwd, I see the user I added to LDAP before the reboot. I tried yppoll as follows: # yppoll -d foretell -h 127.0.0.1 passwd yp_order: clnt_call: RPC: Procedure unavailable No such map passwd. Reason: Can't communicate with ypbind But ypbind is running and pf is off. # rpcinfo -p program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 142 udp806 ypserv 142 tcp 1009 ypserv 172 udp874 ypbind 172 tcp727 ypbind Are commands like yptest usable when ypldap is used instead of ypserv? What else can I use to figure out where I have made a mistake? I am unsure as to where to look for this type of information. When I try it, I get the following: # yptest Test 1: yp_match localhost hosts.byname yp error: No such map in server's domain Test 2: yp_first yp error: No such map in server's domain Test 3: yp_next Test 4: yp_master yp_master: clnt_call: RPC: Can't decode result yp_master: clnt_call: RPC: Can't decode result yp_master: clnt_call: RPC: Can't decode result Any clues or help will be much appreciated. Thanks very much, Vijay -- Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited 59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6 Phone: (204) 885-9535, E-Mail: vsan...@foretell.ca
