Bug 689424

Sachin, Engineering still requires answers to their questions in comment #2; please work with the customer to obtain them.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Also interested in an update, plus details of an official workaround from RH. This particular issue is affecting our RHEL 6.1 Certification process.

Per standard RHEL 6.1 install, we lose rsh/rlogin connectivity after 7 rsh calls.

Flipping nsswitch.conf hosts order to place nis after dns, changes the number to 40 rsh calls before loss of service.

*** Bug 729349 has been marked as a duplicate of this bug. ***

I can't see comment #2 however, this issue remains, unupdated, more than a year after the report.
(after each test - I wait for TIME_WAIT sockets to drop to zero)

Default RHEL config (nsswitch.conf with hosts: files nis dns)
# T=sunv40z-17
# for a in {1..100}; do rsh $T id 2>&1 >/dev/null; if [ $? = 0 ]; then   echo -n "+"; else echo -n "-"; fi; done; echo ""
+++++++---------------------------------------------------------------------------------------------

Flipping dns and nis order:
# for a in {1..100}; do rsh $T id 2>&1 >/dev/null; if [ $? = 0 ]; then   echo -n "+"; else echo -n "-"; fi; done; echo ""
++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------

[root@sunv40z-17 pam.d]# netstat -na | grep TIME_WAIT | wc -l
1241

Remove nis from hosts: entry in nsswitch.conf - I get to around 100 or 101 successes before it stops responding:

#for a in {1..150}; do rsh $T id 2>&1 >/dev/null; if [ $? = 0 ]; then   echo -n "+"; else echo -n "-"; fi; done; echo ""
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------

Please advise if I need to raise the severity through our partner liason.

Red Hat, We need updates to this ASAP.

R/

Paul Hinchman
Linux Storage Connectivity Program Mgr.
Hewlett-Packard

Also adding Steve Almy and Chris Tatman

Just a courtesy update to acknowledge the request from the Red Hat engineering side. We'll have a look at this afresh and see if we can give you some conclusive feedback shortly. Thanks for your patience.

Honza,

I doubt the glibc maintainers will accept that patch as-is, at least not without you or someone with explicit knowledge of this issue championing it.  I simply don't know this code, nor YP and all the issues surrounding it at all -- so if I were to try to champion it, well, all I could do is continually refer back to you or someone else with better knowledge of this issue.

The obvious issues I'd expect them to raise will be around security, ie, what are the implications of not using a reserved port?

So I posted an initial message to glibc maintainers with a slightly enhanced patch (use environment variable to define which maps are secure and use current behaviour in case the variable is not set). Feel free to join discussion:
http://sourceware.org/ml/libc-alpha/2012-08/msg00170.html

Paul or anyone else, can we get some more info, please, how this feature is implemented on the client side by HP? Particularly, how secured maps are defined on the client side? Is there any configuration file/variable or is ypbind's yp.conf used for that?

Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. After consideration, Red Hat does not plan to incorporate the suggested capability in a future release of Red Hat Enterprise Linux. If you would like Red Hat to re-consider your feature request, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.