[Freeipa-users] 6.1 beta

[Stephen Gallagher]

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

On 04/04/2011 04:43 PM, Sigbjorn Lie wrote:
> On 04/04/2011 10:28 PM, Stephen Gallagher wrote:
>> -----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.
>>
> Sure, see the attached file. I'm sending private, unscrambeled.
> 
> For some reason it started working now, sluggish, but working. Takes 
> 0.488s to look up a new user account using "# id username"
> 
> The log file is too much to read for me just now, it's getting late. :)

Can you show me the output from 'dig' instead of SRV? The logs you sent
seem to be telling me that the TTL is set to something extremely short,
because we're marking it as expired pretty much instantly.


- -- 
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/

iEYEARECAAYFAk2aMy8ACgkQeiVVYja6o6PNoACfayD4eb68HdfpEAuSoI4XTn5X
sWgAnjnFg0LaHvRiQ/gHsK07qHFr2NRL
=6mby
-----END PGP SIGNATURE-----