This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 150350

Summary: libnss_hesiod doesn't honor classes=HS,IN in /etc/hesiod.conf
Product: Red Hat Enterprise Linux 3 Reporter: Karl E. Kelley <kekelley>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: drepper.fsp, nalin, roland
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-678 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-05 12:38:55 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 156320, 156322    
Attachments:
Description Flags
proposed patch for hesiod in glibc from hesiod-3.0.2-28.1
none
updated patch for hesiod in glibc none

Description Karl E. Kelley 2005-03-04 15:07:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
At Iowa State we use class=HS for our hesiod database, I know that is
old practice, but we have used it for many many years.

The hesiod-3.0.2-28.1 rpm that comes with Red Hat Enterprise 3 has
the feature in /etc/hesiod.conf to control the order of classes
that hesiod will look up and we have the following in our
/etc/hesiod.conf:

rhs=.IASTATE.EDU
lhs=.ns
classes=HS,IN

This tells hesiod to look for cleass HS first, which is our default
hesiod class.  This works for our code that uses libhesiod.so.0.

However, the code in libnss_hesiod in glibc uses a fixed order and
trys class IN first.  This causes about 6 failed lookups for each
hesiod query that is issued for looking up uids and gids via 
/etc/nsswitch.conf.  This doesn't cause much of a problem if 
everything is working correctly, but occasionally one or more of the
dns servers can have a problem, and if its severe, the hesiod queries
can take a long time, this is bad enough if the lookups are using
class HS, but if they are using class IN, the extra failed queries can
cause severe problems, since we depend on looking up users in hesiod
for logging in to our Linux boxes.



Version-Release number of selected component (if applicable):
glibc-2.3.2-95.30

How reproducible:
Always

Steps to Reproduce:
1. have classes=HS,IN in /etc/hesiod.conf
2. have userids and groups defined in a class HS hesiod database
3. have passwd: files hesiod and
    group: files hesiod
    in /etc/nsswitch.conf
4. Have the dns servers in an unstable or slow environment


Actual Results:  Logins will fail when they take too long.
Also a ps command will take a long time, if someone is logged on
before the dns servers became unstable for processes owned by the
user logged in with hesiod obtained identity.  This is on the order
of minutes versus seconds when the dns servers are responding quickly.

Expected Results:  Logins and the ps command could be somewhat slow,
but nothing like 
described above.

Additional info:

I have a patch to glibc that adapts the code in hesiod-3.0.2-28.1
into the hesiod that is provided by glibc, and it has worked 
correctly for several months. However, it would be nice if glibc
would pick up this patch,or something similar that will honor the
classes- parm in /etc/hesiod.conf.

I will enclose the patch, it applies to many different versions of
glibc, since the hesiod code has been the same for quite a while.
Comment 1 Karl E. Kelley 2005-03-04 15:11:20 EST
Created attachment 111677 [details]
proposed patch for hesiod in glibc from hesiod-3.0.2-28.1
Comment 2 daryl herzmann 2005-06-02 21:05:08 EDT
Does RedHat have a comment about this?  Should we send the bug upstream or?
Comment 3 Jakub Jelinek 2005-06-03 04:02:38 EDT
Looks reasonable to me.
A few nits:
1) New fields should be IMHO added to the end of the structure
2) 
+/* A few operating systems don't define these. */
+#ifndef C_HS
+#define C_HS    4
+#endif
+#ifndef T_TXT
+#define T_TXT   16
+#endif

seems to be unnecessary.  The code used C_HS and T_TXT before without these,
and they are known defined in the glibc headers.
3) perhaps
+                               while (*cp && *cp != ',')
+                                       cp++;
can be replaced with cp = strchrnul (cp, ',');

Please create a ChangeLog entry for the patch and mail it to
libc-alpha@sources.redhat.com.  Once it is in upstream glibc CVS, it will be
backported for RHEL3 and RHEL4.
Comment 4 Jakub Jelinek 2005-06-03 04:48:02 EDT
2 more things:
1) please document the classes config line in hesiod/README.hesiod
2) please use strcasecmp instead of inventing a new function
Comment 5 Karl E. Kelley 2005-06-08 10:13:12 EDT
I have an updated patch that incorporates all the changes discussed above.
I will attach it to this entry.
Comment 6 Karl E. Kelley 2005-06-08 10:15:30 EDT
Created attachment 115220 [details]
updated patch for hesiod in glibc
Comment 7 Ulrich Drepper 2005-06-15 00:15:51 EDT
Applied a patch upstream.
Comment 12 Jakub Jelinek 2005-07-06 13:21:48 EDT
RHEL4 U2 initial glibc testing RPMs that should address also this problem
uploaded to ftp://people.redhat.com/jakub/glibc/2.3.4-2.10/
Comment 13 Jakub Jelinek 2005-07-07 03:38:57 EDT
RHEL3 U6 initial glibc testing RPMs that should address also this problem
uploaded to ftp://people.redhat.com/jakub/glibc/2.3.2-95.35/
Comment 15 Jay Turner 2005-07-19 14:25:48 EDT
Any testing feedback?
Comment 19 Red Hat Bugzilla 2005-09-28 09:52:40 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-661.html
Comment 20 Red Hat Bugzilla 2005-10-05 12:38:56 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-678.html