[Freeipa-devel] [PATCH] 0043 Allow-PKI-CA-Replica-Installs-when-CRL-exceeds-default

[Rob Crittenden]

Andrew Wnuk wrote:
> On 12/20/2012 06:49 AM, Simo Sorce wrote:
>> On Thu, 2012-12-20 at 09:39 -0500, Ade Lee wrote:
>>> On Wed, 2012-12-19 at 21:35 -0500, Simo Sorce wrote:
>>>> On Wed, 2012-12-19 at 22:41 +0000, JR Aquino wrote:
>>>>> On Dec 19, 2012, at 2:32 PM, Simo Sorce wrote:
>>>>>
>>>>>> On Wed, 2012-12-19 at 20:52 +0000, JR Aquino wrote:
>>>>>>> Due to a limitation with 389 DS, the nsslapd-maxbersize cannot be
>>>>>>> set dynamically.
>>>>>>> This causes an issue during IPA PKI-CA Replica installs, when the
>>>>>>> master has a CRL that exceeds the default limit.
>>>>>>> The cainstance.py code attempts to set this value prior to
>>>>>>> performing the initial PKI-CA replication, however, since the
>>>>>>> value cannot be set dynamically, the installation fails.
>>>>>>>
>>>>>>> This patch works around the issue by adding the ldif to the
>>>>>>> original initialization values bootstrapped by the call to
>>>>>>> setup-ds.pl
>>>>>> Why are we not simply restarting the instance after setting the
>>>>>> value ?
>>>>>>
>>>>>> What's in database.ldif ? What produces it ?
>>>>> /usr/share/pki/ca/conf/database.ldif is part of the dogtag
>>>>> installation and it contains the following entry:
>>>>> dn: cn=config
>>>>> changetype: modify
>>>>> replace: nsslapd-maxbersize
>>>>> nsslapd-maxbersize: 209715200
>>>>>
>>>>> It's purpose is to increase the limit for maxbersize from 2097152
>>>>> to 209715200.
> If your CA is relatively recent, 209715200 should give you enough room
> to generate CRLs v1 with up to 9.4 millions entries.
> If you plan on having bigger CRLs, consider further increase of
> nsslapd-maxbersize.
>>>>>
>>>>> The ldif is inserted via the jars that are wrapped by pkisilent...
>>>>> So this leaves 3 options:
>>>>>
>>>>> #1 Add code to perform the ldap insert followed by a dirsrv restart
>>>>> into the cainstance.py code
>>>>> #2 Add recode the jar files from DogTag to require a dirsrv restart
>>>>> after the insert, but prior to the replication
>>>>> #3 Just initialize the dirsrv database with the correct value to
>>>>> begin with. <1 line fix>
>>>>> #4 Ask 389 to allow maxbersize to be a dynamically initialized
>>>>> variable
>>>>>
>>>>> #3 Seemed the path of least resistance.
>>>>> I did take the time to code #1 and verify that it worked as well.
>>>>> I have a ticket open for #4
>>>>> Alee hinted that the jar modifications for #2 might not be trivial...
>>>> Method #3 is ok, but for master, where we have unified ds instances,
>>>> you
>>>> should look at doing ti as we do change other similar attributes in
>>>> install/updates/10-config.update so that older installations are
>>>> updated
>>>> as well.
>>>> If you do it only at install and the CRL grows later you'd get older
>>>> server start choking because they have not been updated.
>>>>
>>> Are you referring to masters which have been converted from non-unified
>>> DS to a single DS using an as-yet-to-be-written script?
>> I was thinking of a current 3.1 setup with multiple replicas installed
>> before this patch lands in Fedora.
>>
>> Old master (3.0) with split instances, new replicas (3.1) with unified
>> instances.
>>
>> After a while CRL in master grows past limit.
>> All replicas break because no update fixed them.
>>
>>> The ldif change mentioned above is already performed as part of the
>>> dogtag install.  For a freshly installed master, there is no large CRL
>>> to break the installation.
>>>
>>> In the replica scenario, this change is needed before we attempt
>>> replication because the large CRL breaks replication.  In fact, if that
>>> value had not been set on the master, there would be no large CRL to
>>> cause replication problems.
>> Understood, I am not asking for a huge change, just that the change is
>> done in an update file and not just on a fresh install.
>>
>> Simo.
>>

After a fair bit of discussion I went ahead and pushed this to master, 
ipa-3-1 and ipa-3-0.

This will will new replica creation. We are still a little unclear about 
whether existing masters will need any changes, but this patch is 
clearly a step forward.

rob