[Freeipa-users] ipa_server and ipa_backup_server failover time

[Matrix]

Hi, all


The purpose of this email is to know more about timeout ipa server failover. 


Env: 
# rpm -qa | grep sssd
sssd-krb5-common-1.13.0-40.el7_2.12.x86_64
python-sssdconfig-1.13.0-40.el7_2.12.noarch
sssd-ipa-1.13.0-40.el7_2.12.x86_64
sssd-client-1.13.0-40.el7_2.12.x86_64
sssd-ad-1.13.0-40.el7_2.12.x86_64
sssd-proxy-1.13.0-40.el7_2.12.x86_64
sssd-common-pac-1.13.0-40.el7_2.12.x86_64
sssd-ldap-1.13.0-40.el7_2.12.x86_64
sssd-krb5-1.13.0-40.el7_2.12.x86_64
sssd-common-1.13.0-40.el7_2.12.x86_64
sssd-1.13.0-40.el7_2.12.x86_64



base config:
# cat /etc/sssd/sssd.conf
[domain/example.com]


cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = spare01.example.com
chpass_provider = ipa

debug_level = 4
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2


domains = example.com



Situation A: both Server A and Server B have been configured in 'ipa_server'
ipa_server = ipa01.example.com, ipa02.example.com


Once ipa01 ipa service failed, id lookup/auth will be failed over to ipa02 around 15mins later. It should be controlled by 'ldap_connection_expire_timeout', with default value 900 seconds. I have proved it with changing it to 300 seconds. 


But if ipa01 was brought back, id lookup/auth will not be back to ipa01. Is it expected ? 


Situation B: Server A has been configured as 'ipa_server', and Server B configured as 'ipa_backup_server'
ipa_server = ipa01.example.com
ipa_backup_server = ipa02.example.com



Once ipa01 ipa service failed, id lookup/auth will be failed over ipa02 some minutes later. I have tried 2 times, failover time is around 10min ~ 15min.


Is it possible to control it more accurate? how to? any parameters I can try? 


Best Regards


Matrix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170109/021f0f08/attachment.htm>