Hello,
I have been spending days with tech support on this one, and nobody seems to have a clue. This is the first time I post on this list so please excuse me for any mistake contained within this message. I searched the archives of the list but did not find anything related to this problem.
I have an F740 running 5.3.4R3. The box is not yet in production because of an annoying problem regarding NIS (also known as Yellow Page). My NIS server is a Linux box running Debian 2.1 with the kernel 2.2.14 and Portmap version 5.
I must say that the dns resolution on the filer works, that I am able to mount shares from any clients in my class C (including the NIS server) and of course I can ping the filer from the NIS server and I can ping the NIS server from the filer. This makes me believe that the network part of it is fine.
The problem is the following : the Filer does not have access to the maps when a single server is specified in the option nis.servers. It works with a lot of garbage in the logs when I specify server,* in this same option.
Just in case it helps when reading the logs, my NIS server is named "aux" (ip : 192.168.1.152). The F740 is named "filer" (ip : 192.168.1.240). I took out the dates and time to make it easier to read.
--------------------
First Scenario : options nis.servers my_nis_server
Message on the filer : [nis_poll]: NIS server(s) not available
Message on the NIS server : (repeated every minute or so) aux portmap[14166]: connect from 192.168.1.240 to callit(ypserv): request not forwarded
'ypcat group' on the filer : No such map group.byname. Reason: Local resource allocation failure
Conclusion : it does not work :(
------------------
Second Scenario : options nis.servers my_nis_server,*
Message on the filer : [nis_poll]: Bound to preferred NIS server 192.168.1.152 [nis_grp_updater]: Local NIS group update successful.
(and the following every two minutes or so) [nis_main]: Preferred NIS Server 192.168.1.152 not responding [nis_main]: NIS server(s) not available [nis_poll]: Bound to preferred NIS server 192.168.1.152
Message on the NIS server : (every minute or so) aux portmap[14223]: connect from 192.168.1.240 to callit(ypserv): request not forwarded
'ypcat group' on the filer : Print the proper groups from the NIS map. Works to with ypcat passwd and ypcat hosts.
Conclusion : it works, sort of.
-------------------
So what exactly is happening? I have an explanation, but I am IN NO WAY SURE THAT IT IS THE CORRECT ONE. It just seemed to me that it would be the more possible one. I must say that I am in no way an NIS expert but I know Linux pretty well. All this to say that yes, the hosts.allow - hosts.deny and other yp.securenets are set correctly.
I think the problem comes from the portmap security scheme. I looked into portmap source code and found this in pmap_check.c :
/* * pmap_check - additional portmap security. [Stuff deleted] * Refuse to forward requests to NIS (YP) daemons; The only exception is the * YPPROC_DOMAIN_NONACK broadcast rpc call that is used to establish initial * contact with the NIS server. [More stuff deleted] */
line 89 :
#define log_no_forward(addr, proc, prog) \ logit(deny_severity, addr, proc, prog, ": request not forwarded")
line 200 (the actual check_callit function) :
check_callit(addr, proc, prog, aproc) struct sockaddr_in *addr; u_long proc; u_long prog; u_long aproc; { #ifdef HOSTS_ACCESS if (!(from_local(addr) || good_client(addr))) { log_bad_host(addr, proc, prog); return (FALSE); } #endif if (prog == PMAPPROG || prog == NFSPROG || prog == YPXPROG || (prog == MOUNTPROG && aproc == MOUNTPROC_MNT) || (prog == YPPROG && aproc != YPPROC_DOMAIN_NONACK)) { log_no_forward(addr, proc, prog); return (FALSE); } if (verboselog) log_client(addr, proc, prog); return (TRUE); }
I think it nails exactly where the problem is coming from. The Filer is sending a forward request and gets denied. Why does the filer do that after the broadcast, I don't know. I am not sure if the problem comes from the filer or from my portmap implementation on my NIS server (or even my server itsef).
I do really hope someone out there has a clue. Thank you for reading this and I hope to get an answer soon.
Haim.