Hide Forgot
2. What is the nature and description of the request? - use non-reserved source ports for non-secure NIS map lookups. - use reserved ports fort secure maps 3. Why does the customer need this?: When customer rcp a lots of small files via rcp from their supercomputer to RHEL, it fails sometimes and found that it happened when reserved ports get exhausted by NIS clients. So they are proposing this solution so that not use reserved potrs for all NIS lookup (indeed by root user) but use reserved ports only for secure NIS map lookups and use non-reserved ports for other lookups. 4. How would the customer like to achieve this? : They are looking something like as HP implemented http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02037757/c02037757.pdf "Reduced Usage of Reserved Ports Reserved ports are the ports from 0 to 1024. Only root users can bind to these ports. In previous releases, NIS commands attempted to bind to reserved ports by default. If there are numerous client requests, all the reserved ports can be consumed. This version of NIS enables binding to reserved ports for select commands or daemons when accessing secure maps which results in reduced usage of reserved ports by NIS. This change does not compromise performance or security. " 5. For each functional requirement listed in question 4, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Run tcpdump and verify source ports for NIS lookup. 6. Is there already an existing RFE upstream or in Red Hat bugzilla? No 7. How quickly does this need resolved? RHEL 5 minor release 8. Does this request meet the RHEL Inclusion criteria? Yes 9. List the affected packages: ypbind 10. Would the customer be able to assist in testing this functionality if implemented?: Yes
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.