Hash: SHA256

>>> Here you go: dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1
>>>  dbs.beginSerialNumber=1 dbs.enableSerialManagement=true 
>>> dbs.endReplicaNumber=50 dbs.endRequestNumber=9900000 
>>> dbs.endSerialNumber=ff60000 dbs.ldap=internaldb 
>>> dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 
>>> dbs.replicaDN=ou=replica dbs.replicaIncrement=100 
>>> dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica,
>>> ou=ranges dbs.requestCloneTransferNumber=10000
>>> dbs.requestDN=ou=ca, ou=requests dbs.requestIncrement=10000000
>>> dbs.requestLowWaterMark=2000000 dbs.requestRangeDN=ou=requests,
>>> ou=ranges dbs.serialCloneTransferNumber=10000 
>>> dbs.serialDN=ou=certificateRepository, ou=ca
>>> dbs.serialIncrement=10000000 dbs.serialLowWaterMark=2000000
>>> dbs.serialRangeDN=ou=certificateRepository, ou=ranges
> Erinn, I still need to see the ldap entries I mentioned above. 
> Those are actually the ones that will need to be changed.
>>> Unfortunately, things seem to have gone further south on the
>>> RHEL 6.5 CA instance now. This just seems to be my luck on this
>>> replica install. From the debug of the ipa-ca-install: ipa
>>> : DEBUG    Starting external process ipa         : DEBUG
>>> args=/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw ipa         :
>>> DEBUG    Process finished, return code=1 ipa : DEBUG
>>> stdout=Loading deployment configuration from /tmp/tmp1G6jOw. 
>>> ERROR:  Unable to access security domain: 404 Client Error: Not
>>> Found
>>> ipa         : DEBUG    stderr= ipa         : CRITICAL failed to
>>> configure ca instance Command '/usr/sbin/pkispawn -s CA -f
>>> /tmp/tmp1G6jOw' returned non-zero exit status 1
>>> I can see in the apache logs on the RHEL 6.5 instance it errors
>>> out: [Mon Aug 04 21:06:02 2014] [error] [client 
>>> 2001:4870:800e:301:862b:2bff:fe67:704d] File does not exist: 
>>> /var/www/html/ca
>>> This is supposed to be mapped via ajp to localhost:9447 which
>>> does appear to be listening. Anyway, I am in the throws of that
>>> currently, but let me know if those ranges are out of control
>>> big.
>>> -Erinn
> Erinn, I'm a little confused.
> Perhaps at this point, it would make sense for you to test out your
> 6.5 instance and confirm that its working/ can issue certs etc. 
> Maybe a restart of IPA on that server could help right things.
>> Could this be caused by
>> https://bugzilla.redhat.com/show_bug.cgi?id=1083878? You could
>> check access log to see what calls are being made by 7.0
>> replica.
>> This will be fixed in 6.6, I am afraid that for 6.5 you will have
>> to do the update (adding "|^/ca/ee/ca/profileSubmit") yourself.
>> Martin

You and me both my friend, confusion seems to be par for the course on
this particular migration, but hey I am learning a lot and y'all are
great help.

Actually I think I have figured out why everything went a bit further
south, well at least I have a theory I would like to run by you folks.
I did a run on the RHEL 7 system of ipa-ca-install that failed
probably because of Ade's theory. However, I think at that point the
replication agreement was in place and functioning possibly because of
the old entries on the RHEL 6.5 system.

I then ran a pkidestroy on the RHEL 7 instance to clean things up. I
reckon this might have replicated on over because at this point it
appears I have no ipaca entries, nor anything functioning in that area
on the RHEL 6.5 system.

Either that or I have some serious corruption or HW problems.

So I am working on a restore from a backup of the directory server
info for the CA on the RHEL 6.5 system.

All in all, pretty damn funny if that is how it worked out. One way or
another the cert info is gone on the RHEL 6.5 system though the
cn=config info remains intact.

- -Erinn
Version: GnuPG v1


Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to