| Summary: | Unable to use SRV records due to incorrect handling | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | John Hodrien <johnh> | ||||
| Component: | autofs | Assignee: | Ian Kent <ikent> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | yanfu,wang <yanwang> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.0 | CC: | ikent | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-07-19 08:56:57 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
John Hodrien
2011-07-15 13:41:39 UTC
(In reply to comment #0) > Created attachment 513382 [details] > Patch by Ian Kent <raven> that resolves the issue > > Description of problem: > > Using SRV records doesn't work due to autofs incorrectly splitting the records > when more than one SRV record exists. Right, I remember this, yes. > > Version-Release number of selected component (if applicable): > > Tested with autofs-5.0.5-31.el6 and autofs-5.0.5-31.el6 > > How reproducible: > > As long as you have multiple LDAP servers listed in SRV records, this will > always break. > > Steps to Reproduce: > 1. Configure autofs to use SRV records for you domain by setting: > LDAP_URI="ldap:///dc=you,dc=domain,dc=com" > > 2. Restart autofs > 3. cd into a directory served by the LDAP map. > > Actual results: > > autofs fails to connect to the server, and you can't cd. > > Expected results: > > autofs should connect and the automount should work. You would hope so, yes. > > Additional info: > > This is caused by it failing to split the responses up, so it tries to connect > to a server "ldap://server1 ldap://server2", rather than identifying that as > two different servers. > > http://www.kernel.org/pub/linux/daemons/autofs/v5/autofs-5.0.5-check-each-dc-server.patch > > Patch attached as well for good measure. Yaeh, same patch I would use but thanks for the reminder. > > This resolves the problem, and SRV records work once more. This is also what > was causing #704228 to fail. Oh ... I guess so, I do understand that if the connection gets that far with a string that has multiple URIs then the host name returned will be broken. > > Given that there appear to be other bugs with autofs such that round-robin DNS > doesn't work correctly with TLS, the only workaround is to explicitly list the > available LDAP servers in the config file, which isn't necessarily convenient > in the long term. Umm ... this sounds a bit odd. Are you saying that, since there are other unspecified or unknown bugs with this it's not worth fixing this? (In reply to comment #2) > (In reply to comment #0) > Yaeh, same patch I would use but thanks for the reminder. Sorry, I did realise the irony of suggesting you patch autofs with your own patch as soon as I'd posted this... But this *is* a patch I think's important to get in. > > Given that there appear to be other bugs with autofs such that round-robin DNS > > doesn't work correctly with TLS, the only workaround is to explicitly list the > > available LDAP servers in the config file, which isn't necessarily convenient > > in the long term. > > Umm ... this sounds a bit odd. > > Are you saying that, since there are other unspecified or unknown > bugs with this it's not worth fixing this? No, that wasn't what I was trying to say but I've clearly rambled. I think what I was really saying was at the moment the only functional alternative appears to be to list the servers explicitly in the config file, which is a pretty poor alternative to having working SRV support. I'd tried to point at ldap://active.directory.domain which should return all of the AD controllers, but that only worked if I disabled TLS. I'd presumed it was making the assumption that the remote server would have a certificate for that hostname, but I'd not tracked it down in the code to be sure. But that's most definitely a different bug to this one. Thanks, jh (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > Yaeh, same patch I would use but thanks for the reminder. > > Sorry, I did realise the irony of suggesting you patch autofs with your own > patch as soon as I'd posted this... But this *is* a patch I think's important > to get in. I agree, let's wait and see if we get acks for QA and project management. > > > > Umm ... this sounds a bit odd. > > > > Are you saying that, since there are other unspecified or unknown > > bugs with this it's not worth fixing this? > > No, that wasn't what I was trying to say but I've clearly rambled. I think > what I was really saying was at the moment the only functional alternative > appears to be to list the servers explicitly in the config file, which is a > pretty poor alternative to having working SRV support. I'll produce a patched test package (a bit busy just now but will get onto it soon as I can). I will need you to test that it works as I don't have an active directory domain to test it myself. > > I'd tried to point at ldap://active.directory.domain which should return all of > the AD controllers, but that only worked if I disabled TLS. I'd presumed it > was making the assumption that the remote server would have a certificate for > that hostname, but I'd not tracked it down in the code to be sure. But that's > most definitely a different bug to this one. Ummm ... don't know about that, it would depend on how the LDAP library routines handle LDAP server names that resolve to multiple addresses I guess, and perhaps something with Kerberos handling needing a specific address to bind to .... Just don't really know, sorry. Ian After checking I see I already have a bug that includes the patch here. The bug looks public so you should be able to see it to verify it is what you're after, 704228. It is approved for 6.2 and I have built a package which includes the patches in that bug. I'm tempted to mark this a a duplicate. If you need a test package I can place the patched package on people.redhat.com. (In reply to comment #5) > After checking I see I already have a bug that includes the patch > here. The bug looks public so you should be able to see it to > verify it is what you're after, 704228. > > It is approved for 6.2 and I have built a package which includes > the patches in that bug. > > I'm tempted to mark this a a duplicate. > If you need a test package I can place the patched package on > people.redhat.com. Well, yes. That's the bug that referenced as I thought looked similar before, but the only patch that was up was for something different. By all means mark this as a dupe and resolve it on the other ticket. I'll keep an eye on that one and am happy to test anything you want against our domain. jh (In reply to comment #6) > > I'm tempted to mark this a a duplicate. > > If you need a test package I can place the patched package on > > people.redhat.com. > > Well, yes. That's the bug that referenced as I thought looked similar before, > but the only patch that was up was for something different. Yes, that's right. I'm not sure of the time line now but when I posted the comment above I had already added the patch and was waiting bug approval to commit it to CVS. I hadn't added the patch to the bug either. I did that when I realized where I was up to with the other bug. IMO, both patches are needed to resolve the reported problem. > > By all means mark this as a dupe and resolve it on the other ticket. I'll keep > an eye on that one and am happy to test anything you want against our domain. Great, I'll do that. Ian *** This bug has been marked as a duplicate of bug 704228 *** |