-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/04/2011 04:20 PM, Sigbjorn Lie wrote:
> On 04/04/2011 10:12 PM, Stephen Gallagher wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 04/04/2011 03:52 PM, Sigbjorn Lie wrote:
>>> On 04/04/2011 09:36 PM, Stephen Gallagher wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 04/04/2011 03:06 PM, Dmitri Pal wrote:
>>>>> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote:
>>>>>> I also noticed that in /etc/sssd/sssd.conf the ipa server is
>>>>>> specified
>>>>>> with:
>>>>>> ipa_server = _srv_, ipa01.ix.test.com
>>>>>>
>>>>>> sssd doesn't resolve anything from IPA until I remove "_srv_,"
>>>>>>
>>>>> Stephen, was there a recent bug on this matter in SSSD?
>>>>>
>>>> The purpose of _srv_ is to check DNS for IPA server addresses first.
>>>> The
>>>> idea is that if you have more than one IPA server in service, then you
>>>> can use DNS to list all of them. Otherwise, the ipa-client-install can
>>>> only specify a static list of servers at the time of install. This
>>>> would
>>>> mean that if the IPA servers changed IP addresses or new ones entered
>>>> production, it would be necessary to change all of the client
>>>> configuration files.
>>>>
>>>> I'm puzzled why you would need to remove this, unless your DNS
>>>> server is
>>>> returning something other than FreeIPA servers for a SRV request
>>>> directed at _ldap.tcp
>>>>
>>> I have verfied that the _ldap._tcp is resolving correctly. DNS was set
>>> up using "ipa-server-install --setup-dns". I discovered this at the IPA
>>> server. This is a newly installed IPA server at RH 6.1 beta installed a
>>> few hours ago. No IP addresses changed.
>>>
>>>
>>> #  host -t srv _ldap._tcp
>>> _ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com.
>>
>> Is the domain part of the client machine also ix.test.com?
>>
>> The way we determine which SRV record to use is as follows:
>> 1) If dns_discovery_domain exists in the config file, it is always used.
>> 2) If not, first try the domain part of the machine's hostname (aka
>> hostname -d)
>> 3) If that fails, try the name of the SSSD domain (in sssd.conf
>> [domain/<domainname>]
>>
>> IIRC ipa-client-install should set [domain/<IPA domain name>] so if
>> that's not the same as your DNS domain, we could be having problems.
>>
>> Can we see your sssd.conf please? (feel free to sanitize as needed)
>>
> Please see the requested output below. This is taken from the IPA
> server, which had the issue. DNS servers in resolv.conf set to the IP of
> the IPA server.
> 
> 
> # hostname -d
> ix.test.com
> 
> # more sssd.conf
> [sssd]
> services = nss, pam
> config_file_version = 2
> 
> domains = ix.test.com
> [nss]
> 
> [pam]
> 
> [domain/ix.test.com]
> cache_credentials = True
> ipa_domain = ix.test.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> chpass_provider = ipa
> #ipa_server = _srv_, ipa01.ix.test.com
> ipa_server = ipa01.ix.test.com
> 
> [domain/default]
> cache_credentials = True
> krb5_realm = IX.TEST.COM
> krb5_kdcip = ipa01.ix.test.com:88
> auth_provider = krb5
> chpass_provider = krb5
> krb5_kpasswd = ipa01.ix.test.com:749
> 

That's very strange. There should be no issue with using _srv_ in this
configuration. Would you mind setting 'debug_level = 9' in
[domain/ix.test.com], turning _srv_ back on, restarting SSSD, trying a
request and then send me /var/log/sssd/sssd_ix.test.com.log to look at?
I'd like to know why we're failing to resolve it.


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2aKdYACgkQeiVVYja6o6OwGQCbBW3SRhGnW3CYGL5IHU8VszHX
NrwAnRRzvqLUxDrmdxDs1nOuF+eQ+Evg
=Z3lV
-----END PGP SIGNATURE-----

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to