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

[Andrew Wnuk]

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.
>