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

[Ade Lee]

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

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.

> Simo.
>