[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30)fails to start
On 2/5/20 1:35 PM, Jochen Demmer via FreeIPA-users wrote: Yeah I actually modified the PEM outputs because I wasn't sure if it was sensible. The second attribute userCertificate has the serial 21. What about the ra-agent.key? When I put the certificate from the LDAP to the file named ra-agent.pem, does the .key file need to be updated, too? If the cert was renewed, the key didn't change. You can actually check that a given key matches a cert with # openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key | openssl md5 # openssl x509 -noout -modulus -in /var/lib/ipa/ra-agent.pem | openssl md5 Both outputs should be identical. HTH, flo Thank you so much. I'm looking forward to a working upgrade, soon ;-) Jochen Am Dienstag, 4. Februar 2020 17:47:05 CET schrieb Florence Blanc-Renaud: On 2/3/20 9:07 AM, Jochen Demmer via FreeIPA-users wrote: Hi, unfortunately currently there's is no other node, which is why I'm trying to update to Fedora 31. I used to replicate between two machines but on got lost. I installed a new machine which is supposed to work as my new replica but this is being virtualized in bhyve / FreeNAS and this doesn't allow Fedora 30 to be installed so I'm stuck with Fedora 31. In the docs it's said that versions between replicas need to be consistent so I'm trying to update the only running FreeIPA node (srv107) to Fedora 31 first. Ok, so in this case we need to work on this single node... Jochen On Monday, February 03, 2020 08:36 CET, Florence Blanc-Renaud via FreeIPA-users wrote: ... We can see that there is an inconsistency between the /var/lib/ipa/ra-agent.pem file and the LDAP content. You need to choose which one to pick as the source of truth and update the other one. If the cert in /var/lib/ipa/ra-agent.pem is still valid, you can use this one. To check the validity: $ openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem Look for the lines: Validity Not Before: Not After : If the cert is valid, use this one as source of truth and update the ldap entry with ldapmodify (the description attribute and the usercertificate attribute). If the cert is not valid, you need to find which one in the ldap entry corresponds to the serial 21. I did not manage to read the content of the usercertificate attribute, did you cut the ldapsearch output? I tried with $ openssl x509 -noout -text -BEGIN CERTIFICATE- MII... -END CERTIFICATE- but the 2 certs in the usercertificate attribute failed with "unable to load certificate". flo ... ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines ... ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30)fails to start
Yeah I actually modified the PEM outputs because I wasn't sure if it was sensible. The second attribute userCertificate has the serial 21. What about the ra-agent.key? When I put the certificate from the LDAP to the file named ra-agent.pem, does the .key file need to be updated, too? Thank you so much. I'm looking forward to a working upgrade, soon ;-) Jochen Am Dienstag, 4. Februar 2020 17:47:05 CET schrieb Florence Blanc-Renaud: On 2/3/20 9:07 AM, Jochen Demmer via FreeIPA-users wrote: Hi, unfortunately currently there's is no other node, which is why I'm trying to update to Fedora 31. I used to replicate between two machines but on got lost. I installed a new machine which is supposed to work as my new replica but this is being virtualized in bhyve / FreeNAS and this doesn't allow Fedora 30 to be installed so I'm stuck with Fedora 31. In the docs it's said that versions between replicas need to be consistent so I'm trying to update the only running FreeIPA node (srv107) to Fedora 31 first. Ok, so in this case we need to work on this single node... Jochen On Monday, February 03, 2020 08:36 CET, Florence Blanc-Renaud via FreeIPA-users wrote: ... We can see that there is an inconsistency between the /var/lib/ipa/ra-agent.pem file and the LDAP content. You need to choose which one to pick as the source of truth and update the other one. If the cert in /var/lib/ipa/ra-agent.pem is still valid, you can use this one. To check the validity: $ openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem Look for the lines: Validity Not Before: Not After : If the cert is valid, use this one as source of truth and update the ldap entry with ldapmodify (the description attribute and the usercertificate attribute). If the cert is not valid, you need to find which one in the ldap entry corresponds to the serial 21. I did not manage to read the content of the usercertificate attribute, did you cut the ldapsearch output? I tried with $ openssl x509 -noout -text -BEGIN CERTIFICATE- MII... -END CERTIFICATE- but the 2 certs in the usercertificate attribute failed with "unable to load certificate". flo ... ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines ... ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On 2/3/20 9:07 AM, Jochen Demmer via FreeIPA-users wrote: Hi, unfortunately currently there's is no other node, which is why I'm trying to update to Fedora 31. I used to replicate between two machines but on got lost. I installed a new machine which is supposed to work as my new replica but this is being virtualized in bhyve / FreeNAS and this doesn't allow Fedora 30 to be installed so I'm stuck with Fedora 31. In the docs it's said that versions between replicas need to be consistent so I'm trying to update the only running FreeIPA node (srv107) to Fedora 31 first. Ok, so in this case we need to work on this single node... Jochen On Monday, February 03, 2020 08:36 CET, Florence Blanc-Renaud via FreeIPA-users wrote: On 2/2/20 11:30 PM, Jochen Demmer via FreeIPA-users wrote: > Hi, > > this is the outputs: > [root@srv107 ipa]# openssl x509 -noout -in /var/lib/ipa/ra-agent.pem > -serial -subject -issuer -nameopt RFC2253 > serial=15 > subject=CN=IPA RA,O=UNIX.domain.NET > issuer=CN=Certificate Authority,O=UNIX.domain.NET > > [root@srv107 ipa]# openssl x509 -noout -in ra-agent.pem -serial -subject > -issuer -nameopt RFC2253 > serial=15 > subject=CN=IPA RA,O=UNIX.domain.NET > issuer=CN=Certificate Authority,O=UNIX.domain.NET > [root@srv107 ipa]# ldapsearch -LLL -o ldif-wrap=no -x -D "cn=directory > manager" -W -b uid=ipara,ou=people,o=ipaca dn description usercertificate > Enter LDAP Password: > dn: uid=ipara,ou=people,o=ipaca > description: 2;21;CN=Certificate Authority,O=UNIX.domain.NET;CN=IPA > RA,O=UNIX.domain.NET We can see that there is an inconsistency between the /var/lib/ipa/ra-agent.pem file and the LDAP content. You need to choose which one to pick as the source of truth and update the other one. If the cert in /var/lib/ipa/ra-agent.pem is still valid, you can use this one. To check the validity: $ openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem Look for the lines: Validity Not Before: Not After : If the cert is valid, use this one as source of truth and update the ldap entry with ldapmodify (the description attribute and the usercertificate attribute). If the cert is not valid, you need to find which one in the ldap entry corresponds to the serial 21. I did not manage to read the content of the usercertificate attribute, did you cut the ldapsearch output? I tried with $ openssl x509 -noout -text -BEGIN CERTIFICATE- MII... -END CERTIFICATE- but the 2 certs in the usercertificate attribute failed with "unable to load certificate". flo > usercertificate:: > MIIDccCCAlqgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDcyODE0MTIyMFoXDTE4MDcxODE0MTIyMFowKjEXMBUGA1UECgwOVU5JWC5HT1NJWC5ORVQxDzANBfNVBAMMBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24aQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBkzCBkDAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9zcnYxMDcuZ29zaXgubmV0OjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAg6wMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAi8CxlPVaFHi7XlT1sSY74WPy9BlZW/Dt9by94wDCs14pZeMalmwkY8iHkvQtTagoS7y/Nq0p7PTHbcr7y9CisiAP+DykYZHdIyBtjrQ37GIADjyXhbYJ+Y90O/J24M2q2t1X8xbSIhxqQ8eN4ICTDHqzBIn2YkAHxT1QkitNIZWlMSWdEImcpmQB5CIU1q8swaK6u1k5ksC4mNwUxkSzi1nr+ixuuIkSDjuC3f1kGOaJGV92fJRk+TbRvP6hxKMY9ITwy0upwcUvO/Sv8kdJ21pJ/VJmxfZDilHW6ZrZtME6zaMUmVCVmchxIV2jTvJ3PCAqly6fI41oOsEoPSYu1Q== > usercertificate:: > MIIadDCCAlygAwIBAgIBFTANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE4MDYyMDE0MTI1MloXDTIwMDYwOTE0MTI1MlowKjEXMBUGA1UEChMOVU5JWC5HT1NJWC5ORVQxDzANBgNVBAMTBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24qQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBlTCBkjAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjBABggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9pcGEtY2EudW5peC5nb3NpeC5uZXQvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUAA4IBAQB+WTlsE5LmEvbfEk/fOlKfwkNv187o/6AtwBxrjvC0D0QobfnxSIgd7R905haHf9fyONYsQKn8mlbghtY3URfGnfYNXJ9ez1pOqoCAlpy5Z5tvDlQMGvVVjk/9pSibTI90noZeMrUE+Tetq45c8ZjFXxcrH4R07xUDRXZg8AXviQMyclUSZbWKsIL7a979Hp13q8sJ8MAod1OhqdP6EOk84AOyRcQuRhv5uEdeDSN4k+4mMSZGnMlKO+0gKnhUIq63/TlW8wp7NhCE+kYdOkF4M0lBYOPE66d/4VdX45soMdp4WphjZMrirarhFJvHpHloUwdoiIFglPvOkvbWndbM
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hi, unfortunately currently there's is no other node, which is why I'm trying to update to Fedora 31. I used to replicate between two machines but on got lost. I installed a new machine which is supposed to work as my new replica but this is being virtualized in bhyve / FreeNAS and this doesn't allow Fedora 30 to be installed so I'm stuck with Fedora 31. In the docs it's said that versions between replicas need to be consistent so I'm trying to update the only running FreeIPA node (srv107) to Fedora 31 first. Jochen On Monday, February 03, 2020 08:36 CET, Florence Blanc-Renaud via FreeIPA-users wrote: On 2/2/20 11:30 PM, Jochen Demmer via FreeIPA-users wrote: > Hi, > > this is the outputs: > [root@srv107 ipa]# openssl x509 -noout -in /var/lib/ipa/ra-agent.pem > -serial -subject -issuer -nameopt RFC2253 > serial=15 > subject=CN=IPA RA,O=UNIX.domain.NET > issuer=CN=Certificate Authority,O=UNIX.domain.NET > > [root@srv107 ipa]# openssl x509 -noout -in ra-agent.pem -serial -subject > -issuer -nameopt RFC2253 > serial=15 > subject=CN=IPA RA,O=UNIX.domain.NET > issuer=CN=Certificate Authority,O=UNIX.domain.NET > [root@srv107 ipa]# ldapsearch -LLL -o ldif-wrap=no -x -D "cn=directory > manager" -W -b uid=ipara,ou=people,o=ipaca dn description usercertificate > Enter LDAP Password: > dn: uid=ipara,ou=people,o=ipaca > description: 2;21;CN=Certificate Authority,O=UNIX.domain.NET;CN=IPA > RA,O=UNIX.domain.NET > usercertificate:: > MIIDccCCAlqgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDcyODE0MTIyMFoXDTE4MDcxODE0MTIyMFowKjEXMBUGA1UECgwOVU5JWC5HT1NJWC5ORVQxDzANBfNVBAMMBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24aQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBkzCBkDAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9zcnYxMDcuZ29zaXgubmV0OjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAg6wMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAi8CxlPVaFHi7XlT1sSY74WPy9BlZW/Dt9by94wDCs14pZeMalmwkY8iHkvQtTagoS7y/Nq0p7PTHbcr7y9CisiAP+DykYZHdIyBtjrQ37GIADjyXhbYJ+Y90O/J24M2q2t1X8xbSIhxqQ8eN4ICTDHqzBIn2YkAHxT1QkitNIZWlMSWdEImcpmQB5CIU1q8swaK6u1k5ksC4mNwUxkSzi1nr+ixuuIkSDjuC3f1kGOaJGV92fJRk+TbRvP6hxKMY9ITwy0upwcUvO/Sv8kdJ21pJ/VJmxfZDilHW6ZrZtME6zaMUmVCVmchxIV2jTvJ3PCAqly6fI41oOsEoPSYu1Q== > usercertificate:: > MIIadDCCAlygAwIBAgIBFTANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE4MDYyMDE0MTI1MloXDTIwMDYwOTE0MTI1MlowKjEXMBUGA1UEChMOVU5JWC5HT1NJWC5ORVQxDzANBgNVBAMTBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24qQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBlTCBkjAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjBABggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9pcGEtY2EudW5peC5nb3NpeC5uZXQvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUAA4IBAQB+WTlsE5LmEvbfEk/fOlKfwkNv187o/6AtwBxrjvC0D0QobfnxSIgd7R905haHf9fyONYsQKn8mlbghtY3URfGnfYNXJ9ez1pOqoCAlpy5Z5tvDlQMGvVVjk/9pSibTI90noZeMrUE+Tetq45c8ZjFXxcrH4R07xUDRXZg8AXviQMyclUSZbWKsIL7a979Hp13q8sJ8MAod1OhqdP6EOk84AOyRcQuRhv5uEdeDSN4k+4mMSZGnMlKO+0gKnhUIq63/TlW8wp7NhCE+kYdOkF4M0lBYOPE66d/4VdX45soMdp4WphjZMrirarhFJvHpHloUwdoiIFglPvOkvbWndbM > > > I can see that the serial is different but I cannot compare the > usercertificate attributes since they are not given in the openssl > command output. > Hi, Serial is 15 on the node srv107 but 21 in LDAP. This means that the cert was renewed but the local file didn't get updated. Can you check first which node is your CA renewal master? $ kinit admin $ ipa config-show | grep "CA renewal master" IPA CA renewal master: master.ipa.domain On this node check that the file /var/lib/ipa/ra-agent.pem and the content in ldap are consistent. You can do just $ cat /var/lib/ipa/ra-agent.pem to compare the content of the cert with the usercertificate attribute of the ldap entry. If everything is OK on the renewal master, you can copy the file /var/lib/ipa/ra-agent.pem to the failing node srv107. HTH, flo > Shall I just adjust the serial and try again? > > Jochen > > > On Friday, January 31, 2020 10:29 CET, Florence Blanc-Renaud via > FreeIPA-users wrote: >> >> This error occurs when IPA framework tries to authenticate to Dogtag CA >> and it fails. It is using the certificate located in >> /var/lib/ipa/ra-agent.pem. >> According to your
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On 2/2/20 11:30 PM, Jochen Demmer via FreeIPA-users wrote: Hi, this is the outputs: [root@srv107 ipa]# openssl x509 -noout -in /var/lib/ipa/ra-agent.pem -serial -subject -issuer -nameopt RFC2253 serial=15 subject=CN=IPA RA,O=UNIX.domain.NET issuer=CN=Certificate Authority,O=UNIX.domain.NET [root@srv107 ipa]# openssl x509 -noout -in ra-agent.pem -serial -subject -issuer -nameopt RFC2253 serial=15 subject=CN=IPA RA,O=UNIX.domain.NET issuer=CN=Certificate Authority,O=UNIX.domain.NET [root@srv107 ipa]# ldapsearch -LLL -o ldif-wrap=no -x -D "cn=directory manager" -W -b uid=ipara,ou=people,o=ipaca dn description usercertificate Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca description: 2;21;CN=Certificate Authority,O=UNIX.domain.NET;CN=IPA RA,O=UNIX.domain.NET usercertificate:: MIIDccCCAlqgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDcyODE0MTIyMFoXDTE4MDcxODE0MTIyMFowKjEXMBUGA1UECgwOVU5JWC5HT1NJWC5ORVQxDzANBfNVBAMMBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24aQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBkzCBkDAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9zcnYxMDcuZ29zaXgubmV0OjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAg6wMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAi8CxlPVaFHi7XlT1sSY74WPy9BlZW/Dt9by94wDCs14pZeMalmwkY8iHkvQtTagoS7y/Nq0p7PTHbcr7y9CisiAP+DykYZHdIyBtjrQ37GIADjyXhbYJ+Y90O/J24M2q2t1X8xbSIhxqQ8eN4ICTDHqzBIn2YkAHxT1QkitNIZWlMSWdEImcpmQB5CIU1q8swaK6u1k5ksC4mNwUxkSzi1nr+ixuuIkSDjuC3f1kGOaJGV92fJRk+TbRvP6hxKMY9ITwy0upwcUvO/Sv8kdJ21pJ/VJmxfZDilHW6ZrZtME6zaMUmVCVmchxIV2jTvJ3PCAqly6fI41oOsEoPSYu1Q== usercertificate:: MIIadDCCAlygAwIBAgIBFTANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE4MDYyMDE0MTI1MloXDTIwMDYwOTE0MTI1MlowKjEXMBUGA1UEChMOVU5JWC5HT1NJWC5ORVQxDzANBgNVBAMTBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24qQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBlTCBkjAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjBABggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9pcGEtY2EudW5peC5nb3NpeC5uZXQvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUAA4IBAQB+WTlsE5LmEvbfEk/fOlKfwkNv187o/6AtwBxrjvC0D0QobfnxSIgd7R905haHf9fyONYsQKn8mlbghtY3URfGnfYNXJ9ez1pOqoCAlpy5Z5tvDlQMGvVVjk/9pSibTI90noZeMrUE+Tetq45c8ZjFXxcrH4R07xUDRXZg8AXviQMyclUSZbWKsIL7a979Hp13q8sJ8MAod1OhqdP6EOk84AOyRcQuRhv5uEdeDSN4k+4mMSZGnMlKO+0gKnhUIq63/TlW8wp7NhCE+kYdOkF4M0lBYOPE66d/4VdX45soMdp4WphjZMrirarhFJvHpHloUwdoiIFglPvOkvbWndbM I can see that the serial is different but I cannot compare the usercertificate attributes since they are not given in the openssl command output. Hi, Serial is 15 on the node srv107 but 21 in LDAP. This means that the cert was renewed but the local file didn't get updated. Can you check first which node is your CA renewal master? $ kinit admin $ ipa config-show | grep "CA renewal master" IPA CA renewal master: master.ipa.domain On this node check that the file /var/lib/ipa/ra-agent.pem and the content in ldap are consistent. You can do just $ cat /var/lib/ipa/ra-agent.pem to compare the content of the cert with the usercertificate attribute of the ldap entry. If everything is OK on the renewal master, you can copy the file /var/lib/ipa/ra-agent.pem to the failing node srv107. HTH, flo Shall I just adjust the serial and try again? Jochen On Friday, January 31, 2020 10:29 CET, Florence Blanc-Renaud via FreeIPA-users wrote: This error occurs when IPA framework tries to authenticate to Dogtag CA and it fails. It is using the certificate located in /var/lib/ipa/ra-agent.pem. According to your getcert output, the cert is valid. You will need to check if it is consistent with what is stored in LDAP. Note the values related to the actual certificate: $ cat /var/lib/ipa/ra-agent.pem -BEGIN CERTIFICATE- MII...NSF -END CERTIFICATE- $ openssl x509 -noout -in /var/lib/ipa/ra-agent.pem -serial -subject -issuer -nameopt RFC2253 serial= subject= CN=IPA RA,O= issuer= CN=Certificate Authority,O= Then compare the result with the ldapentry: $ ldapsearch -LLL -o ldif-wrap=no -x -D "cn=directory manager" -W \ -b uid=ipara,ou=people,o=ipaca dn description usercertificate Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca description:
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hi, this is the outputs: [root@srv107 ipa]# openssl x509 -noout -in /var/lib/ipa/ra-agent.pem -serial -subject -issuer -nameopt RFC2253 serial=15 subject=CN=IPA RA,O=UNIX.domain.NET issuer=CN=Certificate Authority,O=UNIX.domain.NET [root@srv107 ipa]# openssl x509 -noout -in ra-agent.pem -serial -subject -issuer -nameopt RFC2253 serial=15 subject=CN=IPA RA,O=UNIX.domain.NET issuer=CN=Certificate Authority,O=UNIX.domain.NET [root@srv107 ipa]# ldapsearch -LLL -o ldif-wrap=no -x -D "cn=directory manager" -W -b uid=ipara,ou=people,o=ipaca dn description usercertificate Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca description: 2;21;CN=Certificate Authority,O=UNIX.domain.NET;CN=IPA RA,O=UNIX.domain.NET usercertificate:: MIIDccCCAlqgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDcyODE0MTIyMFoXDTE4MDcxODE0MTIyMFowKjEXMBUGA1UECgwOVU5JWC5HT1NJWC5ORVQxDzANBfNVBAMMBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24aQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBkzCBkDAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9zcnYxMDcuZ29zaXgubmV0OjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAg6wMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAi8CxlPVaFHi7XlT1sSY74WPy9BlZW/Dt9by94wDCs14pZeMalmwkY8iHkvQtTagoS7y/Nq0p7PTHbcr7y9CisiAP+DykYZHdIyBtjrQ37GIADjyXhbYJ+Y90O/J24M2q2t1X8xbSIhxqQ8eN4ICTDHqzBIn2YkAHxT1QkitNIZWlMSWdEImcpmQB5CIU1q8swaK6u1k5ksC4mNwUxkSzi1nr+ixuuIkSDjuC3f1kGOaJGV92fJRk+TbRvP6hxKMY9ITwy0upwcUvO/Sv8kdJ21pJ/VJmxfZDilHW6ZrZtME6zaMUmVCVmchxIV2jTvJ3PCAqly6fI41oOsEoPSYu1Q== usercertificate:: MIIadDCCAlygAwIBAgIBFTANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYLkdPU0lYLk5FVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE4MDYyMDE0MTI1MloXDTIwMDYwOTE0MTI1MlowKjEXMBUGA1UEChMOVU5JWC5HT1NJWC5ORVQxDzANBgNVBAMTBklQQSBSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMxnrp8441QA/vzIB/0a9kT5IAH9yACEx8lirOspAOmn8ziFYUvB4idMqd4wKpuIeFhl4LDMN++HJGsfAGbon7LQ0lvlxz16ntdMazfmqSCwgSycroDLJEBHZW0vC6NslOVI808nnc7D+xcrOaGFaisDbjWYFn9LQoBHOAACtgGHmLQWszsQyrZhg0zbhzHoBDfSu6UtyCIuDP4lQ3tZdnNygP1x8cEmCUrAzEl3wqY24qQHMF7RglAb+O7/9A8UURXMi6QwIkbyucPA3Wh+RdHy41xhqDI/bmcq7Nas814PIHjhZQJTT02tdEqYYDgmv/dNqfT/OkYUHNah2Jf8ZL0CAwEAAaOBlTCBkjAfBgNVHSMEGDAWgBROuje6JvS5f3aN0Qk0DRDGjOWHRjBABggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9pcGEtY2EudW5peC5nb3NpeC5uZXQvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUAA4IBAQB+WTlsE5LmEvbfEk/fOlKfwkNv187o/6AtwBxrjvC0D0QobfnxSIgd7R905haHf9fyONYsQKn8mlbghtY3URfGnfYNXJ9ez1pOqoCAlpy5Z5tvDlQMGvVVjk/9pSibTI90noZeMrUE+Tetq45c8ZjFXxcrH4R07xUDRXZg8AXviQMyclUSZbWKsIL7a979Hp13q8sJ8MAod1OhqdP6EOk84AOyRcQuRhv5uEdeDSN4k+4mMSZGnMlKO+0gKnhUIq63/TlW8wp7NhCE+kYdOkF4M0lBYOPE66d/4VdX45soMdp4WphjZMrirarhFJvHpHloUwdoiIFglPvOkvbWndbM I can see that the serial is different but I cannot compare the usercertificate attributes since they are not given in the openssl command output. Shall I just adjust the serial and try again? Jochen On Friday, January 31, 2020 10:29 CET, Florence Blanc-Renaud via FreeIPA-users wrote: This error occurs when IPA framework tries to authenticate to Dogtag CA and it fails. It is using the certificate located in /var/lib/ipa/ra-agent.pem. According to your getcert output, the cert is valid. You will need to check if it is consistent with what is stored in LDAP. Note the values related to the actual certificate: $ cat /var/lib/ipa/ra-agent.pem -BEGIN CERTIFICATE- MII...NSF -END CERTIFICATE- $ openssl x509 -noout -in /var/lib/ipa/ra-agent.pem -serial -subject -issuer -nameopt RFC2253 serial= subject= CN=IPA RA,O= issuer= CN=Certificate Authority,O= Then compare the result with the ldapentry: $ ldapsearch -LLL -o ldif-wrap=no -x -D "cn=directory manager" -W \ -b uid=ipara,ou=people,o=ipaca dn description usercertificate Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca description: 2;23;CN=Certificate Authority,O=;CN=IPA RA,O= usercertificate:: MII..NSF usercertificate:: MII...tKR/c 1/ The usercertificate attribute may contain multiple values. Make sure that one of them corresponds to the value from the file /var/lib/ipa/ra-agent.pem. 2/ The description attribute must contain 2;;; If it's not the case you can use ldapmodify to update the ldap entry with what is expected. HTH, flo > 2020-01-30T22:45:09Z DEBUG The ipa-server-upgrade command failed, > exception: RemoteRetrieveError: Failed to authenticate to CA REST API > 2020-01-30T22:45:09Z ERROR Unexpected error - see > /var/log/ipaupgrade.log for details: > RemoteRetrieveError: Failed to authenticate to CA REST API > 2020-01-30T22:45:09Z ERROR The
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On 1/20/20 9:39 AM, Jochen Demmer via FreeIPA-users wrote: I suffer the exact same problem and already tried to upgrade twice but every time the update fails. The ldap server does not listen when I check with ss or netstat. I reverted back to Fedora 30 with snapshots every time. Hi, can you paste the logs from /var/logs/ipaupgrade.log? We would need the full logs as the error may differ between a first run and a second run. When the packages are upgraded, the script ipa-server-upgrade is called and starts by disabling the LDAP server ports to avoid any LDAP operation during the upgrade. Then the script performs its duty, and re-enables the port. If there is an untrapped failure before the ports are re-enabled, or the user repeatedly presses CTRL-C, we sometimes end up in a situation where the ports are still disabled (please see ticket https://pagure.io/freeipa/issue/7534) after the ipa-server-upgrade script exits. If the user re-runs ipa-server-upgrade at this point, the script output will be completely different but will not give us any hint related to the original failure root cause. That's why we need the full logs. If you are in a situation where the LDAP server isn't listening: 0. stop IPA with ipactl stop 1. edit /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif 2. set nsslapd-port to 389 3. set nsslapd-security to on 4. set nsslapd-global-backend-lock to off (if you have this attribute at all) 5. restart IPA with ipactl start If the services are able to restart at this point, try to run ipa-server-upgrade and provide full logs. HTH, flo Can someone help me to work this around. The OP writes of an IP that changed but mine didn't. Where can I find a clue why ldap does not listen? Jochen ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
- Original Message - > From: "Wulf C. Krueger via FreeIPA-users" > > To: freeipa-users@lists.fedorahosted.org > Cc: "Wulf C. Krueger" > Sent: Sunday, November 10, 2019 10:02:08 AM > Subject: [Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) > fails to start > > On 2019-11-02 13:47, Wulf C. Krueger wrote: > > my FreeIPA installation was working well on Fedora 30. After upgrading > > to F31, though, it fails to start: > > For posterity's sake as well as that of anyone facing the same issue: > > For some reason, the IP of the host FreeIPA runs on, changed which, > admittedly, can upset the most mild-mannered server. Especially if the > local DNS doesn't get updated either. > > I didn't notice it because the FreeIPA host is behind a reverse proxy. Sorry we couldn't be of more help, but glad you figured it out. :) Does this mean you had IPA and LDAP running on separate servers? Seems weird that it'd fail in Dogtag with: 2019-11-05 11:19:33 [main] FINE: LdapBoundConnection: Connecting to ipa.mailstation.de:636 with client cert auth 2019-11-05 11:19:33 [main] FINE: ldapconn/PKISocketFactory.makeSSLSocket: begins 2019-11-05 11:19:33 [main] SEVERE: Unable to create socket: java.net.ConnectException: Connection refused (Connection refused) If the IP changed and you were connecting to IPA via that DNS entry. - Alex > > Best regards, Wulf > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On 2019-11-02 13:47, Wulf C. Krueger wrote: my FreeIPA installation was working well on Fedora 30. After upgrading to F31, though, it fails to start: For posterity's sake as well as that of anyone facing the same issue: For some reason, the IP of the host FreeIPA runs on, changed which, admittedly, can upset the most mild-mannered server. Especially if the local DNS doesn't get updated either. I didn't notice it because the FreeIPA host is behind a reverse proxy. Best regards, Wulf ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On 2019-11-05 13:47, Wulf C. Krueger via FreeIPA-users wrote: I've tried starting FreeIPA again and have uploaded the resulting new logs: https://mailstation.de/ipa-logs/new/ Well, since there don't seem to be any ideas how to salvage that installation (logs still available in the location mentioned above), is there a way to at least recover its data and move that to a new installation? Best regards, Wulf ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hello Alex, On 2019-11-04 18:20, Alex Scheel via FreeIPA-users wrote: 2019-11-02T10:57:00Z DEBUG stderr=Job for pki-tomcatd@pki-tomcat.service failed because a timeout was exceeded. See "systemctl status pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details. However, the pki-tomcat-ca-debug.2019-11-02.log you posted doesn't have any entries from around this time. That's weird - it should have been in there. Maybe I've missed a log; in order to fix that, I've tried starting FreeIPA again and have uploaded the resulting new logs: https://mailstation.de/ipa-logs/new/ Unfortunately, I basically only understand that the connection to LDAP fails but I don't understand why. Best regards, Wulf ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Wulf, Along these lines -- in ipaupgrade.log, I see: 2019-11-02T10:55:29Z DEBUG args=['/bin/systemctl', 'start', 'pki-tomcatd@pki-tomcat.service'] 2019-11-02T10:57:00Z DEBUG Process finished, return code=1 2019-11-02T10:57:00Z DEBUG stdout= 2019-11-02T10:57:00Z DEBUG stderr=Job for pki-tomcatd@pki-tomcat.service failed because a timeout was exceeded. See "systemctl status pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details. However, the pki-tomcat-ca-debug.2019-11-02.log you posted doesn't have any entries from around this time. Additionally, though perhaps a red herring, I see: 2019-11-02T10:55:29Z DEBUG Failed to check CA status: cannot connect to 'http://ipa.mailstation.de:8080/ca/admin/ca/getStatus': [Errno 111] Connection refused So perhaps the Tomcat debug logs from 10:50 -> 11:00 might be a good place to start? Maybe there's an hour shift in there, but I assume the logs would have similar timestamps since they're on the same system. - Alex - Original Message - > From: "Alexander Bokovoy via FreeIPA-users" > > To: "Wulf C. Krueger" > Cc: "FreeIPA users list" , "Alex > Scheel" , "Alexander > Bokovoy" > Sent: Monday, November 4, 2019 11:50:41 AM > Subject: [Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) > fails to start > > On ma, 04 marras 2019, Wulf C. Krueger wrote: > >Hello Alex, > > > >On 2019-11-04 16:49, Alex Scheel via FreeIPA-users wrote: > >>These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to > >>initalize > >>just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems > >>like a bug > >>in the LDAPProfileSubsystem of Dogtag. > > > >Thanks for chiming in - any suggestions on how to proceed? > > > >I'm wondering why the LDAP server *only* seems to be listening on that > >socket (cf. log) instead of (or in addition to) ports 389/636. > > I think it is a red herring. ipa-server-upgrade switches off 389/636 > during upgrade to prevent inconsistency leaking out for replication. If > something unexpected happens during the upgrade when these ports were > disabled, they might be left disabled. The question is why it was left > in a state it was left in. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On ma, 04 marras 2019, Wulf C. Krueger wrote: Hello Alex, On 2019-11-04 16:49, Alex Scheel via FreeIPA-users wrote: These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to initalize just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems like a bug in the LDAPProfileSubsystem of Dogtag. Thanks for chiming in - any suggestions on how to proceed? I'm wondering why the LDAP server *only* seems to be listening on that socket (cf. log) instead of (or in addition to) ports 389/636. I think it is a red herring. ipa-server-upgrade switches off 389/636 during upgrade to prevent inconsistency leaking out for replication. If something unexpected happens during the upgrade when these ports were disabled, they might be left disabled. The question is why it was left in a state it was left in. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hello Alex, On 2019-11-04 16:49, Alex Scheel via FreeIPA-users wrote: These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to initalize just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems like a bug in the LDAPProfileSubsystem of Dogtag. Thanks for chiming in - any suggestions on how to proceed? I'm wondering why the LDAP server *only* seems to be listening on that socket (cf. log) instead of (or in addition to) ports 389/636. Best regards, Wulf ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On ma, 04 marras 2019, Alex Scheel wrote: - Original Message - From: "Alexander Bokovoy via FreeIPA-users" To: "FreeIPA users list" Cc: "Wulf C. Krueger" , "Alexander Bokovoy" Sent: Sunday, November 3, 2019 4:08:09 AM Subject: [Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start On la, 02 marras 2019, Wulf C. Krueger via FreeIPA-users wrote: >Hello, > >my FreeIPA installation was working well on Fedora 30. After upgrading >to F31, though, it fails to start: > > ># ipactl start >IPA version error: data needs to be upgraded (expected version >'4.8.1-4.fc31', current version '4.8.1-1.fc30') >Automatically running upgrade, for details see /var/log/ipaupgrade.log >Be patient, this may take a few minutes. >Automatic upgrade failed: Update complete >Upgrading the configuration of the IPA services >[Verifying that root certificate is published] >[Migrate CRL publish directory] >CRL tree already moved >IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run >command ipa-server-upgrade manually. >Unexpected error - see /var/log/ipaupgrade.log for details: >CalledProcessError: CalledProcessError(Command ['/bin/systemctl', >'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit >status 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a >timeout was exceeded.\nSee "systemctl status >pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details.\n') >The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for >more information > >See the upgrade log for more details and/or run >/usr/sbin/ipa-server-upgrade again >Aborting ipactl > > >Logs: > >ipaupgrade.log: https://mailstation.de/ipa-logs/ipaupgrade.log >pki-tomcatd@pki-tomcat log: >https://mailstation.de/ipa-logs/pki-tomc...@pki-tomcat.log >pki-tomcat-ca-debug log: >https://mailstation.de/ipa-logs/pki-tomcat-ca-debug.2019-11-02.log > >So it looks like the LDAP server isn't reachable but its log says it's >running: https://mailstation.de/ipa-logs/dir...@mailstation-de.log > >There's nothing listening on ports 389 and 636, though. > >Help would be highly appreciated. This looks like https://bugzilla.redhat.com/show_bug.cgi?id=1766451 Do you have updates-testing repository enabled? It should provide an update for jss package. Alexander, I don't think this is that bug at all. That bug (#1766451) was an issue in JSS with a stacktrace ending in the NativeProxy class, caused by an improvement in NativeProxy. That lead to a member used in the equals(...) comparator to be NULL, which is less than ideal. These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to initalize just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems like a bug in the LDAPProfileSubsystem of Dogtag. Thanks, Alex. I hope you can help then with debugging it? As to #1766451, we seem to hit it in FreeIPA CI regularly. I hope https://bodhi.fedoraproject.org/updates/FEDORA-2019-4129cdf50b will get pushed soon... -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
- Original Message - > From: "Alexander Bokovoy via FreeIPA-users" > > To: "FreeIPA users list" > Cc: "Wulf C. Krueger" , "Alexander Bokovoy" > > Sent: Sunday, November 3, 2019 4:08:09 AM > Subject: [Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) > fails to start > > On la, 02 marras 2019, Wulf C. Krueger via FreeIPA-users wrote: > >Hello, > > > >my FreeIPA installation was working well on Fedora 30. After upgrading > >to F31, though, it fails to start: > > > > > ># ipactl start > >IPA version error: data needs to be upgraded (expected version > >'4.8.1-4.fc31', current version '4.8.1-1.fc30') > >Automatically running upgrade, for details see /var/log/ipaupgrade.log > >Be patient, this may take a few minutes. > >Automatic upgrade failed: Update complete > >Upgrading the configuration of the IPA services > >[Verifying that root certificate is published] > >[Migrate CRL publish directory] > >CRL tree already moved > >IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > >command ipa-server-upgrade manually. > >Unexpected error - see /var/log/ipaupgrade.log for details: > >CalledProcessError: CalledProcessError(Command ['/bin/systemctl', > >'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit > >status 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a > >timeout was exceeded.\nSee "systemctl status > >pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details.\n') > >The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > >more information > > > >See the upgrade log for more details and/or run > >/usr/sbin/ipa-server-upgrade again > >Aborting ipactl > > > > > >Logs: > > > >ipaupgrade.log: https://mailstation.de/ipa-logs/ipaupgrade.log > >pki-tomcatd@pki-tomcat log: > >https://mailstation.de/ipa-logs/pki-tomc...@pki-tomcat.log > >pki-tomcat-ca-debug log: > >https://mailstation.de/ipa-logs/pki-tomcat-ca-debug.2019-11-02.log > > > >So it looks like the LDAP server isn't reachable but its log says it's > >running: https://mailstation.de/ipa-logs/dir...@mailstation-de.log > > > >There's nothing listening on ports 389 and 636, though. > > > >Help would be highly appreciated. > > This looks like https://bugzilla.redhat.com/show_bug.cgi?id=1766451 > Do you have updates-testing repository enabled? It should provide an > update for jss package. Alexander, I don't think this is that bug at all. That bug (#1766451) was an issue in JSS with a stacktrace ending in the NativeProxy class, caused by an improvement in NativeProxy. That lead to a member used in the equals(...) comparator to be NULL, which is less than ideal. These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to initalize just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems like a bug in the LDAPProfileSubsystem of Dogtag. My 2c. - Alex > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hello Wulf, Oh yes, in your case, the slapd directory server is started but seems not listening on 389/636, according to the log file. On another further look, yes, you are right, the stack trace looks different from the one in Pagure. As a side node, I had tried to install the jss rpm from updates-testing channel (according to Bugzilla #1766451). One of the replica server can complete the ipa-server-upgrade but the pki-tomcat failed to function properly. I had mentioned it in another mail: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/4HJSWIJQQYZQXUCEDUNZGPEKMOE7Z3MD/ Best regards, Patrick On Sun, Nov 3, 2019 at 6:16 PM Wulf C. Krueger wrote: > Hello Patrick, > > On 2019-11-02 20:54, Patrick Dung via FreeIPA-users wrote: > > I am having the same problem about three days ago. > > Related thread in: > > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WLBFHI266KKHLF6G2UC4MHR4OLCLR45S/ > > Thanks, I saw that thread while searching but (possibly wrongly) thought > it was a similar but ultimately different problem because as you write > there "I am able to connect to my ldap server port 636 with TLS without > problem." - which I most certainly am not. There's not even anything > listening on 636. > > And the stack traces seem different as well. > > A rather huge difference as well: In the pagure issue, the PKI server is > running whereas mine at least consistently refuses to start. > > Best regards, Wulf > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hello Patrick, On 2019-11-02 20:54, Patrick Dung via FreeIPA-users wrote: I am having the same problem about three days ago. Related thread in: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WLBFHI266KKHLF6G2UC4MHR4OLCLR45S/ Thanks, I saw that thread while searching but (possibly wrongly) thought it was a similar but ultimately different problem because as you write there "I am able to connect to my ldap server port 636 with TLS without problem." - which I most certainly am not. There's not even anything listening on 636. And the stack traces seem different as well. A rather huge difference as well: In the pagure issue, the PKI server is running whereas mine at least consistently refuses to start. Best regards, Wulf ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hello Alexander, On 2019-11-03 10:08, Alexander Bokovoy via FreeIPA-users wrote: This looks like https://bugzilla.redhat.com/show_bug.cgi?id=1766451 Do you have updates-testing repository enabled? It should provide an update for jss package. Thanks for the suggestion! Unfortunately, updating to the newer jss (jss-4.6.2-2.fc31.x86_64) didn't fix my issue. Reading 1766451 it seems to be different from what I'm seeing. Best regards, Wulf ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On la, 02 marras 2019, Wulf C. Krueger via FreeIPA-users wrote: Hello, my FreeIPA installation was working well on Fedora 30. After upgrading to F31, though, it fails to start: # ipactl start IPA version error: data needs to be upgraded (expected version '4.8.1-4.fc31', current version '4.8.1-1.fc30') Automatically running upgrade, for details see /var/log/ipaupgrade.log Be patient, this may take a few minutes. Automatic upgrade failed: Update complete Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] CRL tree already moved IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit status 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a timeout was exceeded.\nSee "systemctl status pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details.\n') The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade again Aborting ipactl Logs: ipaupgrade.log: https://mailstation.de/ipa-logs/ipaupgrade.log pki-tomcatd@pki-tomcat log: https://mailstation.de/ipa-logs/pki-tomc...@pki-tomcat.log pki-tomcat-ca-debug log: https://mailstation.de/ipa-logs/pki-tomcat-ca-debug.2019-11-02.log So it looks like the LDAP server isn't reachable but its log says it's running: https://mailstation.de/ipa-logs/dir...@mailstation-de.log There's nothing listening on ports 389 and 636, though. Help would be highly appreciated. This looks like https://bugzilla.redhat.com/show_bug.cgi?id=1766451 Do you have updates-testing repository enabled? It should provide an update for jss package. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hello Wulf, I am having the same problem about three days ago. Related thread in: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WLBFHI266KKHLF6G2UC4MHR4OLCLR45S/ Looks like the problem is related to https://pagure.io/dogtagpki/issue/3111 I am waiting for the bugfix or new rpm. Best regards, Patrick On Sat, Nov 2, 2019 at 8:47 PM Wulf C. Krueger via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > Hello, > > my FreeIPA installation was working well on Fedora 30. After upgrading > to F31, though, it fails to start: > > > # ipactl start > IPA version error: data needs to be upgraded (expected version > '4.8.1-4.fc31', current version '4.8.1-1.fc30') > Automatically running upgrade, for details see /var/log/ipaupgrade.log > Be patient, this may take a few minutes. > Automatic upgrade failed: Update complete > Upgrading the configuration of the IPA services > [Verifying that root certificate is published] > [Migrate CRL publish directory] > CRL tree already moved > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > command ipa-server-upgrade manually. > Unexpected error - see /var/log/ipaupgrade.log for details: > CalledProcessError: CalledProcessError(Command ['/bin/systemctl', > 'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit status > 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a timeout was > exceeded.\nSee "systemctl status pki-tomcatd@pki-tomcat.service" and > "journalctl -xe" for details.\n') > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information > > See the upgrade log for more details and/or run > /usr/sbin/ipa-server-upgrade again > Aborting ipactl > > > Logs: > > ipaupgrade.log: https://mailstation.de/ipa-logs/ipaupgrade.log > pki-tomcatd@pki-tomcat log: > https://mailstation.de/ipa-logs/pki-tomc...@pki-tomcat.log > pki-tomcat-ca-debug log: > https://mailstation.de/ipa-logs/pki-tomcat-ca-debug.2019-11-02.log > > So it looks like the LDAP server isn't reachable but its log says it's > running: https://mailstation.de/ipa-logs/dir...@mailstation-de.log > > There's nothing listening on ports 389 and 636, though. > > Help would be highly appreciated. > > Best regards, Wulf > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
