Adding upstream version 2.5.13+dfsg.upstream/2.5.13+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 77 insertions, 0 deletions

diff --git a/doc/guide/admin/maintenance.sdf b/doc/guide/admin/maintenance.sdf
new file mode 100644
index 0000000..62a5532
--- /dev/null
+++ b/doc/guide/admin/maintenance.sdf
@@ -0,0 +1,77 @@
+# $OpenLDAP$
+# Copyright 2007-2022 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: Maintenance
+
+System Administration is all about maintenance, so it is only fair that we 
+discuss how to correctly maintain an OpenLDAP deployment.
+
+
+H2: Directory Backups
+
+Backup strategies largely depend on the amount of change in the database
+and how much of that change an administrator might be willing to lose in a 
+catastrophic failure. There are two basic methods that can be used:
+
+1. Backup the LMDB database itself
+
+The LMDB database can be copied live using the mdb_copy command.  If the database
+is a sparse file via the use of the "writemap" environment flag, the resulting
+copy will be the actual size of the database rather than a sparse copy.
+
+2. Periodically run slapcat and back up the LDIF file:
+
+Slapcat can be run while slapd is active. However, one runs the risk of an
+inconsistent database- not from the point of slapd, but from the point of
+the applications using LDAP. For example, if a provisioning application
+performed tasks that consisted of several LDAP operations, and the slapcat
+took place concurrently with those operations, then there might be
+inconsistencies in the LDAP database from the point of view of that
+provisioning application and applications that depended on it. One must,
+therefore, be convinced something like that won't happen. One way to do that
+would be to put the database in read-only mode while performing the
+slapcat. The other disadvantage of this approach is that the generated LDIF
+files can be rather large and the accumulation of the day's backups could
+add up to a substantial amount of space.
+
+You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8) 
+back-mdb databases.
+
+>    slapcat -f slapd.conf -b "dc=example,dc=com"
+
+For back-mdb this command may be ran while slapd(8) is running.
+
+
+H2: Checkpointing
+
+Setting a checkpoint is only necessary when back-mdb has the dbnosync flag set. Otherwise
+it has no effect. With back-mdb the kbyte option is not implemented, meaning it will only
+run a checkpoint based on the elapsed amount of minutes flag.
+
+H2: Migration
+
+The simplest steps needed to migrate between versions or upgrade, depending on your deployment
+type are:
+
+.{{S: }}
+^{{B: Stop the current server when convenient}}
+
+.{{S: }}
++{{B: slapcat the current data out}}
+
+.{{S: }}
++{{B: Clear out the current data directory (/usr/local/var/openldap-data/)}}
+
+.{{S: }}
++{{B: Perform the software upgrades}}
+
+.{{S: }}
++{{B: slapadd the exported data back into the directory}}
+
+.{{S: }}
++{{B: Start the server}}
+
+Obviously this doesn't cater for any complicated deployments with {{SECT: N-Way Multi-Provider}}, 
+but following the above sections and using either commercial support or community support should help. Also check the
+{{SECT: Troubleshooting}} section.