[Freeipa-users] Red Hat 5 and 6 with IPA Client v. 4

[Martin Basti]

On 09/16/2015 06:30 PM, Andrey Ptashnik wrote:
> Alexander,
>
> Thank you for your feedback!
>
> In my environment I noticed that client machines that are on Red Hat 6 have version 3.0.0 of IPA client installed.
>
> [root at ptr-test-6 ~]# yum list installed | grep ipa
> ipa-client.x86_64                  3.0.0-47.el6
> ipa-python.x86_64                  3.0.0-47.el6
>
>
> [root at ptr-test-6 ~]# yum list installed | grep sssd
> python-sssdconfig.noarch           1.12.4-47.el6
> sssd.x86_64                        1.12.4-47.el6
> sssd-ad.x86_64                     1.12.4-47.el6
> sssd-client.x86_64                 1.12.4-47.el6
> sssd-common.x86_64                 1.12.4-47.el6
> sssd-common-pac.x86_64             1.12.4-47.el6
> sssd-ipa.x86_64                    1.12.4-47.el6
> sssd-krb5.x86_64                   1.12.4-47.el6
> sssd-krb5-common.x86_64            1.12.4-47.el6
> sssd-ldap.x86_64                   1.12.4-47.el6
> sssd-proxy.x86_64                  1.12.4-47.el6
> [root at ptr-test-6 ~]#
>
>
> And I noticed particular behavior with IPA client 3.0.0 and IPA server 4.1 - when I add machines to the domain using command below:
>
> # ipa-client-install --enable-dns-updates --ssh-trust-dns —mkhomedir
>
> DNS record populate in Forward lookup zone, but no PTR records appear in Reverse lookup zones. That behavior is not the same with IPA client 4.1 and IPA server 4.1 version combination.

Do you have enables PTR sync in forward zone configuration and do you 
have allowed dynamic updates for reverse zones?

How does the ipa41 client work, does it populate PTR record?

>
> Also during IPA client v. 3.0.0 configuration on version 6 of Red Hat I see output below:
>
> Synchronizing time with KDC...
> Enrolled in IPA realm XXXXXXXXX.COM
> Attempting to get host TGT...
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured sudoers in /etc/nsswitch.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm XXXXXXXXX.COM
> trying https://ipa-idm.XXXXXXXXX.COM/ipa/xml
> Forwarding 'env' to server u'https://ipa-idm.XXXXXXXXX.COM/ipa/xml'
> Failed to update DNS records.
> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
> Forwarding 'host_mod' to server u'https://ipa-idm.XXXXXXXXX.COM/ipa/xml'
> SSSD enabled
> Configuring XXXXXXXXX.COM as NIS domain
> Configured /etc/openldap/ldap.conf
> NTP enabled
> Configured /etc/ssh/ssh_config
> Configured /etc/ssh/sshd_config
> Client configuration complete.
>
>
> Regards,
>
> Andrey Ptashnik
>
>
>
>
>
>
> On 9/16/15, 8:43 AM, "Alexander Bokovoy" <abokovoy at redhat.com> wrote:
>
>> On Wed, 16 Sep 2015, Andrey Ptashnik wrote:
>>> Dear IPA Team,
>>>
>>> We have a situation in our datacenter where we deployed Red Hat 7.1
>>> with IPA server 4.1 and on the other hand we still have older machines
>>> with Red Hat 5 and 6. I noticed that repositories associated with
>>> version 6 have older version of the client software – v.3.0. Therefore
>>> some functionality is missing from client package 3 vs 4, like
>>> automatic update of both forward and reverse DNS records.
>>>
>>> Is it possible to install IPA client v. 4 on Red Hat 5 and 6 without
>>> much breaking dependencies in OS?
>> You don't need to install IPA python packages on older machines. These
>> packages are mostly for administration purposes.
>>
>> Automatic update of forward/reverse DNS zones is done by SSSD. RHEL 6
>> version of SSSD is on par with RHEL 7 version in the recent updates.
>> Additionally, MIT Kerberos backports were done in the recent updates to
>> allow OTP functionality in RHEL6 as well. So most of features are there
>> already, client-wise.
>>
>> RHEL5 version does not have such updates and you can implement most of
>> the support with existing SSSD and output of 'ipa-advise' tool on IPA
>> masters. nsupdate integration would probably need to be done
>> differently.
>>
>> Backporting IPA v4.x client code to RHEL 5 or 6 in general makes not
>> much sense.
>>
>> -- 
>> / Alexander Bokovoy