Bug 7341 - winbind not working over IPv6
winbind not working over IPv6
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: Winbind
3.5.2
Other Linux
: P3 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
http://krbdev.mit.edu/rt/Ticket/Displ...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-09 13:15 UTC by Guenther Deschner
Modified: 2010-05-19 06:18 UTC (History)
6 users (show)

See Also:


Attachments
v3-5-test: getpeername check (1.97 KB, patch)
2010-05-17 07:17 UTC, Guenther Deschner
jra: review+
Details
v3-5-test: avoid ipv6 addr in krb5.conf creation (6.85 KB, patch)
2010-05-17 07:18 UTC, Guenther Deschner
jra: review+
Details
v3-4-test: getpeername check (1.97 KB, patch)
2010-05-18 10:08 UTC, Guenther Deschner
kseeger: review? (jra)
Details
v3-4-test: avoid ipv6 addr in krb5.conf creation (6.87 KB, patch)
2010-05-18 10:09 UTC, Guenther Deschner
kseeger: review? (jra)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guenther Deschner 2010-04-09 13:15:34 UTC
winbind not working over IPv6

logs to follow...
Comment 1 Stefan Metzmacher 2010-04-26 02:57:02 UTC
Günther any updates on this? Are you able to reproduce it with v3-5-test?
Comment 2 Guenther Deschner 2010-05-14 18:28:17 UTC
I can reliably reproduce it even with master.

Here are some fixes that were required to make it work for a simple setup:

http://git.samba.org/?p=gd/samba/.git;a=shortlog;h=master-ipv6

(w2k8r2 ipv6 only, and only ipv6 dns in winbinds resolv.conf)
Comment 3 Jeremy Allison 2010-05-14 21:09:00 UTC
Must have bit-rotted then, as this used to work. Thanks for your efforts on this !
Jeremy.
Comment 4 Jeremy Allison 2010-05-14 21:12:24 UTC
Guenther - are these enough to fix it for master and 3.5.x ? I've reviewed the patches, and they look correct to me. (I remember testing an IPv6 kdc address with SLES, so I thought that worked on that distro). If you confirm they're enough, I'll ack the patches and re-assign to Karolin for 3.5.3. Push them to master if they're working for you please.

Jeremy.
Comment 5 Guenther Deschner 2010-05-17 04:26:53 UTC
sorry, this is a blocker.

actively testing my patches in more ipv6 networks now.
Comment 6 Guenther Deschner 2010-05-17 07:16:14 UTC
ok, tests succeeded in another ipv6 network.
Comment 7 Guenther Deschner 2010-05-17 07:17:00 UTC
Created attachment 5710 [details]
v3-5-test: getpeername check
Comment 8 Guenther Deschner 2010-05-17 07:18:38 UTC
Created attachment 5711 [details]
v3-5-test: avoid ipv6 addr in krb5.conf creation
Comment 9 Guenther Deschner 2010-05-17 08:44:11 UTC
adding http://krbdev.mit.edu/rt/Ticket/Display.html?id=6562#lasttrans which simo found.

As it seems, putting ipv6 addresses into krb5.conf is still not supported in MIT krb5 (which reflects testing experiences).
Comment 10 Jeremy Allison 2010-05-17 12:01:56 UTC
Comment on attachment 5710 [details]
v3-5-test: getpeername check

Looks good to me.
Comment 11 Jeremy Allison 2010-05-17 12:21:28 UTC
Comment on attachment 5711 [details]
v3-5-test: avoid ipv6 addr in krb5.conf creation

Looks good to me.
Jeremy.
Comment 12 Jeremy Allison 2010-05-17 12:22:56 UTC
Re-assigning to Karolin for inclusion in 3.5.x.
Comment 13 Karolin Seeger 2010-05-18 03:47:21 UTC
As IPv6 support did not work in any of the 3.5 releases, I vote to fix this one for 3.5.4 instead of delaying 3.5.3 which is scheduled for tomorrow. Are there any objections?
Comment 14 Guenther Deschner 2010-05-18 09:51:36 UTC
(In reply to comment #13)
> As IPv6 support did not work in any of the 3.5 releases, I vote to fix this one
> for 3.5.4 instead of delaying 3.5.3 which is scheduled for tomorrow. Are there
> any objections?

Fine by me, really your decision. Jeremy ?

Oh and btw. 3.4 has the same problem, backports to follow...
Comment 15 Guenther Deschner 2010-05-18 10:08:31 UTC
Created attachment 5714 [details]
v3-4-test: getpeername check
Comment 16 Guenther Deschner 2010-05-18 10:09:23 UTC
Created attachment 5715 [details]
v3-4-test: avoid ipv6 addr in krb5.conf creation
Comment 17 Jeremy Allison 2010-05-18 11:31:51 UTC
Karolin, you're the boss on this. If you want to wait until 3.5.4 that's ok with me. Thanks,
Jeremy.
Comment 18 Volker Lendecke 2010-05-18 13:00:48 UTC
The alternative is to delay 3.5.3 for a week or two.

Volker
Comment 19 Jeremy Allison 2010-05-18 13:03:50 UTC
What do the distro maintainers think (Jim, Simo, Guenther - or the debian guys) ?
Jeremy.
Comment 20 Simo Sorce 2010-05-18 13:07:57 UTC
On the one hand it is a bad regression, on the other it has been around for quite a while.
So I think Karolin should decide what's best. We will carry the patch in RHEL until upstream has it and we re-import a new version from upstream.
Comment 21 Jim McDonough 2010-05-18 13:14:10 UTC
We are in the same situation.  We will not change any delivery schedule of ours based on this, but merely include the patches until the upstream version which we ship contains the fix.

Comment 22 Lars Müller 2010-05-18 13:21:48 UTC
I suggest to stay with the release schedule of 3.5.3 as planed.

The release notes should reference this issue and include a pointer to a patch set addressing the issue.  This might make the life for vendors a bit more easy.
Comment 23 Karolin Seeger 2010-05-19 05:54:56 UTC
Pushed patches to v3-5-test.
Will be included in 3.5.4, not in 3.5.3.

Waiting for review of the 3.4 versions.
Comment 24 Guenther Deschner 2010-05-19 06:15:29 UTC
Karolin, the v3-4-test patches are really 1:1 to the v3-5-test ones (sorry, I should have pointed out that). So no additional review is needed, IMHO.

Thanks a lot of being cautious about these sort of things ;-)
Comment 25 Karolin Seeger 2010-05-19 06:18:26 UTC
(In reply to comment #24)
> Karolin, the v3-4-test patches are really 1:1 to the v3-5-test ones (sorry, I
> should have pointed out that). So no additional review is needed, IMHO.

Pushed to v3-4-test.
Closing out bug report.

> Thanks a lot of being cautious about these sort of things ;-)

Getting paranoid... ;-)

Thanks!