[Freeipa-users] Confused/lost at promoting a replica into a master

[Dmitri Pal]

On 04/30/2012 03:02 PM, David Copperfield wrote:
> Hi Deon and all,
>
> >> Hi follks,
> >>
> >>  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
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/promoting-replica.html#promoting-pki,
> the last steps 'g' said:
> >>
> >>    g. Disable the redirect settings for CRL generation requests:
> >>         master.ca.agent.host=hostname
> >>         master.ca.agent.port=port number
> >>
> >> 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 or removed.
> >
> >I can definitely make that more clear.


Have you used a --selfsign option when you installed the first server?
If you did, you installed the server without CA. This is an advanced
option for those who know why they do not want the CA at all.
The standard, default way is to not provide --selfsign flag.
This will install CA on the first replica. On the other replicas you can
have a CA at your discretion. Or add it later if you did not install it
at the beginning.
HTH.

>
> Sure, please elabroate -- I'll still half undertstand only :) This
> part is pretty confusing by itself.
>
> First, when a IPA replica is first installed, the dogtag certification
> system is not installed at all, so the directory /var/lib/pki-ca/conf
> doesn't exist on IPA slave at all. The directory shows after
> only after 'ipa-ca-install' command is run on the replica.
>
> After running the command 'ipa-ca-install', in the configuration file
> '/var/lib/pki-ca/conf/CS.conf', there are no 'ca.crl.*' statements on
> IPA replica at all; there are no master.ca.agent.{host/port} s
> tatement either.
>
> What we really need to clarify here, from users' respective, are
> elaborated below(may not be completed):
>
> 1, how to promote a IPA replica into a IPA master?
>
> 2, What's the effect on other sibling IPA replicas? -- do we need to
> break original replication agreement with old IPA master? and create
> new aggrement with new server? If so, how to do it?
>
> 3, How to check/verify that new IPA replica is really promoted into
> new IPA master?
>
> 4, how to check/verify that old IPA Master is stopped its orignal
> master function? disowning the master CA in the PKI hierarchy as claimed?
>
> 4, what's the operations on the original IPA master?
>   4.1 case #1, what is the 'official' steps to remove/decommission
> original IPA master? -- what's the steps besides final
> 'ipa-master-install --uninstall'?
>   4.2 case #2, if the original IPA server is broken completely and all
> IPA replica could not reach it? -- Then what's are the steps to
> promote a IPA replica? Do we need the orignal /root/cacert.p12?
>   4.3 case #2, if the original IPA server is only temporarily
> unreachable? -- then after an IPA replica is promoted into new IPA
> master, how to depromote the orignal IPA master to replica after it is up?
>
> >>
> >> 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
> data,
> >
> >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.
> >
> >
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120430/bb2291f6/attachment.htm>