[Freeipa-devel] [PATCH] 825 add dogtag replication management

[Rich Megginson]

On 07/18/2011 09:34 AM, Rob Crittenden wrote:
> Jan Cholasta wrote:
>> On 15.7.2011 21:24, Rob Crittenden wrote:
>>> Rich Megginson wrote:
>>>> On 07/15/2011 10:57 AM, Rob Crittenden wrote:
>>>>> Rich Megginson wrote:
>>>>>> On 07/15/2011 08:01 AM, Rob Crittenden wrote:
>>>>>>> Martin Kosek wrote:
>>>>>>>> On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
>>>>>>>>> On 15.7.2011 05:42, Rob Crittenden wrote:
>>>>>>>>>> Add a separate tool for now to do dogtag replication agreement
>>>>>>>>>> management. The syntax is the same for IPA agreements with the
>>>>>>>>>> exception
>>>>>>>>>> that the DM password is always required and it isn't possible to
>>>>>>>>>> delegate the management of this.
>>>>>>>>>>
>>>>>>>>>> ticket https://fedorahosted.org/freeipa/ticket/1250
>>>>>>>>>>
>>>>>>>>>> rob
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> NACK
>>>>>>>>>
>>>>>>>>> 'ipa-csreplica-manage list server' doesn't list the peers of the
>>>>>>>>> specified server, but the peers of localhost.
>>>>>>>>>
>>>>>>>>> Connecting already connected pair of replicas duplicates the
>>>>>>>>> replication
>>>>>>>>> information ('ipa-csreplica-manage list server' shows the same
>>>>>>>>> hostname
>>>>>>>>> twice).
>>>>>>>>>
>>>>>>>>> There is trailing whitespace on line 87 of the patch.
>>>>>>>>>
>>>>>>>>> BTW I don't understand why is it possible (or necessary?) to be
>>>>>>>>> able to
>>>>>>>>> have CS replication topology that is different from the main IPA
>>>>>>>>> replication topology (ipa-csreplica-manage allows you to do
>>>>>>>>> that). Is
>>>>>>>>> there a reason for this?
>>>>>>>>>
>>>>>>>>> Honza
>>>>>>>>>
>>>>>>>>
>>>>>>>> And some issues from me:
>>>>>>>>
>>>>>>>> 1) Unhelpful error message when force-syncing from a master
>>>>>>>> without a
>>>>>>>> replication agreement:
>>>>>>>>
>>>>>>>> # ipa-csreplica-manage force-sync --from=HOST
>>>>>>>> Directory Manager password:
>>>>>>>> ipa: ERROR: Unable to find replication agreement for
>>>>>>>> vm-060.idm.lab.bos.redhat.com
>>>>>>>> unexpected error: Unable to proceed
>>>>>>>>
>>>>>>>> 2) Minor stuff in man page:
>>>>>>>>
>>>>>>>> Unindented Exit statuses:
>>>>>>>> EXIT STATUS
>>>>>>>> 0 if the command was successful
>>>>>>>> 1 if an error occurred
>>>>>>>>
>>>>>>>> Missing dot: The default is the machine on which the command is 
>>>>>>>> run
>>>>>>>> Not
>>>>>>>> honoured by the re-initialize command.
>>>>>>>>
>>>>>>>>
>>>>>>>> Otherwise it looks good.
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>
>>>>>>> This should address all the issues raised.
>>>>>>>
>>>>>>> The reason for different topology has several reasons:
>>>>>>>
>>>>>>> 1. A given IPA server may not have a CA installed
>>>>>>> 2. Some aspects of ipa-replica-manage can be delegated. We can't
>>>>>>> delegate CS replica management because it is in a different 
>>>>>>> directory
>>>>>>> server. We don't have users stored there so can't map the GSSAPI
>>>>>>> credentials. So only Directory Manager can operate on it for now.
>>>>>>> 3. Flexibility. You may want way more connections for users than 
>>>>>>> for
>>>>>>> the CA.
>>>>>>
>>>>>> + if starttls:
>>>>>> + self.conn = ipaldap.IPAdmin(hostname, port=port)
>>>>>> + ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
>>>>>>
>>>>>> Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
>>>>>> port=PORT, cacert=CACERT) ?
>>>>>
>>>>> Because the port is the non-secure port and opening an SSL connection
>>>>> to it failed.
>>>> Ah, ok. So that tells IPAdmin to use this CACERT and to use ldaps.
>>>>>
>>>>>>
>>>>>> + managers = entry.getValues('nsDS5ReplicaBindDN')
>>>>>> + if replica_binddn not in managers:
>>>>>>
>>>>>> You might want to use the dn.py code, or at least normalize the 
>>>>>> DNs in
>>>>>> managers before comparing
>>>>>
>>>>> That's a good idea.
>>>>>
>>>>>>
>>>>>> + if master is None:
>>>>>> + entry.setValues('nsds5replicaupdateschedule', '0000-2359
>>>>>> 0123456')
>>>>>>
>>>>>> You should just omit nsds5replicaupdateschedule
>>>>>
>>>>> It failed with an operations erorr when I tried removing the 
>>>>> attribute
>>>>> either directly with a MOD_DELETE or doing a MOD_REPLACE with 
>>>>> nothing.
>>>>> I assume this is another attribute in cn=config that once set cannot
>>>>> be undone.
>>>> Right. Ok. When you add the agreement entry, you can just omit it. But
>>>> if you are trying to modify an existing agreement entry, you can't
>>>> MOD_DELETE it or MOD_REPLACE with an empty value.
>>>
>>> Ok, good point about normalizing, updated patch attached.
>>>
>>> rob
>>>
>>
>> Everything I found is fixed. You might want to take a look at what
>> Martin found, though.
>>
>> Honza
>>
>
> Updated patch to use the DN class a bit more.
ack
>
> rob