[Freeipa-users] RHEL 7 Upgrade experience so far

[Rob Crittenden]

Erinn Looney-Triggs wrote:
> On 08/04/2014 04:01 AM, Martin Kosek wrote:
>> On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
>>>
>>>
>>>
>>>
>>>> Whether related or not I am getting the following in my RHEL
>>>> 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log:
>>>
>>>> [26/Jul/2014:20:23:23 +0000] slapi_ldap_bind - Error: could
>>>> not send startTLS re quest: error -1 (Can't contact LDAP
>>>> server) errno 107 (Transport endpoint is not connected)
>>>> [26/Jul/2014:20:23:23 +0000] NSMMReplicationPlugin -
>>>> agmt="cn=masterAgreement1-i pa2.example.com-pki-ca"
>>>> (ipa2:7389): Replication bind with SIMPLE auth failed: LD AP
>>>> error -1 (Can't contact LDAP server) ((null)) 
>>>> [26/Jul/2014:20:23:37 +0000] slapi_ldap_bind - Error: could
>>>> not send startTLS re quest: error -1 (Can't contact LDAP
>>>> server) errno 107 (Transport endpoint is not connected)
>>>> [26/Jul/2014:20:23:48 +0000] slapi_ldap_bind - Error: could not
>>>> send startTLS re quest: error -1 (Can't contact LDAP server)
>>>> errno 107 (Transport endpoint is not connected)
>>>
>>>> And these errors just continue to be logged.
>>>
>>>> When attempting to run ipa-ca-install -d on the RHEL 7 replica 
>>>> (all other services are on there running fine) I receive the 
>>>> following:
>>>
>>>> ipa         : CRITICAL failed to configure ca instance Command
>>>>  '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned
>>>> non-zero exit status 1 ipa         : DEBUG      File 
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>>>
>>>
>>>
>>>>
> line 638, in run_script
>>>> return_value = main_function()
>>>
>>>> File "/usr/sbin/ipa-ca-install", line 179, in main CA = 
>>>> cainstance.install_replica_ca(config, postinstall=True)
>>>
>>>> File 
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>
>>>
>>>
>>>>
> line 1678, in install_replica_ca
>>>> subject_base=config.subject_base)
>>>
>>>> File 
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>
>>>
>>>
>>>>
> line 478, in configure_instance
>>>> self.start_creation(runtime=210)
>>>
>>>> File 
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>>>>
>>>>
> line 364, in start_creation method()
>>>
>>>> File 
>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>>>
>>>
>>>
>>>>
> line 604, in __spawn_instance
>>>> raise RuntimeError('Configuration of CA failed')
>>>
>>>> ipa         : DEBUG    The ipa-ca-install command failed, 
>>>> exception: RuntimeError: Configuration of CA failed
>>>
>>>> Your system may be partly configured. Run 
>>>> /usr/sbin/ipa-server-install --uninstall to clean up.
>>>
>>>> Configuration of CA failed
>>>
>>>
>>>> So this behavior changed after restarting the IPA service on
>>>> the RHEL 6.5 system.
>>>
>>>> So at this point I have a RHEL 6.5 system and a RHEL 7 replica
>>>> of everything except the CA. The RHEL 6.5 system, when the IPA
>>>> service is restarted throws an error, perhaps from schema
>>>> change?
>>>
>>>> Any ideas?
>>>
>>>> -Erinn
>>>
>>>
>>>
>>> I went in and debugged this a bit further by changing the
>>> verbosity for nsslapd-errorlog-level. It appears that the rhel
>>> 6.5 system is attempting to connect to the RHEL 7 system on port
>>> 7389 and since the RHEL 7 system does not have the CA installed
>>> this would obviously fail. This leads me to believe that there is
>>> cruft in the directory that is pointing to the wrong place. I
>>> don't think this will fix my second group of errors, but how does
>>> one view the replication agreements specifically for the ca?
>>>
>>> As well I omitted to lines from the ipa-ca-install error which
>>> are probably pertinent:
>>>
>>> ERROR:  Unable to access directory server: Server is unwilling to
>>> perform
>>>
>>> ipa         : DEBUG    stderr=
>>>
>>> -Erinn
> 
>> This is strange. ipa-ca-install/ipa-replica-install --setup-ca
>> should create the replication agreement pointing at port 389 on
>> RHEL-7.0, given that the 2 originally separated DS databases were
>> merged.
> 
>> It looks like this is some replication agreement left over from
>> previous tests.
> 
>> Anyway, to list all hosts with PKI, try:
> 
>> # ipa-csreplica-manage list Directory Manager password:
> 
>> vm-089.idm.lab.bos.redhat.com: master 
>> vm-086.idm.lab.bos.redhat.com: master
> 
>> "master" means that this server has PKI service installed. It will
>> show different value if there is no PKI service.
> 
>> To check PKI replication agreements for specific hostname, run:
> 
>> # ipa-csreplica-manage list `hostname` Directory Manager password:
> 
>> vm-089.idm.lab.bos.redhat.com
> 
>> Check "man ipa-csreplica-manage" for advise how to delete or create
>> the PKI agreements.
> 
>> HTH, Martin
> 
> 
> Yeah here is what I get:
> ipa-csreplica-manage list
> Directory Manager password:
> 
> ipa2.example.com: CA not configured
> ipa.example.com: master
> 
> ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance.
> 
> ipa-csreplica-manage list ipa2.example.com
> Directory Manager password:
> 
> Can't contact LDAP server
> 
> Which I guess makes sense, however:
> ipa-csreplica-manage list -v ipa.example.com
> Directory Manager password:
> 
> ipa2.example.com
>   last init status: None
>   last init ended: None
>   last update status: -1  - LDAP error: Can't contact LDAP server
>   last update ended: None
> ipa2.example.com
>   last init status: None
>   last init ended: None
>   last update status: 0 Replica acquired successfully: Incremental
> update succeeded
>   last update ended: 2014-08-04 14:43:48+00:00
> 
> This seems odd to me, but I don't really know exactly what to expect.
> Why is ipa2 referenced twice? Why does on have replication succeeding
> and the other failing?
> 
> It currently just feels like something is configured wrong, there is a
> wrong entry somewhere, but I can't figure it out just yet.

As Directory Manager, look in cn=mapping tree,cn=config for the list of
agreements. I'm guessing at least one of those has the wrong port.

The IPA agreement CN takes the form of meTo<somewhere> and CA agreements
CN uses masterAgreement1-<hostname>-* (or cloneAgreement, depending on
the side you're on).

rob