"certmonger.py", line 317, in request_and_wait_for_cert

[lejeczek]

hi

not an python nor ipa expert here, looking at certmonger.py

what does such an error indicate? :

ipa         : DEBUG    certmonger request is in state 
dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1)
ipa         : DEBUG    certmonger request is in state 
dbus.String(u'CA_UNREACHABLE', variant_level=1)
ipa         : DEBUG    Traceback (most recent call last):
   File 
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 504, in start_creation
     run_step(full_msg, method)
   File 
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 494, in run_step
     method()
   File 
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", 
line 824, in __enable_ssl
     post_command=cmd)
   File 
"/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py", 
line 317, in request_and_wait_for_cert
     raise RuntimeError("Certificate issuance failed 
({})".format(state))
RuntimeError: Certificate issuance failed (CA_UNREACHABLE)

ipa         : DEBUG      [error] RuntimeError: Certificate 
issuance failed (CA_UNREACHABLE)
   [error] RuntimeError: Certificate issuance failed 
(CA_UNREACHABLE)
-- end
Is this about local replica candidate or remote ipa server?
thanks, L.

[Rob Crittenden]

lejeczek via FreeIPA-users wrote:
> hi
>
> not an python nor ipa expert here, looking at certmonger.py
>
> what does such an error indicate? :
>
> ipa         : DEBUG    certmonger request is in state
> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1)
> ipa         : DEBUG    certmonger request is in state
> dbus.String(u'CA_UNREACHABLE', variant_level=1)
> ipa         : DEBUG    Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 504, in start_creation
>     run_step(full_msg, method)
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 494, in run_step
>     method()
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
> 824, in __enable_ssl
>     post_command=cmd)
>   File "/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py",
> line 317, in request_and_wait_for_cert
>     raise RuntimeError("Certificate issuance failed ({})".format(state))
> RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
>
> ipa         : DEBUG      [error] RuntimeError: Certificate issuance
> failed (CA_UNREACHABLE)
>   [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
> -- end
> Is this about local replica candidate or remote ipa server?

getcert list may provide the host it was trying to contact.

rob

[lejeczek]

On 11/01/18 15:02, Rob Crittenden wrote:
> lejeczek via FreeIPA-users wrote:
> > hi
> >
> > not an python nor ipa expert here, looking at certmonger.py
> >
> > what does such an error indicate? :
> >
> > ipa         : DEBUG    certmonger request is in state
> > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1)
> > ipa         : DEBUG    certmonger request is in state
> > dbus.String(u'CA_UNREACHABLE', variant_level=1)
> > ipa         : DEBUG    Traceback (most recent call last):
> >    File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > line 504, in start_creation
> >      run_step(full_msg, method)
> >    File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > line 494, in run_step
> >      method()
> >    File
> > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
> > 824, in __enable_ssl
> >      post_command=cmd)
> >    File "/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py",
> > line 317, in request_and_wait_for_cert
> >      raise RuntimeError("Certificate issuance failed ({})".format(state))
> > RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
> >
> > ipa         : DEBUG      [error] RuntimeError: Certificate issuance
> > failed (CA_UNREACHABLE)
> >    [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
> > -- end
> > Is this about local replica candidate or remote ipa server?
>
> getcert list may provide the host it was trying to contact.
>
> rob

When replica candidate installation fails I get the above on 
that candidate.
When after a failure, on that would-be replica I do:

$ getcert list
Number of certificates and requests being tracked: 1.
Request ID '20180111154743':
     status: CA_UNREACHABLE
     ca-error: Server at

It points at itself, own FQDN.

Should I be rather watching server's end?
How to troubleshoot it?

thanks,L.

[Florence Blanc-Renaud]

On 01/11/2018 05:16 PM, lejeczek via FreeIPA-users wrote:
> On 11/01/18 15:02, Rob Crittenden wrote:
> > lejeczek via FreeIPA-users wrote:
> > > hi
> > >
> > > not an python nor ipa expert here, looking at certmonger.py
> > >
> > > what does such an error indicate? :
> > >
> > > ipa         : DEBUG    certmonger request is in state
> > > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1)
> > > ipa         : DEBUG    certmonger request is in state
> > > dbus.String(u'CA_UNREACHABLE', variant_level=1)
> > > ipa         : DEBUG    Traceback (most recent call last):
> > >    File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > > line 504, in start_creation
> > >      run_step(full_msg, method)
> > >    File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > > line 494, in run_step
> > >      method()
> > >    File
> > > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
> > > 824, in __enable_ssl
> > >      post_command=cmd)
> > >    File "/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py",
> > > line 317, in request_and_wait_for_cert
> > >      raise RuntimeError("Certificate issuance failed 
> > > ({})".format(state))
> > > RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
> > >
> > > ipa         : DEBUG      [error] RuntimeError: Certificate issuance
> > > failed (CA_UNREACHABLE)
> > >    [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
> > > -- end
> > > Is this about local replica candidate or remote ipa server?
> >
> > getcert list may provide the host it was trying to contact.
> >
> > rob
>
> When replica candidate installation fails I get the above on that 
> candidate.
> When after a failure, on that would-be replica I do:
>
> $ getcert list
> Number of certificates and requests being tracked: 1.
> Request ID '20180111154743':
>      status: CA_UNREACHABLE
>      ca-error: Server at
>
> It points at itself, own FQDN.
>
> Should I be rather watching server's end?
> How to troubleshoot it?
>
> thanks,L.
> _______________________________________________
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

Hi,

certmonger tries first to connect to the IPA server defined 
/etc/ipa/default.conf, but if this one fails then it will try to locate 
another IPA master (see the man page for ipa-submit(8), especially the 
section about -h option).

During a replica installation, certmonger will send a cert_request call 
to the IPA master. You should be able to find a trace in 
/var/log/httpd/error_log on the master, with a line containing the 
string cert_request and the call parameters.
In turn, IPA master contacts Dogtag in order to generate the certificate 
for the replica. The logs are in /var/log/pki/pi-tomcat/ca/debug.

Can you see any cert_request log in the master? If not, then certmonger 
(from the would-be replica) was not able to contact the master. In this 
case I would check the output of:
$ dig -t srv _ldap._tcp.<ipa domain>

to make sure which servers certmonger tried to contact.

HTH,
Flo

[lejeczek]

On 11/01/18 17:02, Florence Blanc-Renaud wrote:
> On 01/11/2018 05:16 PM, lejeczek via FreeIPA-users wrote:
> > On 11/01/18 15:02, Rob Crittenden wrote:
> > > lejeczek via FreeIPA-users wrote:
> > > > hi
> > > >
> > > > not an python nor ipa expert here, looking at 
> > > > certmonger.py
> > > >
> > > > what does such an error indicate? :
> > > >
> > > > ipa         : DEBUG    certmonger request is in state
> > > > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', 
> > > > variant_level=1)
> > > > ipa         : DEBUG    certmonger request is in state
> > > > dbus.String(u'CA_UNREACHABLE', variant_level=1)
> > > > ipa         : DEBUG    Traceback (most recent call last):
> > > >    File 
> > > > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > > >
> > > > line 504, in start_creation
> > > >      run_step(full_msg, method)
> > > >    File 
> > > > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > > >
> > > > line 494, in run_step
> > > >      method()
> > > >    File
> > > > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", 
> > > > line
> > > > 824, in __enable_ssl
> > > >      post_command=cmd)
> > > >    File 
> > > > "/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py",
> > > >
> > > > line 317, in request_and_wait_for_cert
> > > >      raise RuntimeError("Certificate issuance failed 
> > > > ({})".format(state))
> > > > RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
> > > >
> > > > ipa         : DEBUG      [error] RuntimeError: 
> > > > Certificate issuance
> > > > failed (CA_UNREACHABLE)
> > > >    [error] RuntimeError: Certificate issuance failed 
> > > > (CA_UNREACHABLE)
> > > > -- end
> > > > Is this about local replica candidate or remote ipa 
> > > > server?
> > >
> > > getcert list may provide the host it was trying to contact.
> > >
> > > rob
> >
> > When replica candidate installation fails I get the above 
> > on that candidate.
> > When after a failure, on that would-be replica I do:
> >
> > $ getcert list
> > Number of certificates and requests being tracked: 1.
> > Request ID '20180111154743':
> >      status: CA_UNREACHABLE
> >      ca-error: Server at
> >
> > It points at itself, own FQDN.
> >
> > Should I be rather watching server's end?
> > How to troubleshoot it?
> >
> > thanks,L.
> > _______________________________________________
> > FreeIPA-users mailing list -- 
> > [e-mail]
> > To unsubscribe send an email to 
> > [e-mail]
>
> Hi,

thanks Flo, I tried my best to follow clues you gave and 
find some more, I replied in that other topic CA_UNREACHABLE.
> certmonger tries first to connect to the IPA server 
> defined /etc/ipa/default.conf, but if this one fails then 
> it will try to locate another IPA master (see the man page 
> for ipa-submit(8), especially the section about -h option).
>
> During a replica installation, certmonger will send a 
> cert_request call to the IPA master. You should be able to 
> find a trace in /var/log/httpd/error_log on the master, 
> with a line containing the string cert_request and the 
> call parameters.

in httpd/error_log I see:

[Thu Jan 11 17:20:53.475973 2018] [:error] [pid 2701892] 
ipa: INFO: [jsonserver_kerb] host/dzien.priv.
[e-mail].x: ping(): 
SUCCESS
[Thu Jan 11 17:20:53.527232 2018] [:error] [pid 2701893] 
ipa: INFO: [jsonserver_kerb] host/dzien.priv.
[e-mail].x: 
env((u'version',)): SUCCESS
[Thu Jan 11 17:20:53.573580 2018] [:error] [pid 2701892] 
ipa: INFO: [jsonserver_kerb] host/dzien.priv.
[e-mail].x: 
env((u'fips_mode',)): SUCCESS
[Thu Jan 11 17:21:04.406246 2018] [:error] [pid 2701893] 
ipa: INFO: [jsonserver_kerb] [e-mail].
xx.PRIVATE.xx.xx.x: ping(): SUCCESS
[Thu Jan 11 17:21:04.444042 2018] [:error] [pid 2701892] 
ipa: INFO: [jsonserver_kerb] [e-mail].
xx.PRIVATE.xx.xx.x: ping/1(version=u'2.228'): SUCCESS
[Thu Jan 11 17:21:04.900349 2018] [:error] [pid 2701893] 
ipa: INFO: [jsonserver_kerb] [e-mail].
xx.PRIVATE.xx.xx.x: 
server_conncheck(u'swir.priv.xx.xx.priv.xx.xx.x', 
u'dzien.priv.xx.
xx.priv.xx.xx.x', version=u'2.162'): SUCCESS
[Thu Jan 11 17:21:40.832678 2018] [auth_gssapi:error] [pid 
2702831] [client 10.5.6.17:47072] NO AUTH DATA
  Client did not send any authentication headers, referer: 
https://swir.priv.xx.xx.priv.xx.xx.x
/ipa/xml
[Thu Jan 11 17:21:40.913393 2018] [:error] [pid 2701892] 
ipa: INFO: [xmlserver] 
host/[e-mail].x: 
cert_request(u'MIIEWTCCA0ECAQAwYDErMCkGA1UEChMiUFJJVkFURS5DQ05SLkNFQi5QUklWQVRFLkNBTS5BQy5VSzExMC8GA1UEAxMoZHppZW4ucHJpdmF0ZS5jY25yLmNlYi5wcml2YXRlLmNhbS5hYy51azCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK81UM4J4041W+ujikOQrplTcUjjmMHOWkE8YbVwjZvH2AYhP7tn+jZ7GYWZuv//j4tfFEEiIyV94hL85xjhXCwkLdR1R6CaswD1SpwOkQGOOICol1aV2tX1+o9Q3Q4gDLMBvxX3+s+l39l7dgDqj6ZaueH8E7H+W9Oj+w3+E8mR5Zy/kG6X6WNtwbqyf6fZwshRO26O4aUNlxMDpeLN5mDoRWBeeHiWoFBXwYXqysHoVLFN4urpH7wHKSEkdW7Vaj/1HXGutOV5HsaBqeGzdCiwlrBFDE9maU7HhyBxxGEit11ejGxoP2hjxyO0l0tfBuqJjBkGZDvgB3501jGgHQ8CAwEAAaCCAbIwJQYJKoZIhvcNAQkUMRgeFgBTAGUAcgB2AGUAcgAtAEMAZQByAHQwggGHBgkqhkiG9w0BCQ4xggF4MIIBdDCCAQwGA1UdEQEBAASCAQAwgf2CKGR6aWVuLnByaXZhdGUuY2Nuci5jZWIucHJpdmF0ZS5jYW0uYWMudWugYAYKKwYBBAGCNxQCA6BSDFBsZGFwL2R6aWVuLnByaXZhdGUuY2Nuci5jZWIucHJpdmF0ZS5jYW0uYWMudWtAUFJJVkFURS5DQ05SLkNFQi5QUklWQVRFLkNBTS5BQy5VS6BvBgYrBgEFAgKgZTBjoCQbIlBSSVZBVEUuQ0NOUi5DRUIuUFJJVkFURS5DQU0uQUMuVUuhOzA5oAMCAQGhMjAwGwRsZGFwGyhkemllbi5wcml2YXRlLmNjbnIuY2ViLnByaXZhdGUuY2FtLmFjLnVrMAwGA1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFA1WfK69+iWx/R7b8kWpd/4M3QtrMDIGCSsGAQQBgjcUAgEBAAQiHiAAYwBhAEkAUABBAHMAZQByAHYAaQBjAGUAQwBlAHIAdDANBgkqhkiG9w0BAQsFAAOCAQEAXBhrwG29M+UEWZsWjIJWRHEQ6bAdpTWJVP7P9eXu11Krd/VrCb/qgz7/68GWkKCDpINLB8P7SGWoUwI4zjn1YJNn9jyVELryLn4MHfQ/3W3mVZcK6FPtRqmpwZ6q0TEG/ZpBftWlpI8AkhruGrx8bJ/pGo3UJgY/5QajMjsuuysvoukVxeYmQJDCH36Hdfw6+hYg3XQfmJ2WgLjnVaA0v3e9gKYf0gObwSbKF1ZqF6pVw9D9h8BgTITB8PO6aQvYCeWY6H9w/Dc3V77pPubTrScN6JJFZEyTWPK2GijpO7E+4nV5bnHNlJ4LpAZRYH0lzcVok/YNsRv8bupoFoChNQ==', 
profile_id=u'caIPAserviceCert', 
principal=u'ldap/[e-mail].x', 
add=True, version=u'2.51'): NetworkError

dzien is a replica candidate, swir is the server.
Before I'll go after other logs, does this one above is more 
revealing?
Pokes eyes is that last line "NetworkError" - but does it 
actually say?

many thanks, L.
> In turn, IPA master contacts Dogtag in order to generate 
> the certificate for the replica. The logs are in 
> /var/log/pki/pi-tomcat/ca/debug.
>
> Can you see any cert_request log in the master? If not, 
> then certmonger (from the would-be replica) was not able 
> to contact the master. In this case I would check the 
> output of:
> $ dig -t srv _ldap._tcp.<ipa domain>
>
> to make sure which servers certmonger tried to contact.
>
> HTH,
> Flo

[Florence Blanc-Renaud]

On 01/11/2018 06:37 PM, lejeczek via FreeIPA-users wrote:
> On 11/01/18 17:02, Florence Blanc-Renaud wrote:
> > On 01/11/2018 05:16 PM, lejeczek via FreeIPA-users wrote:
> > > On 11/01/18 15:02, Rob Crittenden wrote:
> > > > lejeczek via FreeIPA-users wrote:
> > > > > hi
> > > > >
> > > > > not an python nor ipa expert here, looking at certmonger.py
> > > > >
> > > > > what does such an error indicate? :
> > > > >
> > > > > ipa         : DEBUG    certmonger request is in state
> > > > > dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1)
> > > > > ipa         : DEBUG    certmonger request is in state
> > > > > dbus.String(u'CA_UNREACHABLE', variant_level=1)
> > > > > ipa         : DEBUG    Traceback (most recent call last):
> > > > >    File 
> > > > > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > > > > line 504, in start_creation
> > > > >      run_step(full_msg, method)
> > > > >    File 
> > > > > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> > > > > line 494, in run_step
> > > > >      method()
> > > > >    File
> > > > > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", 
> > > > > line
> > > > > 824, in __enable_ssl
> > > > >      post_command=cmd)
> > > > >    File 
> > > > > "/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py",
> > > > > line 317, in request_and_wait_for_cert
> > > > >      raise RuntimeError("Certificate issuance failed 
> > > > > ({})".format(state))
> > > > > RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
> > > > >
> > > > > ipa         : DEBUG      [error] RuntimeError: Certificate issuance
> > > > > failed (CA_UNREACHABLE)
> > > > >    [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
> > > > > -- end
> > > > > Is this about local replica candidate or remote ipa server?
> > > >
> > > > getcert list may provide the host it was trying to contact.
> > > >
> > > > rob
> > >
> > > When replica candidate installation fails I get the above on that 
> > > candidate.
> > > When after a failure, on that would-be replica I do:
> > >
> > > $ getcert list
> > > Number of certificates and requests being tracked: 1.
> > > Request ID '20180111154743':
> > >      status: CA_UNREACHABLE
> > >      ca-error: Server at
> > >
> > > It points at itself, own FQDN.
> > >
> > > Should I be rather watching server's end?
> > > How to troubleshoot it?
> > >
> > > thanks,L.
> > > _______________________________________________
> > > FreeIPA-users mailing list -- [e-mail]
> > > To unsubscribe send an email to 
> > > [e-mail]
> >
> > Hi,
>
> thanks Flo, I tried my best to follow clues you gave and find some more, 
> I replied in that other topic CA_UNREACHABLE.
> > certmonger tries first to connect to the IPA server defined 
> > /etc/ipa/default.conf, but if this one fails then it will try to 
> > locate another IPA master (see the man page for ipa-submit(8), 
> > especially the section about -h option).
> >
> > During a replica installation, certmonger will send a cert_request 
> > call to the IPA master. You should be able to find a trace in 
> > /var/log/httpd/error_log on the master, with a line containing the 
> > string cert_request and the call parameters.
>
> in httpd/error_log I see:
>
> [Thu Jan 11 17:20:53.475973 2018] [:error] [pid 2701892] ipa: INFO: 
> [jsonserver_kerb] host/dzien.priv.
> [e-mail].x: ping(): SUCCESS
> [Thu Jan 11 17:20:53.527232 2018] [:error] [pid 2701893] ipa: INFO: 
> [jsonserver_kerb] host/dzien.priv.
> [e-mail].x: env((u'version',)): 
> SUCCESS
> [Thu Jan 11 17:20:53.573580 2018] [:error] [pid 2701892] ipa: INFO: 
> [jsonserver_kerb] host/dzien.priv.
> [e-mail].x: env((u'fips_mode',)): 
> SUCCESS
> [Thu Jan 11 17:21:04.406246 2018] [:error] [pid 2701893] ipa: INFO: 
> [jsonserver_kerb] [e-mail].
> xx.PRIVATE.xx.xx.x: ping(): SUCCESS
> [Thu Jan 11 17:21:04.444042 2018] [:error] [pid 2701892] ipa: INFO: 
> [jsonserver_kerb] [e-mail].
> xx.PRIVATE.xx.xx.x: ping/1(version=u'2.228'): SUCCESS
> [Thu Jan 11 17:21:04.900349 2018] [:error] [pid 2701893] ipa: INFO: 
> [jsonserver_kerb] [e-mail].
> xx.PRIVATE.xx.xx.x: server_conncheck(u'swir.priv.xx.xx.priv.xx.xx.x', 
> u'dzien.priv.xx.
> xx.priv.xx.xx.x', version=u'2.162'): SUCCESS
> [Thu Jan 11 17:21:40.832678 2018] [auth_gssapi:error] [pid 2702831] 
> [client 10.5.6.17:47072] NO AUTH DATA
>   Client did not send any authentication headers, referer: 
> https://swir.priv.xx.xx.priv.xx.xx.x
> /ipa/xml
> [Thu Jan 11 17:21:40.913393 2018] [:error] [pid 2701892] ipa: INFO: 
> [xmlserver] 
> host/[e-mail].x: 
> cert_request(u'MIIEWTCCA0ECAQAwYDErMCkGA1UEChMiUFJJVkFURS5DQ05SLkNFQi5QUklWQVRFLkNBTS5BQy5VSzExMC8GA1UEAxMoZHppZW4ucHJpdmF0ZS5jY25yLmNlYi5wcml2YXRlLmNhbS5hYy51azCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK81UM4J4041W+ujikOQrplTcUjjmMHOWkE8YbVwjZvH2AYhP7tn+jZ7GYWZuv//j4tfFEEiIyV94hL85xjhXCwkLdR1R6CaswD1SpwOkQGOOICol1aV2tX1+o9Q3Q4gDLMBvxX3+s+l39l7dgDqj6ZaueH8E7H+W9Oj+w3+E8mR5Zy/kG6X6WNtwbqyf6fZwshRO26O4aUNlxMDpeLN5mDoRWBeeHiWoFBXwYXqysHoVLFN4urpH7wHKSEkdW7Vaj/1HXGutOV5HsaBqeGzdCiwlrBFDE9maU7HhyBxxGEit11ejGxoP2hjxyO0l0tfBuqJjBkGZDvgB3501jGgHQ8CAwEAAaCCAbIwJQYJKoZIhvcNAQkUMRgeFgBTAGUAcgB2AGUAcgAtAEMAZQByAHQwggGHBgkqhkiG9w0BCQ4xggF4MIIBdDCCAQwGA1UdEQEBAASCAQAwgf2CKGR6aWVuLnByaXZhdGUuY2Nuci5jZWIucHJpdmF0ZS5jYW0uYWMudWugYAYKKwYBBAGCNxQCA6BSDFBsZGFwL2R6aWVuLnByaXZhdGUuY2Nuci5jZWIucHJpdmF0ZS5jYW0uYWMudWtAUFJJVkFURS5DQ05SLkNFQi5QUklWQVRFLkNBTS5BQy5VS6BvBgYrBgEFAgKgZTBjoCQbIlBSSVZBVEUuQ0NOUi5DRUIuUFJJVkFURS5DQU0uQUMuVUuhOzA5oAMCAQGhMjAwGwRsZGFwGyhkemllbi5wcml2YXRlLmNjbnIuY2ViLnByaXZhdGUuY2FtLmFjLnVrMAwGA1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFA1WfK69+iWx/R7b8kWpd/4M3QtrMDIGCSsGAQQBgjcUAgEBAAQiHiAAYwBhAEkAUABBAHMAZQByAHYAaQBjAGUAQwBlAHIAdDANBgkqhkiG9w0BAQsFAAOCAQEAXBhrwG29M+UEWZsWjIJWRHEQ6bAdpTWJVP7P9eXu11Krd/VrCb/qgz7/68GWkKCDpINLB8P7SGWoUwI4zjn1YJNn9jyVELryLn4MHfQ/3W3mVZcK6FPtRqmpwZ6q0TEG/ZpBftWlpI8AkhruGrx8bJ/pGo3UJgY/5QajMjsuuysvoukVxeYmQJDCH36Hdfw6+hYg3XQfmJ2WgLjnVaA0v3e9gKYf0gObwSbKF1ZqF6pVw9D9h8BgTITB8PO6aQvYCeWY6H9w/Dc3V77pPubTrScN6JJFZEyTWPK2GijpO7E+4nV5bnHNlJ4LpAZRYH0lzcVok/YNsRv8bupoFoChNQ==', 
> profile_id=u'caIPAserviceCert', 
> principal=u'ldap/[e-mail].x', 
> add=True, version=u'2.51'): NetworkError

To have more information, you can start the master in debug mode:
- edit (or create if it does not exist) /etc/ipa/server.conf and add the 
following:
[global]
debug = True
- restart httpd with
$ systemctl restart httpd

If the replica installation triggers this type of log in 
/var/log/httpd/error_log:

[...date...] [:error] [pid 9337] ipa: INFO: [xmlserver] 
host/[e-mail]: 
cert_request(u'MII...MJUs6', profile_id=u'caIPAserviceCert', 
principal=u'ldap/[e-mail]', add=True, 
version=u'2.51'): NetworkError
[...date...] [:error] [pid 9337] ipa: DEBUG: response: NetworkError: 
cannot connect to 
'https://master.ipadomain.com:443/ca/rest/account/login': [Errno 13] 
Permission denied

then the problem you are seeing is probably BZ 14852017 [RFE] If the 
umask is too restrictive the installation won't work [1]

Did you install the master with a umask different from 022? In this 
case, some configuration files are probably not accessible by non-root 
user, and the httpd server - running as apache - cannot read files 
needed to establish the secure connection to dogtag.

You can try to change the permissions for /etc/ipa/ca.crt and 
/var/lib/ipa/ra-agent.{key|pem} on the master:
$ chmod 444 /etc/ipa/ca.crt
$ chmod 440 /var/lib/ipa/ra-agent.*

and re-try the replica installation.

HTH,
Flo

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1485217
> dzien is a replica candidate, swir is the server.
> Before I'll go after other logs, does this one above is more revealing?
> Pokes eyes is that last line "NetworkError" - but does it actually say?
>
> many thanks, L.
> > In turn, IPA master contacts Dogtag in order to generate the 
> > certificate for the replica. The logs are in 
> > /var/log/pki/pi-tomcat/ca/debug.
> >
> > Can you see any cert_request log in the master? If not, then 
> > certmonger (from the would-be replica) was not able to contact the 
> > master. In this case I would check the output of:
> > $ dig -t srv _ldap._tcp.<ipa domain>
> >
> > to make sure which servers certmonger tried to contact.
> >
> > HTH,
> > Flo
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[lejeczek]

On 11/01/18 18:55, Florence Blanc-Renaud wrote:
> then the problem you are seeing is probably BZ 14852017 
> [RFE] If the umask is too restrictive the installation 
> won't work [1]
>
> Did you install the master with a umask different from 
> 022? In this case, some configuration files are probably 
> not accessible by non-root user, and the httpd server - 
> running as apache - cannot read files needed to establish 
> the secure connection to dogtag.
>
> You can try to change the permissions for /etc/ipa/ca.crt 
> and /var/lib/ipa/ra-agent.{key|pem} on the master:
> $ chmod 444 /etc/ipa/ca.crt
> $ chmod 440 /var/lib/ipa/ra-agent.*
>
> and re-try the replica installation.
>
> HTH,
> Flo

I'm double posting.. beware
Jesus freaking Christ.. (this comes after I produced a whole 
litany of of bad words in my own language), sorry.
It almost drove me insane! no, really!

all these problems, all these errors, all because of my 
root's umask 027
Now having replica installed, I'll see how two servers 
behave in my simple domain.

Guys, make it a very first check in installer code and make 
that installer fail, and.. push out a new release with that 
little fix like... yesterday(do not wait till it's properly 
fixed) You can still save lives!

[Alexander Bokovoy]

On pe, 12 tammi 2018, lejeczek via FreeIPA-users wrote:
> On 11/01/18 18:55, Florence Blanc-Renaud wrote:
> > then the problem you are seeing is probably BZ 14852017 [RFE] If the 
> > umask is too restrictive the installation won't work [1]
> >
> > Did you install the master with a umask different from 022? In this 
> > case, some configuration files are probably not accessible by 
> > non-root user, and the httpd server - running as apache - cannot 
> > read files needed to establish the secure connection to dogtag.
> >
> > You can try to change the permissions for /etc/ipa/ca.crt and 
> > /var/lib/ipa/ra-agent.{key|pem} on the master:
> > $ chmod 444 /etc/ipa/ca.crt
> > $ chmod 440 /var/lib/ipa/ra-agent.*
> >
> > and re-try the replica installation.
> >
> > HTH,
> > Flo
>
> I'm double posting.. beware
> Jesus freaking Christ.. (this comes after I produced a whole litany of 
> of bad words in my own language), sorry.
> It almost drove me insane! no, really!
>
> all these problems, all these errors, all because of my root's umask 
> 027
> Now having replica installed, I'll see how two servers behave in my 
> simple domain.
>
> Guys, make it a very first check in installer code and make that 
> installer fail, and.. push out a new release with that little fix 
> like... yesterday(do not wait till it's properly fixed) You can still 
> save lives!

There is https://pagure.io/freeipa/issue/7193 for that. Unfortunately,
it is not going to get into next RHEL update due to timing issues.

A patch is welcomed.

[lejeczek]

On 12/01/18 12:32, Alexander Bokovoy wrote:
> On pe, 12 tammi 2018, lejeczek via FreeIPA-users wrote:
> > On 11/01/18 18:55, Florence Blanc-Renaud wrote:
> > > then the problem you are seeing is probably BZ 14852017 
> > > [RFE] If the umask is too restrictive the installation 
> > > won't work [1]
> > >
> > > Did you install the master with a umask different from 
> > > 022? In this case, some configuration files are probably 
> > > not accessible by non-root user, and the httpd server - 
> > > running as apache - cannot read files needed to 
> > > establish the secure connection to dogtag.
> > >
> > > You can try to change the permissions for 
> > > /etc/ipa/ca.crt and /var/lib/ipa/ra-agent.{key|pem} on 
> > > the master:
> > > $ chmod 444 /etc/ipa/ca.crt
> > > $ chmod 440 /var/lib/ipa/ra-agent.*
> > >
> > > and re-try the replica installation.
> > >
> > > HTH,
> > > Flo
> >
> > I'm double posting.. beware
> > Jesus freaking Christ.. (this comes after I produced a 
> > whole litany of of bad words in my own language), sorry.
> > It almost drove me insane! no, really!
> >
> > all these problems, all these errors, all because of my 
> > root's umask 027
> > Now having replica installed, I'll see how two servers 
> > behave in my simple domain.
> >
> > Guys, make it a very first check in installer code and 
> > make that installer fail, and.. push out a new release 
> > with that little fix like... yesterday(do not wait till 
> > it's properly fixed) You can still save lives!
>
> There is https://pagure.io/freeipa/issue/7193 for that. 
> Unfortunately,
> it is not going to get into next RHEL update due to timing 
> issues.
>
> A patch is welcomed.

I'm sure for you guys @devel it won't take more than a blink 
of an eye - just fail that installer for "non-regular" 
umasks(for now at least) - myself? I'd have to learn python ;)
I've struggled, I've wasted a week, and would have given in 
if it wasn't for Flo's help.
Seriously, I'm sure this will save many lives.