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.
I'm not an NIS expert either, but the forward request could be being generated because the filer is trying to talk to an NIS server that is not in it's subnet.
Are 192.168.1.152 and 192.168.1.240 on the same subnet? Do they both agree on the netmask for the network? (Remember that netmasks can be served via NIS as well.)
Bruce
I'm not an NIS expert either, but the forward request could be being generated because the filer is trying to talk to an NIS server that is not in it's subnet.
They are on the same subnet. We use a /21 (6 class C in superneting) also known as 255.255.248.0.
Are 192.168.1.152 and 192.168.1.240 on the same subnet? Do they both agree on the netmask for the network? (Remember that netmasks can be served via NIS as well.)
They have the same netmask. Let me make sure .... yes they do :) We don't use NIS to submit the netmask, all servers have their IP/Netmask configured properly.
Thank you for you point. Any other idea?
Bruce
Haim.
On Tue, May 09, 2000 at 02:34:24AM -0400, Haim Dimermanas wrote:
They have the same netmask. Let me make sure .... yes they do :) We don't use NIS to submit the netmask, all servers have their IP/Netmask configured properly.
It sounds as if you're using Wietse Venema's secure portmapper or the BSD portmapper (I'm not sure if includes Venema's changes, but it behaves similarly). Netapps and other simple NIS clients (including some stock Unix NIS clients) can't handle the secure portmapper. The port forwarding is disabled because a forwarded connection appears to the receiving RPC daemon to have come from the local host, which thwarts host-based access control.
I don't know how to turn that behavior off, though. I have heard it is possible (and short of actually changing the code) but I haven't actually spoken to anyone who has succeeded. It's probably not worth it anyway; you probably don't want to weaken security, and the filer works better with local files. Just add dumping the maps to the filer to the yp make process.
I would be interested to hear how to disable security on the portmapper, though.
ejt
It sounds as if you're using Wietse Venema's secure portmapper or the BSD portmapper (I'm not sure if includes Venema's changes, but it behaves similarly). Netapps and other simple NIS clients (including some stock Unix NIS clients) can't handle the secure portmapper. The port forwarding is disabled because a forwarded connection appears to the receiving RPC daemon to have come from the local host, which thwarts host-based access control.
That's exactly the kind of answer I was hoping for :) Seriously ... now I know that I am not (that) crazy :)
I don't know how to turn that behavior off, though. I have heard it is possible (and short of actually changing the code) but I haven't actually spoken to anyone who has succeeded. It's probably not worth it anyway; you probably don't want to weaken security, and the filer works better with local files. Just add dumping the maps to the filer to the yp make process.
I don't want to weaken something that is already pretty weak. RPC's are known for their security issues, and the portmapper sure helps. Dumping the maps to the filer is very tempting, and I might do that. I am going to need some explanations on where to put them and what the catch is (if any). I would appreciate you explain a little bit more what you meant by that.
I would be interested to hear how to disable security on the portmapper, though.
Just modify the callit function in pmap_check.c as follow :
line 200 or so (the actual check_callit function) :
BEFORE :
if (prog == PMAPPROG || prog == NFSPROG || prog == YPXPROG || (prog == MOUNTPROG && aproc == MOUNTPROC_MNT) || (prog == YPPROG && aproc != YPPROC_DOMAIN_NONACK)) {
AFTER :
if (prog == PMAPPROG || prog == NFSPROG || prog == YPXPROG || (prog == MOUNTPROG && aproc == MOUNTPROC_MNT) {
Sorry I don't use diff, but the idea is here. I did not compiled, tried, test this, but to the best of my knowledge it should work (you just remove one check after all).
ejt
Thanks again. Haim.
The reason why I didn't think this was the case, though, was that I'm pretty sure I've implemented the secure portmapper on Solaris, and never had this problem. Does the current version of Solaris not use the secure portmapper?
Bruce
They are on the same subnet, they have the same netmask. We use a /21 (255.255.248.0) to do superneting over 6 classes C.
Bruce Sterling Woodcock wrote:
I'm not an NIS expert either, but the forward request could be being generated because the filer is trying to talk to an NIS server that is not in it's subnet.
Are 192.168.1.152 and 192.168.1.240 on the same subnet? Do they both agree on the netmask for the network? (Remember that netmasks can be served via NIS as well.)
Bruce
-
Bruce Sterling Woodcock -
Ethan Torretta -
Haim Dimermanas