[Freeipa-devel] [PATCHSET] Replica promotion patches

Martin Basti mbasti at redhat.com
Thu Oct 15 15:09:04 UTC 2015



On 15.10.2015 14:29, Jan Cholasta wrote:
> On 15.10.2015 12:00, Petr Vobornik wrote:
>> On 10/15/2015 10:45 AM, Jan Cholasta wrote:
>>> On 23.9.2015 19:47, Simo Sorce wrote:
>>>> On Wed, 2015-09-23 at 08:35 +0200, Jan Cholasta wrote:
>>>>> What I mean is that installing a replica using an already existing
>>>>> replica file should be prevented at level 1 as well:
>>>>>
>>>>> root at ipa1# ipa-server-install --domain-level=0
>>>>> root at ipa1# ipa-replica-prepare ipa2.example.com
>>>>> root at ipa1# ipa domainlevel-set 1
>>>>>
>>>>> root at ipa2# ipa-replica-install replica-info-ipa2.example.com.gpg
>>>>> ERROR: Can't install replica from a replica file at domain level > 0
>>>>
>>>> Ok I rebased the patchset with a modification to assume promotion 
>>>> if no
>>>> file was provided, and then raise appropriate RuntimeErrors if
>>>> conditions about the domain level are not met.
>>>>
>>>> This change also prevents installing with a replica file if domain 
>>>> level
>>>> is currently at 1.
>>>>
>>>> They are in the usual custodia-review branch.
>>>
>>> "Add ipa-custodia service": functional ACK
>>>
>>> 1) freeipa-python is still missing BuildRequires and Requires on
>>> python-jwcrypto:
>>>
>>> On 23.9.2015 08:35, Jan Cholasta wrote:
>>>> On 23.9.2015 02:47, Simo Sorce wrote:
>>>>> On Tue, 2015-09-22 at 10:57 -0400, Simo Sorce wrote:
>>>>>> On Tue, 2015-09-22 at 10:45 +0200, Jan Cholasta wrote:
>>>>>>> 1) python-jwcrypto dependency is missing in the spec file.
>>>>>>
>>>>>> It shouldn't be necessary as custodia already depends on it.
>>>>
>>>> IMO it is a good practice to require all direct dependencies, because
>>>> you can't control indirect dependencies. For example, if one day
>>>> custodia switched from jwcrypto to something different, ipa would lose
>>>> the jwcrypto dependency without us knowing.
>>>
>>>
>>> "Require a DS version that has working DNA plugin": ACK
>>>
>>>
>>> "Implement replica promotion functionality":
>>>
>>> 1) You should handle NotFound for the find_entries() call in
>>> cainstance.find_ca_server().
>>>
>>> 2) You can remove ReplicaCA and ReplicaDNS classes as they are unused.
>>>
>>> 3) I'm getting this on domain level 0 client:
>>>
>>> # ipa-replica-install
>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM:
>>> Your system may be partly configured.
>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>
>>> ipa.ipapython.install.cli.install_tool(Replica): ERROR Major (851968):
>>> Unspecified GSS failure. Minor code may provide more information, Minor
>>> (2529639053): No Kerberos credentials available
>>>
>>> It comes from the "Try out authentication" conn.connect() in
>>> promote_check(), because it is missing the ccache kwarg.
>>>
>>>
>>> "Change DNS installer code to use passed in api": ACK
>>>
>>>
>>> "Allow ipa-replica-conncheck to use default creds":
>>>
>>> 1) ipa-replica-install prompts for admin password twice during
>>> connection check:
>>>
>>>      Get credentials to log in to remote master
>>>      Check SSH connection to remote master
>>>      admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password:
>>>      Execute check on remote master
>>>      admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password:
>>>
>>>
>>> "Add function to extract CA certs for install": ACK
>>>
>>>
>>> "topology: manage ca replication agreements": functional ACK
>>>
>>> 1) This 20-replication.update bit does not seem to be related to the
>>> patch:
>>>
>>> # add IPA realm managed suffix to master entry
>>> dn: cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX
>>> add: objectclass: ipaReplTopoManagedServer
>>> add: ipaReplTopoManagedSuffix: $SUFFIX
>>>
>>> Why is it included? (Petr?)
>>
>> I believe this could be send as a separate patch. It was included during
>> tuning of update and is not related to replica promotion nor managing of
>> CA agreements.
>
> (reference: 
> <https://www.redhat.com/archives/freeipa-devel/2015-October/msg00262.html>)
>
>>
>>>
>>> 2) In update_ca_topology, call CAInstance.__update_topology() 
>>> instead of
>>> copy & pasting the code.
>>>
>>>
>>> "enable topology plugin on upgrade": ACK
>>>
>>>
>>> "topology plugin configuration workaround": ACK
>>>
>>>
>>> "handle multiple managed suffixes": ACK
>>>
>>>
>>> "prevent operation on tombstones": ACK
>>>
>>>
>>> "Allow to setup the CA when promoting a replica": ACK
>>>
>>>
>>> "Make checks for existing credentials reusable": ACK
>>>
>>>
>>> "Add low level helper to get domain level": ACK
>
> To speed things up, I fixed the issues I found in the patches above, 
> to be able to push them.
>
> Pushed to master: 6a0087aea176d1e1154b359fa262066896d663e3

Upgrade does not work:

https://fedorahosted.org/freeipa/ticket/5374

Martin
>
>>>
>>>
>>> "Allow ipa-ca-install to use the new promotion code":
>>>
>>> 1) The --replica option was not removed:
>>>
>>> On 22.9.2015 10:45, Jan Cholasta wrote:
>>>> 1) The --replica option is redundant. You can safely decide whether 
>>>> this
>>>> is the first CA master or not based on information in cn=masters.
>>>
>>> 2) ipa-ca-install prompts for both admin and DM password:
>>>
>>> # ipa-ca-install -r
>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM:
>>> Directory Manager (existing master) password:
>>>
>>> DM password should not be required, right?
>>>
>>> 3) ipa-ca-install fails with:
>>>
>>> Traceback (most recent call last):
>>>    File 
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>>> line 445, in start_creation
>>>      run_step(full_msg, method)
>>>    File 
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>>> line 435, in run_step
>>>      method()
>>>    File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", 
>>> line
>>> 631, in __spawn_instance
>>>      DogtagInstance.spawn_instance(self, cfg_file)
>>>    File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
>>> line 185, in spawn_instance
>>>      self.handle_setup_error(e)
>>>    File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
>>> line 448, in handle_setup_error
>>>      raise RuntimeError("%s configuration failed." % self.subsystem)
>>> RuntimeError: CA configuration failed.
>>>
>>> I guess I'm hitting the authentication bug in Dogtag. It is supposed to
>>> be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2?
>>> We might need a new 10.2.7 build.
>>>
>>>
>>> "Remove unused kra option": ACK
>
> I also pushed this one.
>
> Pushed to master: 9e007edbd902a5395797ca0ca9a698033540d755
>
>>>
>>>
>>> "Allow to install the KRA on a promoted server":
>>>
>>> 1) ipa-kra-install fails with:
>>>
>>> Traceback (most recent call last):
>>>    File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
>>> 171, in execute
>>>      return_value = self.run()
>>>    File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", 
>>>
>>> line 220, in run
>>>      self._run()
>>>    File
>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", 
>>>
>>> line 200, in _run
>>>      if config.subject_base is None:
>>> AttributeError: 'NoneType' object has no attribute 'subject_base'
>>>
>>>
>>
>>
>
>




More information about the Freeipa-devel mailing list