On 4/27/2012 10:20 PM, David Copperfield wrote:
I'm completely lost at reading the IPA document on how to promote a
IPA replica into master IPA. When I'm try to follow the steps listed
in the chapter '16.8.1 Promoting a Replica with a Dogtag Certificate
System CA' at the link
the last steps 'g' said:
g. Disable the redirect settings for CRL generation requests:
The above instructions don't give any hints of 'hostname', or 'port
number'. users don't have any clues about them, should them be this
replica's name, or the original master's name? and what is the por
t number? it is a TCP port, or a UDP port?
The replica is configured to check for information from the master CA --
in this case, asking the master CA to generate a CRL. Those parameters
tell the replica where to look. Part of promoting the replica is telling
it *not* to look for a master CA. So, those parameters should be blanked
I can definitely make that more clear.
As a serious evaluator of IPA, I have to think more above just for
fun. So it is a natural thought to think about disaster recovery and
smooth/continuous operations(simulation and real case): how to back up
Currently, there is no disaster recovery or backup information. There
are a couple of RFEs open to develop this information. My understanding
(and this is something that Dmitri or one of the engineers can explain
better) is that the best thing to do is to back up the DS instances
using db2ldif and then spin up a new server/replica instance and import
the backed up data using ldif2db.
how to promote replica into master, etc. But this document just post
quite way too much challenges for me. :)
What challenges? Can you elaborate? Or, even better, file a bug so that
I can make the docs better! (I'm the doc writer.)
One thing that would be helpful to me is to know what kinds of scenarios
you need covered; then I can work with engineering to get something into
Thank you very much for your feedback!
Freeipa-users mailing list