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

[Simo Sorce]

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

-- 
Simo Sorce * Red Hat, Inc * New York