Description of problem: In an attempt to use ypbind on a firewalled NIS client I tried forcing ypbind to listen on a pre-defined port so that I would know how to configure my firewall to exclusively allow incoming traffic on that port. According to the ypbind manual I'm supposed to use the -p option to tell ypbind which port number to use. I tried passing the '-p 833' option and ypbind seemed to use that number for a TCP port and a UDP port. However, it also opened a second UDP port which seemed to be randomly selected each time I ran ypbind. Unfortunately, I couldn't get my firewall to know which port to unlock and this completely prevented ypbind to bind to my organization's NIS server. Version-Release number of selected component (if applicable): ypbind.i386 3:1.20.4-6.fc9 How reproducible: Always Steps to Reproduce: 1. ypbind -p 833 2. netstat -natup|grep ypbind 3. pkill ypbind 4. ypbind -p 833 5. netstat -natup|grep ypbind Actual results: tcp 0 0 0.0.0.0:833 0.0.0.0:* LISTEN 21650/ypbind udp 0 0 0.0.0.0:833 0.0.0.0:* 21650/ypbind udp 0 0 0.0.0.0:634 0.0.0.0:* 21650/ypbind tcp 0 0 0.0.0.0:833 0.0.0.0:* LISTEN 21663/ypbind udp 0 0 0.0.0.0:647 0.0.0.0:* 21663/ypbind udp 0 0 0.0.0.0:833 0.0.0.0:* 21663/ypbind Expected results: I was expecting to see only one UDP port and such that its number what I requested with -p. Additional info: Having two UDP ports might be a design choice, but unless I can control which numbers they are set to, ypbind really can't be used on NIS clients with a firewall enabled. I guess the easiest solution would be to allow users to select the second UDP port's number too.
If you issue the netstat command from time to time for a longer period, you'll see that the 'third' udp port changes over time. I *think* this is used as originating port for pinging servers, so I'm not sure how relevant its number is for configuring the firewall.
I haven't noticed that it changes, and it's depressing to know that it does. I verified that ypbind is able to bind to the NIS server only when I open ports 833 _and_ that random port. Whatever that port is used for, it totally makes NIS unusable if a firewall is turned on. I wish I could find some documentation about this port. If you really want, I could show the relevant firewall config and ypbind output.
# #netconfsoapbeep is the same as port 833 # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:netconfsoapbeep ACCEPT udp -- anywhere anywhere state NEW udp dpt:netconfsoapbeep REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination # ypbind -debug -p 833 4806: parsing config file 4806: Trying entry: domain my.domain.com broadcast 4806: parsed domain 'my.domain.com' broadcast 4806: add_server() domain: my.domain.com, broadcast 4806: [Welcome to ypbind-mt, version 1.20.4] 4806: ping interval is 20 seconds 4808: NetworkManager is not running. 4809: do_broadcast() for domain 'my.domain.com' is called 4809: broadcast: RPC: Timed out. 4809: leave do_broadcast() for domain 'my.domain.com' ^C4807: Signal (2) for quitting program arrived. # # while do_broadcast() was running I saw this: # netstat -natup|grep ypbind tcp 0 0 0.0.0.0:833 0.0.0.0:* LISTEN 4806/ypbind udp 0 0 0.0.0.0:43540 0.0.0.0:* 4806/ypbind udp 0 0 0.0.0.0:833 0.0.0.0:* 4806/ypbind # after leave do_broadcast() happened I saw this: [root@dynamic-25 ~]# netstat -natup|grep ypbind tcp 0 0 0.0.0.0:833 0.0.0.0:* LISTEN 4806/ypbind udp 0 0 0.0.0.0:833 0.0.0.0:* 4806/ypbind All of means that I wasn't able to connect to my NIS server while the firewall was turned on.
# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # ypbind -debug -p 833 5084: parsing config file 5084: Trying entry: domain my.domain.com broadcast 5084: parsed domain 'my.domain.com' broadcast 5084: add_server() domain: my.domain.com, broadcast 5084: [Welcome to ypbind-mt, version 1.20.4] 5084: ping interval is 20 seconds 5086: NetworkManager is not running. 5087: do_broadcast() for domain 'my.domain.com' is called 5087: Answer for domain 'my.domain.com' from server 'keyserver.my.domain.com' 5087: leave do_broadcast() for domain 'my.domain.com' # # in a different terminal, right after leave do_broadcast(): # netstat -natup|grep ypbind tcp 0 0 0.0.0.0:833 0.0.0.0:* LISTEN 5084/ypbind udp 0 0 0.0.0.0:833 0.0.0.0:* 5084/ypbind udp 0 0 0.0.0.0:604 0.0.0.0:* 5084/ypbind # # and a minute later: # netstat -natup|grep ypbind tcp 0 0 0.0.0.0:833 0.0.0.0:* LISTEN 5084/ypbind udp 0 0 0.0.0.0:833 0.0.0.0:* 5084/ypbind udp 0 0 0.0.0.0:606 0.0.0.0:* 5084/ypbind This shows that ypbind is able to connect to my NIS server if the firewall is completely turned off. It also confirms that the random UDP port number is changing over time.
In my trials I noticed that ypbind is able to get an "Answer for domain" if it accidentally starts listening on an open UDP port, but this is obviously not an acceptable solution because the timeout delays are long and the chances of hitting an open port are low. While ypbind is waiting for an answer the client machine becomes severely limited in functionality because things UID lookups don't return for prolonged periods of time. As a specific example, I have to wait for ypbind to work before a new terminal emulator can open.
(In reply to comment #1) > I *think* this is used as originating port for pinging servers, so I'm not sure > how relevant its number is for configuring the firewall. That's true. The second port is used for pinging servers and which port is used is up to RPC manager (called rpcbind now, portmap before). -p port option is useful only when you need access ypbind service from hosts on the network.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is still a problem in ypbind-1.20.4-19.fc11.i586.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.