Red Hat Bugzilla – Bug 712239
Timeout with yppush and iptables enabled pushing maps to NIS slave server
Last modified: 2012-10-08 03:30:06 EDT
Description of problem:
I'm running an NIS server, and have recently setup a slave. All works well except when I activate iptables on the master, the push to slave times out for each map being pushed.
I've already got both servers setup properly in /etc/sysconfig/network with YPXFRD_ARGS, YPSERV_ARGS and /etc/sysconfig/yppasswdd setup properly for ports to open. I also have /etc/sysconfig/nfs set for specifying ports. I have those ports open on iptables. All works fine except for the yppush call back (after a file is pushed to the slave, the slave "calls back" to the master for verification. The portmapper assigns a random port for process /usr/sbin/yppush each time. This makes it impossible to secure the master server with iptables.
There appears to be no config option anywhere in the folder /etc/sysconfig to specify a static port for yppush, instead it gets randomized each time yppush is launched (launched each time to copy a map, and listen for the call back).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Setup NIS Master & NIS Slave server as per RH KB-DOCS
2. Configure static ports in /etc/sysconfig/network (environment vars YPXFRD_ARGS and YPSERV_ARGS) with appropriate port numbers
3. Activate iptables with the ports specified in step 2 open.
4. After slave is initialized properly, configure NOPUSH to false in /var/yp/Makefile
5. On the Master, run command to force an update push to the slave server: cd /var/yp ; touch Makefile ; make (or push a specific map (any map) via: yppush -h SLAVESERVERHOSTNAME passwd.byname)
6. Maps will push to the slave server (viewable on the slave server via: ls -l /var/yp/NISDOMAINNAME/*), and the callback from the slave to verify transfer will fail with a timeout on the master (callback timed out)
Error message similar to: NISMAPNAME->NISSLAVESERVER: Callback timed out
(where NISMAPNAME is each nis map file and NISSLAVESERVER is the servername of the slave)
Push without timeout errors. Need an option allowable in /etc/sysconfig somewhere (either in /etc/sysconfig/network or perhaps /etc/sysconfig/yppush) that allows one to specify ports, just as in other yp programs like ypserv & ypxfrd.
The only workaround I've been able to accomplish is to change the line in /var/yp/Makefile from:
YPPUSH = $(YPSBINDIR)/yppush
YPPUSH = $(YPSBINDIR)/yppush --port 838
(838 is a port I have opened up in iptables on the master)
After making this change, the push to the slave is flawless and does not timeout.
(In reply to comment #0)
> The only workaround I've been able to accomplish is to change the line in
> /var/yp/Makefile from:
> YPPUSH = $(YPSBINDIR)/yppush
> YPPUSH = $(YPSBINDIR)/yppush --port 838
> (838 is a port I have opened up in iptables on the master)
> After making this change, the push to the slave is flawless and does not
This solution looks good and afaik it's the exactly way how others solve this issue. /var/yp/Makefile is a kind of config file, though a bit dubious (see bug #481780) and it is already not being replaced during update in RHEL-6 and Fedora).
So, from my point of view it is legitimate to change your Makefile to correspond with your objections, exactly as you did. What is probably a flaw is a missing comment about this possibility, so the best fix would be to add the following comment into this Makefile:
# yppush sends maps to slave servers and waits for their call-back on
# a random port selected by a portmap by default. It is possible to specify
# a fixed port as well as any other additional yppush arguments using
# variable YPPUSH_ARGS.
# e.g. YPPUSH_ARGS = --port 1002
..and then use this variable when running yppush:
-YPPUSH = $(YPSBINDIR)/yppush
+YPPUSH = $(YPSBINDIR)/yppush $(YPPUSH_ARGS)
The other way how to solve this issue is to parse a config file (like you suggest), but I'm not sure if it is necessary. I'll consult both solutions with upstream.
I've consulted this issue with upstream and there is no better way how to do this. Even implementing a new feature just for adding options to yppush would be overkill.
Please, consider your /var/yp/Makefile as a config file and feel free to adjust it if you need, while this is exactly what other do in your situation.
If you won't disagree I'm going to close this bug soon.
I will agree with the stipulation that the RH Knowledgebase docs (https://access.redhat.com/kb/docs/DOC-48333) be updated as to this information. I wasted 3 days figuring this out, delaying my project. Although I'm an RHCE, I'm not a developer/programmer.
This doc (https://access.redhat.com/kb/docs/DOC-9022) should also be updated since it contains port information for securing NIS, securing a server with iptables and having to specify ports is part of this problem/bug-report.
(In reply to comment #4)
> This doc (https://access.redhat.com/kb/docs/DOC-9022) should also be updated
> since it contains port information for securing NIS, securing a server with
> iptables and having to specify ports is part of this problem/bug-report.
Thanks for pointing me out, I've proposed to add a comment about how to add options to yppush in https://access.redhat.com/kb/docs/DOC-9022. It should be there in the foreseeable future.
A comment in /var/yp/Makefile has been added and yppush man page has been adjusted in Fedora:
Created attachment 504683 [details]
proposed patch that adjust man page for yppush
It would be also good to adjust man page in RHEL, but it doesn't make sense to change Makefile, which is not going to be updated during package update. So the attached patch adjusts only yppush man page.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
That problem is also/still present in recent versions of RHEL 6.
The fix stays the same (yppush --port xxx). I belive that the fix can be applied to the recent version of ypserv.