Bug 3957 - samba-3.0.23a, get_dc_list failure(s)
Summary: samba-3.0.23a, get_dc_list failure(s)
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: net utility (show other bugs)
Version: 3.0.23
Hardware: Other Linux
: P3 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-24 10:22 UTC by Rex Dieter
Modified: 2006-07-25 20:10 UTC (History)
0 users

See Also:


Attachments
zero memory for dc list (580 bytes, patch)
2006-07-25 15:11 UTC, Gerald (Jerry) Carter (dead mail address)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rex Dieter 2006-07-24 10:22:19 UTC
Tried upgrading a couple of working samba-3.0.22 boxes that are currently members of our ads domain to samba-3.0.23a.

Before the upgrade:
$ kinit foo@BAR.com
$ net ads testjoin
$ net ads join
works fine.

After the upgrade
$ net ads testjoin
$ net ads join
both hang.  So I tried

$ net ads testjoin -d4
and found that it returns:
[2006/07/24 10:12:27, 4] libsmb/namequery.c:get_dc_list(1502)
  get_dc_list: returning 2 ip addresses in an unordered list
[2006/07/24 10:12:27, 4] libsmb/namequery.c:get_dc_list(1503)
  get_dc_list: 2.0.0.0:389 73.78.47.85:1160662094
which is *totally* not right for our site (not even close).

????

running the aforementioned command using samba-3.0.22 does return the correct values for get_dc_list.
Comment 1 Gerald (Jerry) Carter (dead mail address) 2006-07-24 10:25:29 UTC
Please attach a level 10 debug log from net and a raw network 
trace from ethereal.  I rewrote the DNS lookup routines for 3.0.23.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2006-07-24 10:27:45 UTC
Is this a non-intel Linux platform ?
Comment 3 Rex Dieter 2006-07-24 10:34:36 UTC
These are i686 RHEL4 boxes.

Damn it, must have been a local problem (our campus AD servers have been known to go into la-la land on occasion).  Now, ~30 minutes later, I can no longer reproduce the problem.
Comment 4 Gerald (Jerry) Carter (dead mail address) 2006-07-24 10:39:25 UTC
If this pops back up, let me know.  I've been testing 
pretty thoroughly against Windows 2000 DNS.  Unless there
some packet format that I haven't seen, it should be fine.
Comment 5 Rex Dieter 2006-07-24 11:32:57 UTC
OK, I think I can now reproduce.  It's dependant on what's exactly in /etc/krb5.conf.

If I have in /etc/krb5.conf:
[libdefaults]
 default_realm = UNL.EDU

[realms]
 UNL.EDU = {
  default_domain = unl.edu
 }

[domain_realm]
  unl.edu = UNL.EDU
  .unl.edu = UNL.EDU

Things fail as before.  If I instead I manually specify kdc and admin server

[realms]
 UNL.EDU = {
  kdc = foo.UNL.EDU
  admin_server = foo.UNL.EDU
  default_domain = unl.edu
 }

It works.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2006-07-24 12:04:20 UTC
That makes no sense.  The get_dc_list() talks directly to DNS.
Can you attach the debug logs and network traces?  Thanks.
Comment 7 Rex Dieter 2006-07-24 12:16:10 UTC
> That makes no sense
Tell me about it! (:
Comment 8 Rex Dieter 2006-07-24 12:21:16 UTC
Things seem to be working here again.  It must have been a wild coincidence that my *5* previous attempts to confirm a change in krb5.conf made a difference, because now it works both ways.  I think I need a drink.
Comment 9 Gerald (Jerry) Carter (dead mail address) 2006-07-25 15:09:57 UTC
I think I found the bug.  The problem is when the 
Addition Records section of the DNS reply does not
contain A records for all the SRV names.  Will attach a patch.
Comment 10 Gerald (Jerry) Carter (dead mail address) 2006-07-25 15:11:41 UTC
Created attachment 2061 [details]
zero memory for dc list
Comment 11 Gerald (Jerry) Carter (dead mail address) 2006-07-25 15:12:03 UTC
This should fix the problem.
Comment 12 Rex Dieter 2006-07-25 20:07:06 UTC
Jerry, many thanks (for that patch and for saving my sanity).
Comment 13 Gerald (Jerry) Carter (dead mail address) 2006-07-25 20:10:47 UTC
My fault.  Thanks for following up and testing.