[Pkg-openldap-devel] Recommendation for ldbm to bdb

Matthijs Mohlmann matthijs@cacholong.nl
Wed, 18 May 2005 08:56:22 +0200


This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig32369B06F535E6482D87F77C
Content-Type: multipart/mixed;
 boundary="------------010805010905040909000505"

This is a multi-part message in MIME format.
--------------010805010905040909000505
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Torsten,

Hooo, stop! ;)

I've already made a new patch with modifications, I modified as asked by
Stephen Frost. And here is the updated patch. :)

Well if you have more points and changes you want, discuss them ;)

Regards,

Matthijs Mohlmann

Torsten Landschoff wrote:
> Hi Matthijs, 
> 
> On Sun, May 15, 2005 at 01:28:10PM +0200, Matthijs Mohlmann wrote:
> 
>>Here the patch (with svn diff) that recommends bdb.
> 
> 
> Great, thanks. I hope it's okay to discuss the changes for a bit...
> 
> Generally what I don't like is that the changes are tied to changing
> ldbm to bdb. I'd expect that some day the hdb backend will be the
> recommended one so I'd like to replace the invokation of
> configure_ldbm_to_bdb to something like
> 
> 	change_backend ldbm bdb
> 
> or something along that line. 
> 
> 
>>What the patch does:
>>if the user has ldbm in the current configuration
>>ask for switching to bdb (see configure_dumping).
> 
> 
> Quoting the template for that change:
> 
> 
>>+_Description: Changing database backend.
>>+ It is highly recommended to use the BDB backend. This is also the recommended
>>+ choice of the OpenLDAP developers. The LDBM backend has proven to be more
>>+ reliable in earlier versions of OpenLDAP. (Versions 2.1.30 and below)
>>+ .
>>+ When using the BDB backend make sure you configure BDB properly. For 
>>+ information to do so, see: http://www.openldap.org/faq/data/cache/893.html.
> 
> 
> I think it is a bad idea to mention that LDBM is more stable in earlier
> versions. 
> 
> Given that we had only problems with people running ldbm I think we
> should even enforce changing the backend during upgrade. Comments?
> 
> Thanks again!
> 
> 	Torsten

--------------010805010905040909000505
Content-Type: text/x-patch;
 name="ldbm_bdb_recommendation.svn.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ldbm_bdb_recommendation.svn.patch"

Index: debian/slapd.scripts-common
===================================================================
--- debian/slapd.scripts-common	(revision 555)
+++ debian/slapd.scripts-common	(working copy)
@@ -28,6 +28,16 @@
 		db_input medium slapd/dump_database_destdir || true
 		db_go || true
 
+		# Backend recommendation. LDBM -> BDB
+		if grep '^moduleload[[:space:]]back_ldbm' $SLAPD_CONF 2>&1 >/dev/null ||
+					grep '^database[[:space:]]ldbm' $SLAPD_CONF 2>&1 >/dev/null ||
+					grep '^backend[[:space:]]ldbm' $SLAPD_CONF 2>&1 >/dev/null; then
+			db_input critical slapd/backend_recommendation || true
+			db_go || true
+		else
+			db_set slapd/backend_recommendation false
+		fi
+
 		# If the user entered the empty value, go back to the default
 		db_get slapd/dump_database_destdir 
 		if [ "$RET" = "" ]; then
@@ -66,7 +76,12 @@
 # Return success if yes.
 # Usage: if database_format_changed; then
 
-	dpkg --compare-versions "$OLD_VERSION" lt-nl "2.2.23" || return 1
+	db_get slapd/backend_recommendation
+	if dpkg --compare-versions "$OLD_VERSION" lt-nl "2.2.23" || [ "$RET" = "true" ]; then
+		return 0
+	else
+		return 1
+	fi
 }
 
 # }}}
@@ -558,6 +573,21 @@
 	echo "done." >&2
 } 
 # }}}
+configure_ldbm_to_bdb() {           # {{{
+	# Change all ldbm directives to bdb
+	if [ -e "$SLAPD_CONF" ]; then
+		db_get slapd/backend_recommendation
+		if [ "$RET" = "true" ]; then
+			# Change backend to bdb:
+			# - moduleload   back_ldbm -> moduleload back_bdb
+			# - backend      ldbm      -> backend bdb
+			# - database     ldbm      -> database bdb
+			sed -i -e 's/^moduleload[[:space:]]back_ldbm/moduleload\ back_bdb/' \
+				-e 's/^database[[:space:]]ldbm/database\ bdb/' \
+				-e 's/^backend[[:space:]]ldbm/backend\ bdb/' $SLAPD_CONF
+		fi
+	fi
+} # }}}
 autoconfigure_modules() {						# {{{
 # On upgrades from pre-2.1 we might have to update the configuration 
 # file for loading the backend modules. This function tries to figure out
Index: debian/slapd.postinst
===================================================================
--- debian/slapd.postinst	(revision 555)
+++ debian/slapd.postinst	(working copy)
@@ -43,6 +43,7 @@
 if database_format_changed; then
 	# During upgrading we have to load the old data
 	move_incompatible_databases_away
+	configure_ldbm_to_bdb
 	load_databases
 fi
 
Index: debian/slapd.templates
===================================================================
--- debian/slapd.templates	(revision 555)
+++ debian/slapd.templates	(working copy)
@@ -178,6 +178,19 @@
  option to be set on slaves. You should make sure to fix
  your slapd.conf configuration file.
 
+Template: slapd/backend_recommendation
+Type: boolean
+Default: true
+_Description: Changing backend type from LDBM to BDB
+ The LDBM backend type has been deprecated in OpenLDAP 2.2 and has shown to not
+ work well. BDB is the recommended choice of the OpenLDAP developers and when
+ properly configured has been shown to work very well.
+ .
+ When using the BDB backend make sure you configure BDB properly. For
+ information to do so, see: http://www.openldap.org/faq/data/cache/893.html.
+ .
+ Would you like to change your backend type to BDB from LDBM?
+
 Template: slapd/backend
 Type: select
 Choices: BDB, HDB, LDBM

--------------010805010905040909000505--

--------------enig32369B06F535E6482D87F77C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCiucZ2n1ROIkXqbARAhJSAJ96TDJiJUPuh/44Ubjdlvykm9HikACgnpXi
UstFNq+xuK+Owdf5sHFdVrQ=
=zHn7
-----END PGP SIGNATURE-----

--------------enig32369B06F535E6482D87F77C--