Greetings community,
I'm having some major issues with my IPA servers and myself activating the bat signal seeking some help. We recently upgraded this system to SL7.5 and ran the ipa-server-upgrade command. During the upgrade the process failed and access to the LDAP service is nolonger possible. Running the "ipactl restart" command results in:
Failed to get service list from file: Unknown error when retrieving list of services from file: [Errno 2] No such file or directory: '/var/run/ipa/services.list'
I have tried running the "ipa-replica-manage re-initialize" command in an attempt resync the servers to noavail. I have also been reviewing certificates and no certificates appear to be expired. I believe the main cause of this problem has been the pki-tomcatd service would not start.
I'm guessing the first step in this process is to get the LDAP server running again. Are there any steps that someone could recommend to revive LDAP? I'm able to start and stop the service mainually, but the listening port 636 is not active.
ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected)
Your help is greatly appreciated.
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Greetings community,
I'm having some major issues with my IPA servers and myself activating the bat signal seeking some help. We recently upgraded this system to SL7.5 and ran the ipa-server-upgrade command. During the upgrade the process failed and access to the LDAP service is nolonger possible. Running the "ipactl restart" command results in:
Failed to get service list from file: Unknown error when retrieving list of services from file: [Errno 2] No such file or directory: '/var/run/ipa/services.list'
I have tried running the "ipa-replica-manage re-initialize" command in an attempt resync the servers to noavail. I have also been reviewing certificates and no certificates appear to be expired. I believe the main cause of this problem has been the pki-tomcatd service would not start.
I'm guessing the first step in this process is to get the LDAP server running again. Are there any steps that someone could recommend to revive LDAP? I'm able to start and stop the service mainually, but the listening port 636 is not active.
Shut down dirsrv then edit dse.ldif and set:
nsslapd-port = 389 nsslapd-security = on
That should get things running but doesn't address the cause of the upgarde failure.
rob
ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected)
Your help is greatly appreciated.
-- *Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Rob,
A big thank you for showing me howto bringthe service back. You are correct the doesn't resolve the cause. I suspect I'm in a bit of certificate hades. The first sign of problems start with pki-tomcatd failing to start. Testing of the https:<server_name> url says the connection is refused. I haven't been able to track down the cause. However, I do have other systems exibiting the same problem.
Could not connect to LDAP server host fitch.<domain> port 636 Error netscape.ldap.LDAPException: Authentication failed (49)
From here, I'm not certain where to look. Is this an issue with certmonger, pki-tomcatd, or something else?
Any suggestions?
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 02:41 PM, Rob Crittenden via FreeIPA-users wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Greetings community,
I'm having some major issues with my IPA servers and myself activating the bat signal seeking some help. We recently upgraded this system to SL7.5 and ran the ipa-server-upgrade command. During the upgrade the process failed and access to the LDAP service is nolonger possible. Running the "ipactl restart" command results in:
Failed to get service list from file: Unknown error when retrieving list of services from file: [Errno 2] No such file or directory: '/var/run/ipa/services.list'
I have tried running the "ipa-replica-manage re-initialize" command in an attempt resync the servers to noavail. I have also been reviewing certificates and no certificates appear to be expired. I believe the main cause of this problem has been the pki-tomcatd service would not start.
I'm guessing the first step in this process is to get the LDAP server running again. Are there any steps that someone could recommend to revive LDAP? I'm able to start and stop the service mainually, but the listening port 636 is not active.
Shut down dirsrv then edit dse.ldif and set:
nsslapd-port = 389 nsslapd-security = on
That should get things running but doesn't address the cause of the upgarde failure.
rob
ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected)
Your help is greatly appreciated.
-- *Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On 05/09/2018 04:23 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Rob,
A big thank you for showing me howto bringthe service back. You are correct the doesn't resolve the cause. I suspect I'm in a bit of certificate hades. The first sign of problems start with pki-tomcatd failing to start. Testing of the https:<server_name> url says the connection is refused. I haven't been able to track down the cause. However, I do have other systems exibiting the same problem.
Could not connect to LDAP server host fitch.<domain> port 636 Error netscape.ldap.LDAPException: Authentication failed (49)
From here, I'm not certain where to look. Is this an issue with certmonger, pki-tomcatd, or something else?
You need to look at the Directory Server access log to find what BIND DN is having problems:
/var/log/dirsrv/slapd-YOUR_INSTANCE/access
Then grep for "err=49". It should say if it's a bad password or if the bind dn is missing (no such object)
Any suggestions?
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 02:41 PM, Rob Crittenden via FreeIPA-users wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Greetings community,
I'm having some major issues with my IPA servers and myself activating the bat signal seeking some help. We recently upgraded this system to SL7.5 and ran the ipa-server-upgrade command. During the upgrade the process failed and access to the LDAP service is nolonger possible. Running the "ipactl restart" command results in:
Failed to get service list from file: Unknown error when retrieving list of services from file: [Errno 2] No such file or directory: '/var/run/ipa/services.list'
I have tried running the "ipa-replica-manage re-initialize" command in an attempt resync the servers to noavail. I have also been reviewing certificates and no certificates appear to be expired. I believe the main cause of this problem has been the pki-tomcatd service would not start.
I'm guessing the first step in this process is to get the LDAP server running again. Are there any steps that someone could recommend to revive LDAP? I'm able to start and stop the service mainually, but the listening port 636 is not active.
Shut down dirsrv then edit dse.ldif and set:
nsslapd-port = 389 nsslapd-security = on
That should get things running but doesn't address the cause of the upgarde failure.
rob
ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected)
Your help is greatly appreciated.
-- *Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Along with the logs listed below, searching through the certificates is not possible. A message is returned:
Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)
Certmonger is running and pki-tomcatd is not. "journalctl -u pki-tomcatd@pki-tomcat.service" shows certificates are not being matched. What am I missing?
Server Logs:
conn=23 fd=85 slot=85 SSL connection from XXX.XXX.XXX.91 to XXX.XXX.XXX.91 conn=23 TLS1.2 256-bit AES; client CN=CA Subsystem,O=<REALM>; issuer CN=Certificate Authority,O=<REALM> conn=23 TLS1.2 failed to map client certificate to LDAP DN (Could not matching certificate in User's LDAP entry) conn=23 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL conn=23 op=0 RESULT err=49 tag=97 nentries=0 etime=0.0022754084 - Client certificate mapping failed
conn=73 fd=123 slot=123 connection from XXX.XXX.XXX.241 to XXX.XXX.XXX.91 [09/May/2018:08:18:50.038802503 -0500] conn=73 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin" [09/May/2018:08:18:50.038845419 -0500] conn=73 op=0 RESULT err=0 tag=120 nentries=0 etime=0.0000382164 [09/May/2018:08:18:50.046139659 -0500] conn=73 TLS1.2 256-bit AES-GCM [09/May/2018:08:18:50.046531729 -0500] conn=73 op=1 BIND dn="cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" method=128 version=3 [09/May/2018:08:18:50.046882326 -0500] conn=73 op=1 RESULT err=49 tag=97 nentries=0 etime=0.0007732885 [09/May/2018:08:18:50.085596219 -0500] conn=73 op=2 UNBIND [09/May/2018:08:18:50.085625301 -0500] conn=73 op=2 fd=123 closed - U1
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 03:46 PM, Mark Reynolds via FreeIPA-users wrote:
On 05/09/2018 04:23 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Rob,
A big thank you for showing me howto bringthe service back. You are correct the doesn't resolve the cause. I suspect I'm in a bit of certificate hades. The first sign of problems start with pki-tomcatd failing to start. Testing of the https:<server_name> url says the connection is refused. I haven't been able to track down the cause. However, I do have other systems exibiting the same problem.
Could not connect to LDAP server host fitch.<domain> port 636 Error netscape.ldap.LDAPException: Authentication failed (49)
From here, I'm not certain where to look. Is this an issue with certmonger, pki-tomcatd, or something else?
You need to look at the Directory Server access log to find what BIND DN is having problems:
/var/log/dirsrv/slapd-YOUR_INSTANCE/access
Then grep for "err=49". It should say if it's a bad password or if the bind dn is missing (no such object)
Any suggestions?
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 02:41 PM, Rob Crittenden via FreeIPA-users wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Greetings community,
I'm having some major issues with my IPA servers and myself activating the bat signal seeking some help. We recently upgraded this system to SL7.5 and ran the ipa-server-upgrade command. During the upgrade the process failed and access to the LDAP service is nolonger possible. Running the "ipactl restart" command results in:
Failed to get service list from file: Unknown error when retrieving list of services from file: [Errno 2] No such file or directory: '/var/run/ipa/services.list'
I have tried running the "ipa-replica-manage re-initialize" command in an attempt resync the servers to noavail. I have also been reviewing certificates and no certificates appear to be expired. I believe the main cause of this problem has been the pki-tomcatd service would not start.
I'm guessing the first step in this process is to get the LDAP server running again. Are there any steps that someone could recommend to revive LDAP? I'm able to start and stop the service mainually, but the listening port 636 is not active.
Shut down dirsrv then edit dse.ldif and set:
nsslapd-port = 389 nsslapd-security = on
That should get things running but doesn't address the cause of the upgarde failure.
rob
ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected)
Your help is greatly appreciated.
-- *Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org To unsubscribe send an email tofreeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On 05/09/2018 05:54 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Along with the logs listed below, searching through the certificates is not possible. A message is returned:
Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)
Certmonger is running and pki-tomcatd is not. "journalctl -u pki-tomcatd@pki-tomcat.service" shows certificates are not being matched. What am I missing?
Server Logs:
What version of 389-ds-base are you using? rpm -qa | grep 389-ds-base
conn=23 fd=85 slot=85 SSL connection from XXX.XXX.XXX.91 to XXX.XXX.XXX.91 conn=23 TLS1.2 256-bit AES; client CN=CA Subsystem,O=<REALM>; issuer CN=Certificate Authority,O=<REALM> conn=23 TLS1.2 failed to map client certificate to LDAP DN (Could not matching certificate in User's LDAP entry) conn=23 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL conn=23 op=0 RESULT err=49 tag=97 nentries=0 etime=0.0022754084 - Client certificate mapping failed
conn=73 fd=123 slot=123 connection from XXX.XXX.XXX.241 to XXX.XXX.XXX.91 [09/May/2018:08:18:50.038802503 -0500] conn=73 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin" [09/May/2018:08:18:50.038845419 -0500] conn=73 op=0 RESULT err=0 tag=120 nentries=0 etime=0.0000382164 [09/May/2018:08:18:50.046139659 -0500] conn=73 TLS1.2 256-bit AES-GCM [09/May/2018:08:18:50.046531729 -0500] conn=73 op=1 BIND dn="cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" method=128 version=3 [09/May/2018:08:18:50.046882326 -0500] conn=73 op=1 RESULT err=49 tag=97 nentries=0 etime=0.0007732885 [09/May/2018:08:18:50.085596219 -0500] conn=73 op=2 UNBIND [09/May/2018:08:18:50.085625301 -0500] conn=73 op=2 fd=123 closed - U1
So there are two possibilities here. One, "cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" does not exist on the server, or two, you are using the wrong password for this entry in the replication agreement.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 03:46 PM, Mark Reynolds via FreeIPA-users wrote:
On 05/09/2018 04:23 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Rob,
A big thank you for showing me howto bringthe service back. You are correct the doesn't resolve the cause. I suspect I'm in a bit of certificate hades. The first sign of problems start with pki-tomcatd failing to start. Testing of the https:<server_name> url says the connection is refused. I haven't been able to track down the cause. However, I do have other systems exibiting the same problem.
Could not connect to LDAP server host fitch.<domain> port 636 Error netscape.ldap.LDAPException: Authentication failed (49)
From here, I'm not certain where to look. Is this an issue with certmonger, pki-tomcatd, or something else?
You need to look at the Directory Server access log to find what BIND DN is having problems:
/var/log/dirsrv/slapd-YOUR_INSTANCE/access
Then grep for "err=49". It should say if it's a bad password or if the bind dn is missing (no such object)
Any suggestions?
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 02:41 PM, Rob Crittenden via FreeIPA-users wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Greetings community,
I'm having some major issues with my IPA servers and myself activating the bat signal seeking some help. We recently upgraded this system to SL7.5 and ran the ipa-server-upgrade command. During the upgrade the process failed and access to the LDAP service is nolonger possible. Running the "ipactl restart" command results in:
Failed to get service list from file: Unknown error when retrieving list of services from file: [Errno 2] No such file or directory: '/var/run/ipa/services.list'
I have tried running the "ipa-replica-manage re-initialize" command in an attempt resync the servers to noavail. I have also been reviewing certificates and no certificates appear to be expired. I believe the main cause of this problem has been the pki-tomcatd service would not start.
I'm guessing the first step in this process is to get the LDAP server running again. Are there any steps that someone could recommend to revive LDAP? I'm able to start and stop the service mainually, but the listening port 636 is not active.
Shut down dirsrv then edit dse.ldif and set:
nsslapd-port = 389 nsslapd-security = on
That should get things running but doesn't address the cause of the upgarde failure.
rob
ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected)
Your help is greatly appreciated.
-- *Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
SL7.5:
389-ds-base-snmp-1.3.6.1-28.el7_4.x86_64 389-ds-base-libs-1.3.6.1-28.el7_4.x86_64 389-ds-base-1.3.6.1-28.el7_4.x86_64
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 05:01 PM, Mark Reynolds via FreeIPA-users wrote:
rpm -qa | grep 389-ds-bas
So there are two possibilities here. One, "cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" does not exist on the server, or two, you are using the wrong password for this entry in the replication agreement.
Perhaps the password has been corrupted. The agreements appear to be there when I run the command listed below. These systems have been running well for the past few years before this problem started appearing. I have run the "ipa-replica-manage re-initialize" command, but the pki-tomcatd service still continues to fail when trying to start the service. Are there any additional steps you recommend?
[root@fitch ~]# ipa-replica-manage list fitch.<domain> Directory Manager password:
kodiak.<domain>: replica piston.<domain>: replica tierod.<domain>: replica
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 05:01 PM, Mark Reynolds via FreeIPA-users wrote:
So there are two possibilities here. One, "cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" does not exist on the server, or two, you are using the wrong password for this entry in the replication agreement.
On 05/10/2018 10:48 AM, Michael Rainey (Contractor, Code 7320) wrote:
So there are two possibilities here. One, "cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" does not exist on the server, or two, you are using the wrong password for this entry in the replication agreement.
Perhaps the password has been corrupted. The agreements appear to be there when I run the command listed below. These systems have been running well for the past few years before this problem started appearing. I have run the "ipa-replica-manage re-initialize" command, but the pki-tomcatd service still continues to fail when trying to start the service. Are there any additional steps you recommend?
Try resetting the password for "cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" to the password you used in the agreement
# ldapmodify -D "cn=directory manager" -W dn: cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config changetype: modify replace: userpassword userpassword: YOUR_PASSWORD
[root@fitch ~]# ipa-replica-manage list fitch.<domain> Directory Manager password:
kodiak.<domain>: replica piston.<domain>: replica tierod.<domain>: replica
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 05:01 PM, Mark Reynolds via FreeIPA-users wrote:
So there are two possibilities here. One, "cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" does not exist on the server, or two, you are using the wrong password for this entry in the replication agreement.
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
So there are two possibilities here. One, "cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" does not exist on the server, or two, you are using the wrong password for this entry in the replication agreement.
Perhaps the password has been corrupted. The agreements appear to be there when I run the command listed below. These systems have been running well for the past few years before this problem started appearing. I have run the "ipa-replica-manage re-initialize" command, but the pki-tomcatd service still continues to fail when trying to start the service. Are there any additional steps you recommend?
certificate authentication is used for this connection so I'd check the certs.
Try:
# getcert list -f /var/lib/ipa/ra-agent.pem
Is the cert still valid?
Get the serial #
# openssl x509 -text -in /var/lib/ipa/ra-agent.pem | grep Number:
Look at the equivalent entry in LDAP:
# ldapsearch -x -D 'cn=directory manager' -W -b uid=ipara,ou=people,o=ipaca usercertificate description
The description attribute is in the form of 2;serial #;issuer;subject
Make sure the serial #'s match. For extra points compare the pem to that of usercertificate (minus the header/footer)
rob
[root@fitch ~]# ipa-replica-manage list fitch.<domain> Directory Manager password:
kodiak.<domain>: replica piston.<domain>: replica tierod.<domain>: replica
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/09/2018 05:01 PM, Mark Reynolds via FreeIPA-users wrote:
So there are two possibilities here. One, "cn=Replication Manager cloneAgreement1-fitch.<domain>-pki-tomcat,ou=csusers,cn=config" does not exist on the server, or two, you are using the wrong password for this entry in the replication agreement.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Rob for the win. When comparing the serial numbers there is big difference, one digit on the failing system and 10 digits on the working system. Upon further inspection, I noticed the ldapsearch returned two usercertificates where the failing system returned one.
Is there a bit of magic sauce to update the certificate?
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:01 AM, Rob Crittenden via FreeIPA-users wrote:
openssl x509 -text -in /var/lib/ipa/ra-agent.pem | grep Number:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Rob for the win. When comparing the serial numbers there is big difference, one digit on the failing system and 10 digits on the working system. Upon further inspection, I noticed the ldapsearch returned two usercertificates where the failing system returned one.
Is there a bit of magic sauce to update the certificate?
Ok I missed something. This works on one master but not the other?
It suggests that replication is broken between the two. Use ipa-cacert-manage -v `hostname` to see what the status is.
Is the actual PEM file correct on both systems?
rob
Use ipa-cacert-manage -v `hostname` to see what the status is.
Is this correct usage for this command? It throws out debug messages.
ipa-cacert-manage -v 'fitch' ipa: DEBUG: Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' Usage: ipa-cacert-manage renew [options] ipa-cacert-manage install [options] CERTFILE
ipa-cacert-manage: error: unknown command "fitch" ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in execute self.validate_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 105, in validate_options parser.error("unknown command "%s"" % command) File "/usr/lib64/python2.7/optparse.py", line 1583, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "/usr/lib64/python2.7/optparse.py", line 1573, in exit sys.exit(status)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The ipa-cacert-manage command failed, exception: SystemExit: 2 ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The ipa-cacert-manage command failed.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:59 AM, Rob Crittenden via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
Is this correct usage for this command? It throws out debug messages.
Sigh. This is what I get when I type too fast.
ipa-csreplica-manage ...
rob
ipa-cacert-manage -v 'fitch' ipa: DEBUG: Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' Usage: ipa-cacert-manage renew [options] ipa-cacert-manage install [options] CERTFILE
ipa-cacert-manage: error: unknown command "fitch" ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in execute self.validate_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 105, in validate_options parser.error("unknown command "%s"" % command) File "/usr/lib64/python2.7/optparse.py", line 1583, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "/usr/lib64/python2.7/optparse.py", line 1573, in exit sys.exit(status)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The ipa-cacert-manage command failed, exception: SystemExit: 2 ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The ipa-cacert-manage command failed.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:59 AM, Rob Crittenden via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Sigh. This is what I get when I type too fast.
No worries. You're helping me to make some headway on this problem.
This is more of what you are wanting to see, and for me it doesn't look good. Does this mean I'll be using the re-initialize option or some variation?
ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 12:09 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
Is this correct usage for this command? It throws out debug messages.
Sigh. This is what I get when I type too fast.
ipa-csreplica-manage ...
rob
ipa-cacert-manage -v 'fitch' ipa: DEBUG: Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' Usage: ipa-cacert-manage renew [options] ipa-cacert-manage install [options] CERTFILE
ipa-cacert-manage: error: unknown command "fitch" ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in execute self.validate_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 105, in validate_options parser.error("unknown command "%s"" % command) File "/usr/lib64/python2.7/optparse.py", line 1583, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "/usr/lib64/python2.7/optparse.py", line 1573, in exit sys.exit(status)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The ipa-cacert-manage command failed, exception: SystemExit: 2 ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The ipa-cacert-manage command failed.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:59 AM, Rob Crittenden via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Sigh... My replication agreements really do seem to be completely jacked up. I would have expected the hostname replica agreements and the hostname csreplica agreements to match.
# ipa-replica-manage list fitch.<domain> -v Directory Manager password:
kodiak.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00 piston.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-10 19:11:56+00:00 tierod.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00
# ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 01:02 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh. This is what I get when I type too fast.
No worries. You're helping me to make some headway on this problem.
This is more of what you are wanting to see, and for me it doesn't look good. Does this mean I'll be using the re-initialize option or some variation?
ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 12:09 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
Is this correct usage for this command? It throws out debug messages.
Sigh. This is what I get when I type too fast.
ipa-csreplica-manage ...
rob
ipa-cacert-manage -v 'fitch' ipa: DEBUG: Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' Usage: ipa-cacert-manage renew [options] ipa-cacert-manage install [options] CERTFILE
ipa-cacert-manage: error: unknown command "fitch" ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in execute self.validate_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 105, in validate_options parser.error("unknown command "%s"" % command) File "/usr/lib64/python2.7/optparse.py", line 1583, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "/usr/lib64/python2.7/optparse.py", line 1573, in exit sys.exit(status)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The ipa-cacert-manage command failed, exception: SystemExit: 2 ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The ipa-cacert-manage command failed.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:59 AM, Rob Crittenden via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh... My replication agreements really do seem to be completely jacked up. I would have expected the hostname replica agreements and the hostname csreplica agreements to match.
This is fairly typical. You don't really need a full CA on every master you just want > 1 CAs in your installation.
Maybe Mark can provide some insight into the replication issues.
I think that once we work that out the the other CA master will get its updated certificate via standard means and things will hopefully just work at that point.
rob
# ipa-replica-manage list fitch.<domain> -v Directory Manager password:
kodiak.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00 piston.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-10 19:11:56+00:00 tierod.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00
# ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 01:02 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh. This is what I get when I type too fast.
No worries. You're helping me to make some headway on this problem.
This is more of what you are wanting to see, and for me it doesn't look good. Does this mean I'll be using the re-initialize option or some variation?
ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 12:09 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
Is this correct usage for this command? It throws out debug messages.
Sigh. This is what I get when I type too fast.
ipa-csreplica-manage ...
rob
ipa-cacert-manage -v 'fitch' ipa: DEBUG: Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' Usage: ipa-cacert-manage renew [options] ipa-cacert-manage install [options] CERTFILE
ipa-cacert-manage: error: unknown command "fitch" ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in execute self.validate_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 105, in validate_options parser.error("unknown command "%s"" % command) File "/usr/lib64/python2.7/optparse.py", line 1583, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "/usr/lib64/python2.7/optparse.py", line 1573, in exit sys.exit(status)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The ipa-cacert-manage command failed, exception: SystemExit: 2 ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The ipa-cacert-manage command failed.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:59 AM, Rob Crittenden via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org To unsubscribe send an email tofreeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On 05/10/2018 03:30 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh... My replication agreements really do seem to be completely jacked up. I would have expected the hostname replica agreements and the hostname csreplica agreements to match.
This is fairly typical. You don't really need a full CA on every master you just want > 1 CAs in your installation.
Maybe Mark can provide some insight into the replication issues.
replication is not working because the master can not bind to the consumer to initialize it. Another option is to do an offline initialization so that the consumer gets the usercertificate it needs for incremental replication to work.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
I think that once we work that out the the other CA master will get its updated certificate via standard means and things will hopefully just work at that point.
rob
# ipa-replica-manage list fitch.<domain> -v Directory Manager password:
kodiak.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00 piston.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-10 19:11:56+00:00 tierod.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00
# ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 01:02 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh. This is what I get when I type too fast.
No worries. You're helping me to make some headway on this problem.
This is more of what you are wanting to see, and for me it doesn't look good. Does this mean I'll be using the re-initialize option or some variation?
ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 12:09 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
Is this correct usage for this command? It throws out debug messages.
Sigh. This is what I get when I type too fast.
ipa-csreplica-manage ...
rob
ipa-cacert-manage -v 'fitch' ipa: DEBUG: Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' Usage: ipa-cacert-manage renew [options] ipa-cacert-manage install [options] CERTFILE
ipa-cacert-manage: error: unknown command "fitch" ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in execute self.validate_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 105, in validate_options parser.error("unknown command "%s"" % command) File "/usr/lib64/python2.7/optparse.py", line 1583, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "/usr/lib64/python2.7/optparse.py", line 1573, in exit sys.exit(status)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The ipa-cacert-manage command failed, exception: SystemExit: 2 ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The ipa-cacert-manage command failed.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:59 AM, Rob Crittenden via FreeIPA-users wrote:
Use ipa-cacert-manage -v `hostname` to see what the status is.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org To unsubscribe send an email tofreeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
While researching the steps to perform the offline initilalization I notice peculiarity with the the replica aggrements on the system I plan to use as my source data. Notice the duplicate hostname from the ipa-csreplica-mange command. Is this yet another concern? If so, how do I remove the duplicate? Looking at the list of RUVs I don't see a duplicate there.
Please forgive me if I'm off topic and seem to be going through a squirell moment. I'm finding thissituation a bit nerve wracking.
Thank you for all of your help.
# ipa-csreplica-manage list tierod.<domain> -v Directory Manager password:
fitch.<domain> last init status: 0 Total update succeeded last init ended: 2018-05-10 19:28:58+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-11 15:13:48+00:00 piston.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (32) Problem connecting to replica - LDAP error: No such object (connection error) last update ended: 1970-01-01 00:00:00+00:00 fitch.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (49) Problem connecting to replica - LDAP error: Invalid credentials (connection error) last update ended: 1970-01-01 00:00:00+00:00 kodiak.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00 piston.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-11 15:13:48+00:00
# ipa-replica-manage list tierod.<domain> -v Directory Manager password:
fitch.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-11 15:26:31+00:00 sump.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-11 15:26:31+00:00
# ipa-replica-manage list-ruv Directory Manager password:
Replica Update Vectors: tierod.<domain>:389: 8 sump.<domain>:389: 15 piston.<domain>:389: 12 kodiak.<domain>:389: 11 voge.<domain>:389: 10 fitch.<domain>:389: 14 Certificate Server Replica Update Vectors: tierod.<domain>:389: 1095 piston.<domain>:389: 1180 kodiak.<domain>:389: 1185 voge.<domain>:389: 1190 fitch.<domain>:389: 1295
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 03:06 PM, Mark Reynolds via FreeIPA-users wrote:
On 05/10/2018 03:30 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh... My replication agreements really do seem to be completely jacked up. I would have expected the hostname replica agreements and the hostname csreplica agreements to match.
This is fairly typical. You don't really need a full CA on every master you just want > 1 CAs in your installation.
Maybe Mark can provide some insight into the replication issues.
replication is not working because the master can not bind to the consumer to initialize it. Another option is to do an offline initialization so that the consumer gets the usercertificate it needs for incremental replication to work.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
I think that once we work that out the the other CA master will get its updated certificate via standard means and things will hopefully just work at that point.
rob
# ipa-replica-manage list fitch.<domain> -v Directory Manager password:
kodiak.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00 piston.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-10 19:11:56+00:00 tierod.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00 # ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 01:02 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh. This is what I get when I type too fast.
No worries. You're helping me to make some headway on this problem.
This is more of what you are wanting to see, and for me it doesn't look good. Does this mean I'll be using the re-initialize option or some variation?
ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 12:09 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
> Use ipa-cacert-manage -v `hostname` to see what the status is. Is this correct usage for this command? It throws out debug messages.
Sigh. This is what I get when I type too fast.
ipa-csreplica-manage ...
rob
> ipa-cacert-manage -v 'fitch' > ipa: DEBUG: Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > Usage: ipa-cacert-manage renew [options] > ipa-cacert-manage install [options] CERTFILE > > ipa-cacert-manage: error: unknown command "fitch" > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line > 169, in execute > self.validate_options() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", > line 105, in validate_options > parser.error("unknown command "%s"" % command) > File "/usr/lib64/python2.7/optparse.py", line 1583, in error > self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) > File "/usr/lib64/python2.7/optparse.py", line 1573, in exit > sys.exit(status) > > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The > ipa-cacert-manage command failed, exception: SystemExit: 2 > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The > ipa-cacert-manage command failed.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:59 AM, Rob Crittenden via FreeIPA-users wrote: > Use ipa-cacert-manage -v `hostname` to see what the status is.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org To unsubscribe send an email tofreeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Well... I made a what think is a major oopsie. I was working my way through the guide from the link below. I was having good success exporting the directory database and migrating the data to a failing server. When attempting to load the data I overlooked the file ownership and the import failed. I corrected the mistake and successfully imported the data.
Now the problem is that the system is missing the dirsrv@<instance>. Now i can't start the service.
# systemctl status dirsrv dirsrv-admin.service dirsrv-snmp.service dirsrv.target
What can be done to bring back the service?
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 03:06 PM, Mark Reynolds via FreeIPA-users wrote:
On 05/10/2018 03:30 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh... My replication agreements really do seem to be completely jacked up. I would have expected the hostname replica agreements and the hostname csreplica agreements to match.
This is fairly typical. You don't really need a full CA on every master you just want > 1 CAs in your installation.
Maybe Mark can provide some insight into the replication issues.
replication is not working because the master can not bind to the consumer to initialize it. Another option is to do an offline initialization so that the consumer gets the usercertificate it needs for incremental replication to work.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
I think that once we work that out the the other CA master will get its updated certificate via standard means and things will hopefully just work at that point.
rob
# ipa-replica-manage list fitch.<domain> -v Directory Manager password:
kodiak.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00 piston.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-10 19:11:56+00:00 tierod.<domain>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) last update ended: 1970-01-01 00:00:00+00:00 # ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 01:02 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Sigh. This is what I get when I type too fast.
No worries. You're helping me to make some headway on this problem.
This is more of what you are wanting to see, and for me it doesn't look good. Does this mean I'll be using the re-initialize option or some variation?
ipa-csreplica-manage list fitch.<domain> -v Directory Manager password:
voge.<domain> last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) No replication sessions started since server startup last update ended: 1970-01-01 00:00:00+00:00
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 12:09 PM, Rob Crittenden wrote:
Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
> Use ipa-cacert-manage -v `hostname` to see what the status is. Is this correct usage for this command? It throws out debug messages.
Sigh. This is what I get when I type too fast.
ipa-csreplica-manage ...
rob
> ipa-cacert-manage -v 'fitch' > ipa: DEBUG: Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > Usage: ipa-cacert-manage renew [options] > ipa-cacert-manage install [options] CERTFILE > > ipa-cacert-manage: error: unknown command "fitch" > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line > 169, in execute > self.validate_options() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", > line 105, in validate_options > parser.error("unknown command "%s"" % command) > File "/usr/lib64/python2.7/optparse.py", line 1583, in error > self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) > File "/usr/lib64/python2.7/optparse.py", line 1573, in exit > sys.exit(status) > > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The > ipa-cacert-manage command failed, exception: SystemExit: 2 > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: The > ipa-cacert-manage command failed.
*Michael Rainey* Network Representative Naval Research Laboratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529
On 05/10/2018 10:59 AM, Rob Crittenden via FreeIPA-users wrote: > Use ipa-cacert-manage -v `hostname` to see what the status is.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org To unsubscribe send an email tofreeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Well I'm sure how this happened. It looks like I have an Identity server that has a replication agreement with itself. Is there a method to help clean this up?
# ipa-replica-manage list sump.<domain-name> -v Directory Manager password:
sump.<domain-name>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Unable to aquire replica: the replica has the same Replica ID as this one. Replication is aborting. last update ended: 1970-01-01 00:00:00+00:00 tierod.<domain-name>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-22 15:07:23+00:00
On 05/22/2018 11:24 AM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
Well I'm sure how this happened. It looks like I have an Identity server that has a replication agreement with itself. Is there a method to help clean this up?
# ipa-replica-manage list sump.<domain-name> -v Directory Manager password:
sump.<domain-name>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Unable to aquire replica: the replica has the same Replica ID as this one. Replication is aborting.
This means you have two replicas that are using the same replica id (nsds5replicaid). Perhaps this agreement is old and needs to be removed?
last update ended: 1970-01-01 00:00:00+00:00 tierod.<domain-name>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-22 15:07:23+00:00
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
The mystery continues. It seems might be working but in reality it's not. The replica has stopped updating from the master and is unable to talk to the LDAP server. I'm fairly certain this is a certificate issue. However, my certs appear to be valid.
So far, the ipa-replica-manage command using the re-initialize or force-sync is not fixing the problem. Copying the LDAP database from the master to the replica has not worked. Where do I go from here?
# ipa-replica-manage list tierod.<domain-name> -v fitch.<domain-name>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-22 21:19:06+00:00 sump.<domain-name>: replica last init status: -1 - LDAP error: Can't contact LDAP server last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00
# ipa-replica-manage list sump.<domain-name> -v Directory Manager password:
tierod.<domain-name>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-22 21:09:22+00:00
On 05/22/2018 05:32 PM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
The mystery continues. It seems might be working but in reality it's not. The replica has stopped updating from the master and is unable to talk to the LDAP server. I'm fairly certain this is a certificate issue. However, my certs appear to be valid.
So far, the ipa-replica-manage command using the re-initialize or force-sync is not fixing the problem. Copying the LDAP database from the master to the replica has not worked. Where do I go from here?
# ipa-replica-manage list tierod.<domain-name> -v fitch.<domain-name>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-22 21:19:06+00:00 sump.<domain-name>: replica
The directory server access log on (sump) should confirm your theory....
But of course I have to ask, is sump actually running?
last init status: -1 - LDAP error: Can't contact LDAP server last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00
# ipa-replica-manage list sump.<domain-name> -v Directory Manager password:
tierod.<domain-name>: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-05-22 21:09:22+00:00
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
But of course I have to ask, is sump actually running?
Yes, sump is running. I thought about mentoning this right after hitting the send button. I only wish my problem was that simple.
Anyway, back to my problem at hand. I reviewed the logs and found two reoccuring entries in the access and error logs. They are listed below.
On Sump: /var/log/dirsrv/slapd-<instance>/errors [21/May/2018:11:50:45.730639109 -0500] - ERR - agmt="cn=meTotierod.<domain-name>" (tierod:389) - clcache_load_buffer
- Can't locate CSN 5af9efa80002000f0000 in the changelog (DB
rc=-30988). If replication stops, the consumer may need to be reinitialized.
/var/log/dirsrv/slapd-<instance>/access [22/May/2018:22:40:47.308660133 -0500] conn=4574 op=1 SRCH base="cn=sump.<domain-name>,cn=masters,cn=ipa,cn=etc,<domain-name>" scope=2 filter="(ipaConfigString=enabledService)" attrs="ipaConfigString cn"
I found a reference to the CSN on the mailing list, but came up empty.
On 05/23/2018 10:57 AM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
But of course I have to ask, is sump actually running?
Yes, sump is running. I thought about mentoning this right after hitting the send button. I only wish my problem was that simple.
Anyway, back to my problem at hand. I reviewed the logs and found two reoccuring entries in the access and error logs. They are listed below.
On Sump: /var/log/dirsrv/slapd-<instance>/errors [21/May/2018:11:50:45.730639109 -0500] - ERR - agmt="cn=meTotierod.<domain-name>" (tierod:389) - clcache_load_buffer
- Can't locate CSN 5af9efa80002000f0000 in the changelog (DB
rc=-30988). If replication stops, the consumer may need to be reinitialized.
/var/log/dirsrv/slapd-<instance>/access [22/May/2018:22:40:47.308660133 -0500] conn=4574 op=1 SRCH base="cn=sump.<domain-name>,cn=masters,cn=ipa,cn=etc,<domain-name>" scope=2 filter="(ipaConfigString=enabledService)" attrs="ipaConfigString cn"
Need more "logging" than that :-) Can you provide a snippet from just the access log (~50 lines) during the time the replication initialization was attempted? <this would be the logs on sump>
Thanks
I found a reference to the CSN on the mailing list, but came up empty. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Thanks for the feedback. I was able to restart replication on the system. There was a typo in the /etc/hosts file on sump causing it to look at the wrong host on the networkand this came from earlier troubleshooting of DNS issues.
I appreciate all of your help and patience in this issue. Should we ever meet I'll need to buy you a beer.
Thanks,
On 05/23/2018 04:27 PM, Mark Reynolds via FreeIPA-users wrote:
On 05/23/2018 10:57 AM, Michael Rainey (Contractor, Code 7320) via FreeIPA-users wrote:
But of course I have to ask, is sump actually running?
Yes, sump is running. I thought about mentoning this right after hitting the send button. I only wish my problem was that simple.
Anyway, back to my problem at hand. I reviewed the logs and found two reoccuring entries in the access and error logs. They are listed below.
On Sump: /var/log/dirsrv/slapd-<instance>/errors [21/May/2018:11:50:45.730639109 -0500] - ERR - agmt="cn=meTotierod.<domain-name>" (tierod:389) - clcache_load_buffer
- Can't locate CSN 5af9efa80002000f0000 in the changelog (DB
rc=-30988). If replication stops, the consumer may need to be reinitialized.
/var/log/dirsrv/slapd-<instance>/access [22/May/2018:22:40:47.308660133 -0500] conn=4574 op=1 SRCH base="cn=sump.<domain-name>,cn=masters,cn=ipa,cn=etc,<domain-name>" scope=2 filter="(ipaConfigString=enabledService)" attrs="ipaConfigString cn"
Need more "logging" than that :-) Can you provide a snippet from just the access log (~50 lines) during the time the replication initialization was attempted? <this would be the logs on sump>
Thanks
I found a reference to the CSN on the mailing list, but came up empty. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
freeipa-users@lists.fedorahosted.org
-
Mark Reynolds -
Michael Rainey (Contractor, Code 7320) -
Rob Crittenden