Date: Sat, 28 Dec 1996 20:50:28 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: rlb@mindspring.com (Ron Bolin) Cc: current@freebsd.org Subject: Re: Todays Build 12-28 ypserv and libc depend ?? Message-ID: <199612290150.UAA27960@skynet.ctr.columbia.edu> In-Reply-To: <32C5C074.41C67EA6@mindspring.com> from "Ron Bolin" at Dec 28, 96 07:51:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Ron Bolin had to walk into mine and say: > This is a multi-part message in MIME format. > > --------------446B9B3D2781E494167EB0E7 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > In building todays current 12-28. I found that building usr.sbin/ypserv > required me to build and install libc b4 I could build ypserv. Is this > intentional, if so fine. Otherwise, under my configuration, I could not > complete a make world because ypserv depended on __dns_getanswer being > linked > and as far as I could see it was in libc, which had not been installed > yet. Yes, this is intentional. I know it sucks. The alternative is to chop out the part of the resolver code that ypserv now needs and duplicate it in the ypserv sources. This would require both sets of sources to be updated if a new BIND release is merged into the system. The reason that ypserv needs this __dns_getanswer() function is that it now supports async DNS lookups. ypserv will do a DNS lookup is a client searches the host.byname or hosts.byaddr maps for a non-local hostname or address, and the maps were built with the YP_INTERDOMAIN flag (or if ypserv was started with the -n flag). The problem is that DNS lookups can take a long time; this could cause ypserv to block for a long time waiting for the nameserver to respond, which in turn could cause other NIS clients to block, which sucks. The old solution for this was to fork() a child ypserv process to handle the lookup; this lets the parent proceed and handle other requests, but a fork() is expensive and if you have a lot of clients you can swamp the server. With the async resolver, ypserv assembles and transmits DNS requests itself using UDP and saves the request in a queue. It can then go back to what it was doing. When the reply arrives, it select() will notice the data pending on the resolver socket and process the reply. This way you don't block while waiting for DNS replies, and you don't have to fork(). However, once you get the reply datagram, you have to parse it into a hostent structure in order to do anything with it. There's a function called gethostanswer() in src/lib/libc/net/gethostbydns.c, but it's declared static which prevents other programs from calling it. I wanted to use gethostanswer() but I didn't want to duplicate the code, so I added a wrapper called __dns_getanswer() that could be used to call the gethostanswer() routine from ypserv. ypserv used to depend on __gethostbydnsname() and __gethostbydnsaddr() instead of __dns_getanswer(), but the former two functions were there long before I wrote ypserv so nobody noticed. > Once I did a cd lib;make install, then make world and ypserv linked fine > and the complete source tree finished the build. > > Seems odd to have to break out of the world and do a partial install. > Just checking sanity here and my configuration. Your configuration is fine. I'm not qualified to judge your sanity. Hell, I'm not even qualified to judge mine. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612290150.UAA27960>