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.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
