Re: [Freeipa-users] FREEIPA REPLICA - ITS USE AND HOW IT SHOULD OPERATE WHEN PRIMARY FAILS
Thanx for the feedback So if the replica is similar to the primary ,if the primary gets completely fried , without automatic failover ,i can reconfigure my clients to point to the new replica server without issues ??? From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Nathan Kinder [nkin...@redhat.com] Sent: Saturday, April 11, 2015 4:57 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] FREEIPA REPLICA - ITS USE AND HOW IT SHOULD OPERATE WHEN PRIMARY FAILS On 04/10/2015 06:54 PM, Martin Chamambo wrote: Good day I have a freeipa primary server working as i wanted , no complex stuff has been setup yet except the basic service and sudo controls which is fine by me. I have also setup a replica from the primary. the dns server is running from a different platform so basically the 2 servers query a DNS server on onother server to resolve their names. my questions is as follows: when primary server fails , does the replica automatically assume the position of the primary [and please note that replication is also working as expected] The replica is no different from the primary master, aside from being responsible for CRL generation. Failover really depends on how your clients are configured. If you are using SSSD, you should look at the 'FAILOVER' section in the 'sssd-ipa' man page for a details on how it works and how it is configured. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FREEIPA REPLICA - ITS USE AND HOW IT SHOULD OPERATE WHEN PRIMARY FAILS
Martin Chamambo wrote: Thanx for the feedback So if the replica is similar to the primary ,if the primary gets completely fried , without automatic failover ,i can reconfigure my clients to point to the new replica server without issues ??? If you use DNS SRV records then in the short term all you need to do is drop fried server from the list of SRV records and move on. In the short to medium term on the clients you'd want to check /etc/ipa/default.conf and /etc/sssd/sssd.conf for references to that dearly departed server and replace them with another server. You'll also want to terminate any replication agreements with it on any other masters otherwise changes will accumulate. The only difference between the very first master you install and all the others is that first one generates the CRL and manages CA renewal. See https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master I should mention that unless a master has actually created a user or group it has no DNA configuration so has no range of values to assign to POSIX users/groups. A clone is installed initially without a range and it fetches one the first time it needs it, from the master that created it. Of course, if that master is gone then problems ensure. rob From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Nathan Kinder [nkin...@redhat.com] Sent: Saturday, April 11, 2015 4:57 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] FREEIPA REPLICA - ITS USE AND HOW IT SHOULD OPERATE WHEN PRIMARY FAILS On 04/10/2015 06:54 PM, Martin Chamambo wrote: Good day I have a freeipa primary server working as i wanted , no complex stuff has been setup yet except the basic service and sudo controls which is fine by me. I have also setup a replica from the primary. the dns server is running from a different platform so basically the 2 servers query a DNS server on onother server to resolve their names. my questions is as follows: when primary server fails , does the replica automatically assume the position of the primary [and please note that replication is also working as expected] The replica is no different from the primary master, aside from being responsible for CRL generation. Failover really depends on how your clients are configured. If you are using SSSD, you should look at the 'FAILOVER' section in the 'sssd-ipa' man page for a details on how it works and how it is configured. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Expired Certs
I've inhereted an IPA infrastructure for a group in my organization. So I've got a RHEL instance with a IPA 3.0.0 server with expired certs. [root@ipa ~]# rpm -qa | grep ipa-serveripa-server-selinux-3.0.0-26.el6_4.2.x86_64ipa-server-3.0.0-26.el6_4.2.x86_64[root@ipa ~]# [root@ipa ~]# getcert listNumber of certificates and requests being tracked: 8.Request ID '20130404232110': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='242557339296' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=CA Audit,O=IDEF expires: 2017-02-15 19:26:38 UTC key usage: digitalSignature,nonRepudiation pre-save command: post-save command: track: yes auto-renew: yesRequest ID '20130404232111': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='242557339296' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=OCSP Subsystem,O=IDEF expires: 2017-02-15 19:25:38 UTC eku: id-kp-OCSPSigning pre-save command: post-save command: track: yes auto-renew: yesRequest ID '20130404232112': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='242557339296' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=CA Subsystem,O=IDEF expires: 2017-02-15 19:25:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yesRequest ID '20130404232113': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=IPA RA,O=IDEF expires: 2017-02-15 19:25:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yesRequest ID '20130404232114': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='242557339296' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=ipa.infra.idef,O=IDEF expires: 2017-02-15 19:25:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yesRequest ID '20130404232127': status: CA_UNREACHABLE ca-error: Error setting up ccache for host service on client using default keytab: Cannot contact any KDC for realm 'IDEF'. stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDEF',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDEF/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDEF',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IDEF subject: CN=ipa.infra.idef,O=IDEF expires: 2015-04-05 23:21:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yesRequest ID '20130404232155': status: CA_UNREACHABLE ca-error: Error setting up ccache for host service on client using default keytab: Cannot contact any KDC for realm 'IDEF'. stuck: no key pair storage:
Re: [Freeipa-users] Expired Certs
On 04/10/2015 03:58 PM, John Williams wrote: I've inhereted an IPA infrastructure for a group in my organization. So I've got a RHEL instance with a IPA 3.0.0 server with expired certs. [root@ipa ~]# rpm -qa | grep ipa-server ipa-server-selinux-3.0.0-26.el6_4.2.x86_64 ipa-server-3.0.0-26.el6_4.2.x86_64 [root@ipa ~]# [root@ipa ~]# getcert list Number of certificates and requests being tracked: 8. Request ID '20130404232110': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='242557339296' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=CA Audit,O=IDEF expires: 2017-02-15 19:26:38 UTC key usage: digitalSignature,nonRepudiation pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130404232111': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='242557339296' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=OCSP Subsystem,O=IDEF expires: 2017-02-15 19:25:38 UTC eku: id-kp-OCSPSigning pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130404232112': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='242557339296' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=CA Subsystem,O=IDEF expires: 2017-02-15 19:25:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130404232113': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=IPA RA,O=IDEF expires: 2017-02-15 19:25:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130404232114': status: CA_UNREACHABLE ca-error: Error 7 connecting to http://ipa.infra.idef:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='242557339296' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=IDEF subject: CN=ipa.infra.idef,O=IDEF expires: 2017-02-15 19:25:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130404232127': status: CA_UNREACHABLE ca-error: Error setting up ccache for host service on client using default keytab: Cannot contact any KDC for realm 'IDEF'. stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDEF',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDEF/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDEF',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IDEF subject: CN=ipa.infra.idef,O=IDEF expires: 2015-04-05 23:21:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130404232155': status: CA_UNREACHABLE ca-error: Error setting up ccache for host service on client using default keytab: Cannot contact any KDC for realm 'IDEF'. stuck: no key pair storage:
Re: [Freeipa-users] Expired Certs
John Williams wrote: I've inhereted an IPA infrastructure for a group in my organization. So I've got a RHEL instance with a IPA 3.0.0 server with expired certs. [root@ipa ~]# rpm -qa | grep ipa-server ipa-server-selinux-3.0.0-26.el6_4.2.x86_64 ipa-server-3.0.0-26.el6_4.2.x86_64 [root@ipa ~]# [root@ipa ~]# getcert list [ snip ] [root@ipa ~]# date Thu Apr 10 00:13:51 EDT 2014 [root@ipa ~]# /etc/init.d/certmonger restart Stopping certmonger: [ OK ] Starting certmonger: [ OK ] [root@ipa ~]# You are going way to far back in time AFAICT. The certs expired on April 5 of this year so you don't need to go back to 2014. Just go back to April 3 or 4. You'll also need to restart IPA before kicking certmonger ipactl restart rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare failing
David Dejaeghere wrote: Hi, I even tried the command using an export from the http service nss db, same issue. regarding SElinux: ausearch -m AVC -ts recent no matches Sending you the log personally. Ok, so the way the certs are imported is all the certs in the PKCS#12 file are loaded in, then marked as untrusted. certutil -O is executed against the server cert which prints out what the trust chain should be and those certs marked as trusted CA's. That part is working fine. Finally it makes another pass through the database to verify the chain. Looking at the output there are two certs with the subject CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US and different serial numbers. I wonder if this is confusing the cert loader. These certs are included in the PKCS#12 file (serial #0 and #1828629 AFAICT). I don't know which one is the right' one, or if there even is one. rob Regards, D 2015-04-10 17:03 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi Rob, Without the --http-pin the command will give a prompt to enter the password. Tried both. I am sending the output of the pk12util -l to you in another email. It holds the wildcard certificate and the godaddy bundle for as far as I can tell. I have to admit, I'm a bit stumped. (SEC_ERROR_LIBRARY_FAILURE) is a rather generic NSS error which can mean any number of things. It often means that the NSS database it is using is bad in some way but given that this is a temporary database created just for this purpose I doubt that's it. You may want to look for SELinux AVCs though: ausearch -m AVC -ts recent. At the point where it is blowing up, the PKCS#12 file has already been imported and IPA is walking through the results trying to ensure that the full cert trust chain is available. It does this by reading the certs out of the database, and at that point it's blowing up. The PKCS#12 output you sent me looks ok. I don't believe this is an issue with trust or missing parts of the chain. I created a simple PKCS#12 file and was able to prepare a replica using it, so AFAICT the code isn't completely broken. Can you provide the full output from ipa-replica-prepare? rob Regards, D 2015-04-09 21:39 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Sorry for the lack of details! You are indeed correct about the version its 4.1 The command I am using is this: ipa-replica-prepare ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com --http-cert-file /home/fedora/newcert.pk12 --dirsrv-cert-file /home/fedora/newcert.pk12 --ip-address 172.31.16.31 -v I was pretty sure a pin was required with those options as well. What do the PKCS#12 files look like: pk12util -l /home/fedora/newcert.pk12 rob Regards, D 2015-04-09 16:16 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Does somebody have any pointers for me regarding this issue? It would help very much if you'd include the version you're working with. Based on line numbers I'll assume IPA 4.1. It's hard to say since you don't include the command-line you're using, or what those files consist of. It looks like it is blowing up trying to verify that the whole certificate chain is available. NSS unfortunately doesn't always provide the best error messages so it's hard to say why this particular cert can't be loaded. rob Regards, D 2015-04-07 13:34 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, I get the same error when I use a pk12 with only the server certificate (and key) in it. Not sure what else I can try. Regards, D 2015-04-11 0:23 GMT+02:00 Rob Crittenden rcrit...@redhat.com: David Dejaeghere wrote: Hi, I even tried the command using an export from the http service nss db, same issue. regarding SElinux: ausearch -m AVC -ts recent no matches Sending you the log personally. Ok, so the way the certs are imported is all the certs in the PKCS#12 file are loaded in, then marked as untrusted. certutil -O is executed against the server cert which prints out what the trust chain should be and those certs marked as trusted CA's. That part is working fine. Finally it makes another pass through the database to verify the chain. Looking at the output there are two certs with the subject CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US and different serial numbers. I wonder if this is confusing the cert loader. These certs are included in the PKCS#12 file (serial #0 and #1828629 AFAICT). I don't know which one is the right' one, or if there even is one. rob Regards, D 2015-04-10 17:03 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi Rob, Without the --http-pin the command will give a prompt to enter the password. Tried both. I am sending the output of the pk12util -l to you in another email. It holds the wildcard certificate and the godaddy bundle for as far as I can tell. I have to admit, I'm a bit stumped. (SEC_ERROR_LIBRARY_FAILURE) is a rather generic NSS error which can mean any number of things. It often means that the NSS database it is using is bad in some way but given that this is a temporary database created just for this purpose I doubt that's it. You may want to look for SELinux AVCs though: ausearch -m AVC -ts recent. At the point where it is blowing up, the PKCS#12 file has already been imported and IPA is walking through the results trying to ensure that the full cert trust chain is available. It does this by reading the certs out of the database, and at that point it's blowing up. The PKCS#12 output you sent me looks ok. I don't believe this is an issue with trust or missing parts of the chain. I created a simple PKCS#12 file and was able to prepare a replica using it, so AFAICT the code isn't completely broken. Can you provide the full output from ipa-replica-prepare? rob Regards, D 2015-04-09 21:39 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Sorry for the lack of details! You are indeed correct about the version its 4.1 The command I am using is this: ipa-replica-prepare ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com --http-cert-file /home/fedora/newcert.pk12 --dirsrv-cert-file /home/fedora/newcert.pk12 --ip-address 172.31.16.31 -v I was pretty sure a pin was required with those options as well. What do the PKCS#12 files look like: pk12util -l /home/fedora/newcert.pk12 rob Regards, D 2015-04-09 16:16 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Does somebody have any pointers for me regarding this issue? It would help very much if you'd include the version you're working with. Based on line numbers I'll assume IPA 4.1. It's hard to say since you don't include the command-line you're using, or what those files consist of. It looks like it is blowing up trying to verify that the whole certificate chain is available. NSS unfortunately doesn't always provide the best error messages so it's hard to say why this particular cert can't be loaded. rob Regards, D 2015-04-07 13:34 GMT+02:00
[Freeipa-users] FREEIPA REPLICA - ITS USE AND HOW IT SHOULD OPERATE WHEN PRIMARY FAILS
Good day I have a freeipa primary server working as i wanted , no complex stuff has been setup yet except the basic service and sudo controls which is fine by me. I have also setup a replica from the primary. the dns server is running from a different platform so basically the 2 servers query a DNS server on onother server to resolve their names. my questions is as follows: when primary server fails , does the replica automatically assume the position of the primary [and please note that replication is also working as expected] -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FREEIPA REPLICA - ITS USE AND HOW IT SHOULD OPERATE WHEN PRIMARY FAILS
On 04/10/2015 06:54 PM, Martin Chamambo wrote: Good day I have a freeipa primary server working as i wanted , no complex stuff has been setup yet except the basic service and sudo controls which is fine by me. I have also setup a replica from the primary. the dns server is running from a different platform so basically the 2 servers query a DNS server on onother server to resolve their names. my questions is as follows: when primary server fails , does the replica automatically assume the position of the primary [and please note that replication is also working as expected] The replica is no different from the primary master, aside from being responsible for CRL generation. Failover really depends on how your clients are configured. If you are using SSSD, you should look at the 'FAILOVER' section in the 'sssd-ipa' man page for a details on how it works and how it is configured. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
