From owner-freebsd-current Thu Nov 14 12:47:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA04234 for current-outgoing; Thu, 14 Nov 1996 12:47:56 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA04203 for ; Thu, 14 Nov 1996 12:47:49 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id PAA27723; Thu, 14 Nov 1996 15:46:39 -0500 From: Bill Paul Message-Id: <199611142046.PAA27723@skynet.ctr.columbia.edu> Subject: Re: PLEASE HELP - PROBLEM WITH NIS To: dev@fgate.flevel.co.uk (Developer) Date: Thu, 14 Nov 1996 15:46:38 -0500 (EST) Cc: freebsd-current@FreeBSD.org In-Reply-To: from "Developer" at Nov 14, 96 03:25:54 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Developer had to walk into mine and say: > > Does anyone know how I can get NIS to work correctly? I have to manually > kill -HUP ypserv every time an NIS password is changed or the system still > thinks it is the old one -- ypcat returns the old password??? > > I am using FreeBSD 2.2 -- the yp stuff is compiled from -current. > > Any help would be very helpful. > > Regards, > > Trefor S. Please don't crosspost stuff like this to three different mailing lists when only one applies. (You say you're running -current, yet you also posted to the freebsd-stable and freebsd-chat groups.) You need to tell me a little more about how you have NIS configured. The rpc.yppasswdd server in 2.2 can do updates in one of two ways: the usual 'modify the master.passwd file and run a make to update the maps' way or the in-place update way. It defaults to the 'normal way' unless you start rpc.yppasswdd with the -i flag, in which case it switches to in-place updates. In either case, rpc.yppasswdd is supposed to spawn a child and call the /usr/libexec/yppwupdate script, which in turn runs a make using /var/yp/Makefile. If you are using the 'normal' update method, the script will run a normal 'make' which will generate a new set of master.passwd and passwd maps from the /var/yp/master.passwd file. This is done using the yp_mkdb command. Once the new map is ready, yp_mkdb is invoked again with the -c flag, which sends a YPPROC_CLEAR request to ypserv. This is equivalent to kill -HUP for the FreeBSD ypserv (I rigged it up this way on purpose -- other ypserv inplementations don't honor SIGHUP like this). The YPPROC_CLEAR message tells ypserv to flush out its DB handle cache and reopen all the map databases again; since ypserv caches open DB handles, it has to be told to flush its cache otherwise it will continue to serve stale data. When you use in-place updates, the /usr/libexec/yppwupdate script calls a special taeget in /var/yp/Makefile called 'pushpw'. This target skips the map regeneration step since it's not necessary in this case: when doing in-place updates, rpc.yppasswdd modifies the master.passwd and passwd maps directly. (This is much faster for sites with very large user databases.) However the pushpw target is still supposed to call yp_mkdb -c in order to tell ypserv to flush its cache. Note also that /usr/libexec/ypxfr will send a YPPROC_CLEAR message to the local ypserv itself as the result of a map transfer. This is so that NIS slave servers will also know when to flush their caches after a new map has been transfered from the master. What seems to be happening is that ypserv is not getting the YPPROC_CLEAR message. The thing now is to figure out why. There are a couple of possible reasons: - Somehow, yp_mkdb is broken. You can test this by running yp_mkdb -c manually. Start ypserv with the -d flag to see debug messages, then run yp_mkdb -c from another session; ypserv should tell you when the YPPROC_CLEAR message is received. - rpc.yppasswdd is not calling /usr/libexec/yppwupdate, or /usr/libexec/yppwupdate is barfing somehow. I have a theory. I could _swear_ that DBLOAD in /var/yp/Makefile is specified with an absolute path. But I may be wrong. In that case, edit /usr/libexec/yppwupdate and fix the PATH defined there so that it includes /usr/sbin, which is where yp_mkdb lives. Other things to try: Run ypserv in debug mode with -d and rpc.yppasswdd in verbose mode with -v and pay attention to the output you see (rpc.yppasswdd syslogs messages to /var/log/messages). Try to do a password change and see what happens. Look at /var/yp/ypupdate.log for incriminating error messages. If you find a reproducable problem or error message, let me know. -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 ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================