This is needed for IPA. They would like to create and maintain their own replication agreements. The idea is that the data would be replicated and available prior to running pkispawn on the clone.
We would need to provide an option in pkispawn to skip setting up the replication agreement. We would still need to create the VLV and regular indexes. It would be good to check for the existence of the baseDN at the beginning of the python code in pkispawn, so that we fail fast if the data has not been replicated (if this option is enabled).
Suggested target: 10.2.6
Per CS/DS meeting of 06/15/2015: 10.2.6
Vakwetu, please let us know if this is required earlier (e. g. - 10.2.5).
Per Dogtag 10.2.6 TRIAGE meeting of 06/30/2015: moved from 'critical' to 'major'
Well, this turned out to be even easier than I anticipated. Turns out I actually added this option as part of the work to allow IPA to deploy a KRA under the same top level baseDN as the CA, so that new replication agreements need not be created.
The option is : pki_clone_setup_replication which defaults to True.
What is still missing here is the some documentation in the man pages. Will add that.
what is the behaviour with this option, will it only skip the creation of the agreements ? will the replica entries (with assignment of replicaIds) created ? what about binddns ?
I did try to use the option in cainstance creation but failed:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: configuring certificate server instance ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command /usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp9qr5ih returned non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation logs and the following files/directories for more information: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki-ca-install.log ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration failed.
In the pki-spawn log I see:
2015-07-14 18:04:11 pkispawn : INFO ....... configuring PKI configuration data. 2015-07-14 18:05:29 pkispawn : ERROR ....... Exception from Java Configuration Servlet: 500 Server Error: Internal Server Error 2015-07-14 18:05:29 pkispawn : ERROR ....... ParseError: not well-formed (invalid token): line 1, column 0: {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Errors in creating or updating dbuser: com.netscape.certsrv.base.ResourceNotFoundException: No such object."} 2015-07-14 18:05:29 pkispawn : DEBUG ....... Error Type: ParseError 2015-07-14 18:05:29 pkispawn : DEBUG ....... Error Message: not well-formed (invalid token): line 1, column 0 2015-07-14 18:05:29 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 586, in main rv = instance.spawn(deployer) File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 116, in spawn json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line 3766, in configure_pki_data root = ET.fromstring(e.response.text) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1300, in XML parser.feed(text) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1642, in feed self._raiseerror(v) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror
my change was:
diff cainstance.py.MY cainstance.py 568c568,571 < config.set("CA", "pki_clone_setup_replication", "False")
config.set("CA", "pki_clone_replication_security", "TLS") config.set("CA", "pki_clone_replication_master_port", str(self.master_replication_port)) config.set("CA", "pki_clone_replication_clone_port", dogtag.install_constants.DS_PORT) config.set("CA", "pki_clone_replicate_schema", "False")
I did also try just to add the pki_clone_setup_replication and leave the other options as before, but the result is the same.
What is the right procedure to apply this option - and please answer qustions in previous comment
messages again with better formatting
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: configuring certificate server instance ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp9qr5ih'' returned non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation logs and the following files/directories for more information: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki-ca-install.log ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration failed.
2015-07-14 18:04:11 pkispawn : INFO ....... configuring PKI configuration data. 2015-07-14 18:05:29 pkispawn : ERROR ....... Exception from Java Configuration Servlet: 500 Server Error: Internal Server Error 2015-07-14 18:05:29 pkispawn : ERROR ....... ParseError: not well-formed (invalid token): line 1, column 0: {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Errors in creating or updating dbuser: com.netscape.certsrv.base.ResourceNotFoundException: No such object."} 2015-07-14 18:05:29 pkispawn : DEBUG ....... Error Type: ParseError 2015-07-14 18:05:29 pkispawn : DEBUG ....... Error Message: not well-formed (invalid token): line 1, column 0 2015-07-14 18:05:29 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 586, in main rv = instance.spawn(deployer) File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 116, in spawn json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line 3766, in configure_pki_data root = ET.fromstring(e.response.text) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1300, in XML parser.feed(text) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1642, in feed self._raiseerror(v) File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror raise err
diff cainstance.py.MY cainstance.py 568c568,571 < config.set("CA", "pki_clone_setup_replication", "False") --- > config.set("CA", "pki_clone_replication_security", "TLS") > config.set("CA", "pki_clone_replication_master_port", str(self.master_replication_port)) > config.set("CA", "pki_clone_replication_clone_port", dogtag.install_constants.DS_PORT) > config.set("CA", "pki_clone_replicate_schema", "False")
Hi, I'm working on adjusting IPA installer. I'm also curious what is the intended workflow for creating a clone whose replication agreements are managed externally.
If I simply add pki_clone_setup_replication to "False" for pkispawn on replica which is being installed, I get the same error as Ludwig. My initial though was that it's trying to get some info/user which is not there because o=ipaca is empty. If that's the case then the o=ipaca suffix should be replicated prior to pkispawn call.
Therefore my questions are: 1. what exactly pki_clone_setup_replication: "False" does? 2. who is responsible for creating o=ipaca? (I assume pkispawn) 3. when ipa replica installer should set the agreements and reinitialize o=ipaca?
Thank you
I responded via email thread. If we go with option 1, what is needed is a detailed comment explaining exactly what the replication agreement should look like for IPA, so that I can add the relevant parameters.
To summarize a bit what was discussed on ORC and by mail:
we found there are two options: 1] enhance pkispawn to allow more attributes of the replication agreement be configured. IPA installer could set the options, so that agreements will setup similar to agreements in the main realm database, further management of agreements would be handled by the ipa topology plugin 2] ipa installer installs a minimal backend and replica, sets up the agreements initializes the backend from the master and then calls pkispawn with pki_clone_setup_replication = false
After the discussion it looked like doing 1] would be possible and be the most convenient for ipa installer ( a detailled request will follow) We should also invetsigate 2] from IPA point of view, but need to find out what actions done by pkispawn should be done before calling pkispwan, eg assigning a replica, but is there more to it ?
needed changes in pkispawn for option 1] in comment 15:
a replication agreement created should look like this:
dn: cn=xxxxxx,cn=replica,cn=o\ipaca,cn=mapping tre e,cn=config cn: meTovm-166.abc.idm.lab.eng.brq.redhat.com nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicaHost: vm-166.abc.idm.lab.eng.brq.redhat.com nsDS5ReplicaPort: 389 nsDS5ReplicaRoot: dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com nsDS5ReplicaTransportInfo: LDAP
we need bind method and transportinfo set, but no bind dn or credentials, it could be possible to use one option for this eg pki_clone_replica_agmt_gssapi: true
we also need to set a binddngroup in the replica object:
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config cn: replica objectClass: nsDS5Replica objectClass: extensibleobject nsds5replicabinddngroup: cn=replication managers,cn=sysaccounts,cn=etc,dc=abc, dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
this could be handled by providing to set an option for setting nsds5replicabinddngroup
We have decided to take the original approach and have IPA create the replicas and have all the data replicated prior to starting the installation.
There are two parameters that are of interest here: pki_ds_create_new_db (which defaults to True) and pki_clone_setup_replication (which also defaults to True).
For the case where the database has already been setup and the data is replicated, you need both to be set to False.
When pki_ds_create_new_db is set to False, the following does NOT occur: -- database entry is created under cn=ldbn-database, cn= plugin, cn=config -- db mapping tree created - cn="o=ipaca", cn=mapping tree, cn=config -- base suffix created -> o=ipaca
When pki_clone_setup_replication is set to False, the following does NOT occur:
-- changelog is enabled/enabled on master and clone -- replica object is added --> cn=replica,cn=\"" + suffix + "\",cn=mapping tree,cn=config -- replica bind users are created (we assign replica ID) -- replication agreements are added -- consumer is initialized
The above setup (both parameters set to false) was found to work, except for a small glitch when restarting the server.
On restart the server tests passwords found in cms.passwordList. When pki_clone_setup_replication was set to false, the replication password was not set in password.conf, even though it was still in cms.passwordList. This resulted in a failed startup test.
This was addressed in a patch to master which will show up in 10.2.7:
commit 8a002e091841ceb52346f121d75db80e78735af2 Author: Ade Lee alee@redhat.com Date: Fri Jul 24 15:07:02 2015 -0400
Fix code to add replicationdb password unless already present The replicationdb password is an instance parameter and should be created by the first subsystem in the instance. This should happen independantly of whether replication is being set up in case it is needed to set up replication (as a master) later. Related to Ticket 1414
Note: until 10.2.7, IPA is implementing a workaround that removes the replicationdb entry from cms.passwordList to forego the startup test prior to instance restart.
This workaround is not needed and should be removed once 10.2.7 is available.
Modified in 10.2.6-1, 10.2.6-4, and 10.2.6-5.
Metadata Update from @vakwetu: - Issue assigned to vakwetu - Issue set to the milestone: 10.2.6
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/1975
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.