Bug 125344 - ypbind problems with Solaris ypserv
ypbind problems with Solaris ypserv
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: ypbind (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Feist
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-04 18:00 EDT by Mike Cooper
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-07 12:43:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike Cooper 2004-06-04 18:00:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Description of problem:
ypbind is very flakey when it tries to bind to a ypserv running on
Solaris 8 SPARC.

ypbind -broadcast does not work at all.  ypbind fails to ever bind to
a server.  The server is a Solaris 8 SPARC system with the latest
ypserv patch 109328-03 from Sun.  When running "ypbind -broadcast
-debug" I see:

[root@localhost root]# ypbind -debug -broadcast
add_server() domain: reshape.com, broadcast
[Welcome to ypbind-mt, version 1.17.2]
  
do_broadcast() for domain 'reshape.com' is called
ypbindproc_domain_2_svc (reshape.com)
Pinging all active server.
broadcast: RPC: Timed out.
leave do_broadcast() for domain 'reshape.com'
do_broadcast() for domain 'reshape.com' is called
Pinging all active server.
broadcast: RPC: Timed out.
leave do_broadcast() for domain 'reshape.com'
trylock = success
do_broadcast() for domain 'reshape.com' is called
broadcast: RPC: Timed out.
leave do_broadcast() for domain 'reshape.com'
do_broadcast() for domain 'reshape.com' is called
Status: YPBIND_FAIL_VAL
ypbindproc_domain_2_svc (reshape.com)
Pinging all active server.
broadcast: RPC: Timed out.
leave do_broadcast() for domain 'reshape.com'
do_broadcast() for domain 'reshape.com' is called
Pinging all active server.
broadcast: RPC: Timed out.
leave do_broadcast() for domain 'reshape.com'
trylock = success
do_broadcast() for domain 'reshape.com' is called
Signal (2) for quitting program arrived.

When I specify the YP servers in /etc/yp.conf as such:

ypserver 10.1.3.244
ypserver 10.1.3.243

then ypbind does bind:

[root@localhost root]# ypbind -debug
parsing config file
Trying entry: ypserver 10.1.3.244
parsed ypserver 10.1.3.244
add_server() domain: reshape.com, host: 10.1.3.244, slot: 0
Trying entry: ypserver 10.1.3.243
parsed ypserver 10.1.3.243
add_server() domain: reshape.com, host: 10.1.3.243, slot: 1
[Welcome to ypbind-mt, version 1.17.2]
  
ping host '10.1.3.244', domain 'reshape.com'
ping host '10.1.3.243', domain 'reshape.com'
Answer for domain 'reshape.com' from server '10.1.3.244'
Pinging all active server.
  
Even with this configuration, I see frequent whole system temporary
hangs when ypbind apparantly loses its binding to its ypserv.  It's
very flakey.

Curiously when I had the previous rev of the Sun ypserv patch
installed (patch 109328-02), then ypserv never bound to a server with
either -broadcast or using the 'ypserver' lines in /etc/yp.conf.

We have about 30 Linux systems (Red Hat Linux 7.2 + 9, Red Hat
Enterprise Linux 3) and 15 Sun Solaris 8 SPARC systems which all
happily bind to the same YP servers using broadcast.  Only the Fedora
Core 2 test systems fail.

All YP clients are on a flat network.  Both Solaris YP servers are on
the same subnet as the clients.

The NIC broadcast address and netmask are the same on the Fedora
clients, other Linux + Solaris clients, and the Solaris yp servers.


Version-Release number of selected component (if applicable):
ypbind-1.17.2-1

How reproducible:
Always

Steps to Reproduce:
1. Install Solaris 8 SPARC system with ypserv
2.  Add patch 109328-03 to Solaris 8 ypserv systems
3.  Configure Fedora client to use yp
4.  Boot Fedora client
    

Additional info:
Comment 1 Matthew Miller 2005-04-26 12:41:42 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 2 Mike Cooper 2005-04-26 12:44:13 EDT
I have verified the problem still is in FC3.  I have not yet tried FC4 testX.
Comment 3 Dimitri Papadopoulos 2005-07-07 05:56:08 EDT
I experience the same (or probably worse) problem with FC 4 clients. I've never
tested FC3 but it works just fine with RH9, FC2, Solaris and Irix clients.

Ths NIS server runs Solaris 8 with patch 109328-03 installed as well.

Everything gets incredibly slow as soon as I start ypbind on the client. Typical
error messages:

# ypbind -debug -broadcast
add_server() domain: uriens.shfj.cea.fr, broadcast
[Welcome to ypbind-mt, version 1.17.2]

do_broadcast() for domain 'uriens.shfj.cea.fr' is called
broadcast: RPC: Timed out.
leave do_broadcast() for domain 'uriens.shfj.cea.fr'
Pinging all active server.
do_broadcast() for domain 'uriens.shfj.cea.fr' is called
broadcast: RPC: Timed out.
leave do_broadcast() for domain 'uriens.shfj.cea.fr'
Pinging all active server.
do_broadcast() for domain 'uriens.shfj.cea.fr' is called
[...]
Comment 4 Mike Cooper 2005-07-07 12:43:01 EDT
I finally figured out the problem.  The firewall built into Fedora blocks all
the incoming YP/NIS requests from the server.  This is regardless of whether the
YP/NIS server is running Solaris or some Linux.  Disabling the firewall or
opening up the YP/NIS ports to the YP server fixes this problem.

The real issue is that the Fedora firewall should have a rule which allows
YP/NIS or some mechenism such that when YP is enabled, the firewall has the
appropriate exceptions added.
Comment 5 Dimitri Papadopoulos 2005-08-30 06:15:54 EDT
Ah, indeed! The firewall is disabled on our Red Hat 9 and Fedora 2 workstations,
precisely because of this problem - which I had forgotten in the meantime, sorry.

That said, wouldn't that be a bug in the ypbind initscript? Shouldn't it open
the ports it needs if NIS is enabled? If NIS is enabled, the NIS server has to
be specified somewhere, so it should be easy to open the relevant ports to the
NIS server. Something similar is done for NTP after all.

I'd like to see this issue reopened as a feature request: the NIS ypbind
initscript should open a hole in the firewall to the NIS server, just like the
NTP initscript.

Note You need to log in before you can comment on or make changes to this bug.