3 votes

Sauvegarde de la base de données LDAP

J'essaie de sauvegarder un serveur LDAP de la version 2.4.23 vers une nouvelle version 2.4.40. Pendant la configuration initiale du paquet, on me pose des questions auxquelles je réponds avec des faits réels concernant la base de données, en cherchant à obtenir la même configuration que l'ancien serveur. Mais dès que je termine la configuration, je constate qu'elle n'a pas donné la configuration attendue.

Voici la configuration de l'ancien serveur (acquis avec slapcat -n0 ):

dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
structuralObjectClass: olcGlobal
entryUUID: cde5ce8a-bf8f-1030-9594-7f29588dac90
creatorsName: cn=config
createTimestamp: 20111220195151Z
olcLogLevel: Stats
olcTLSCertificateFile: /etc/ssl/certs/ufpa.br.crt
olcTLSCertificateKeyFile: /etc/ssl/private/ufpa.br.key
olcToolThreads: 4
olcSizeLimit: unlimited
entryCSN: 20111222143131.011291Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20111222143131Z

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
structuralObjectClass: olcModuleList
entryUUID: cdeca534-bf8f-1030-959c-7f29588dac90
creatorsName: cn=admin,cn=config
createTimestamp: 20111220195151Z
entryCSN: 20111220195151.317803Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20111220195151Z

dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
structuralObjectClass: olcSchemaConfig
entryUUID: cde86cda-bf8f-1030-9597-7f29588dac90
creatorsName: cn=admin,cn=config
createTimestamp: 20111220195151Z
entryCSN: 20111220195151.290145Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20111220195151Z

Et voici ce que j'obtiens du serveur fraîchement installé (avec slapcat ):

dn: dc=ufpa,dc=br
objectClass: top
objectClass: dcObject
objectClass: organization
o: UFPA
dc: ufpa
structuralObjectClass: organization
entryUUID: 90e79216-16d2-1037-8dbb-11462ab3e25c
creatorsName: cn=admin,dc=ufpa,dc=br
createTimestamp: 20170816132842Z
entryCSN: 20170816132842.412456Z#000000#000#000000
modifiersName: cn=admin,dc=ufpa,dc=br
modifyTimestamp: 20170816132842Z

dn: cn=admin,dc=ufpa,dc=br
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9RC9YcU5KVFF1UHB0c0Nkc2pObUgrV2NSZHFVM3JWUkI=
structuralObjectClass: organizationalRole
entryUUID: 90e8e2b0-16d2-1037-8dbc-11462ab3e25c
creatorsName: cn=admin,dc=ufpa,dc=br
createTimestamp: 20170816132842Z
entryCSN: 20170816132842.421067Z#000000#000#000000
modifiersName: cn=admin,dc=ufpa,dc=br
modifyTimestamp: 20170816132842Z

En essayant d'importer les fichiers générés à partir de l'ancien serveur, on obtient ce résultat :

slapadd: could not add entry dn="cn=config" (line=1):
_                       0.35% eta   none elapsed            none spd   2.0 M/s
Closing DB...

Et si j'essaie d'importer seulement les informations sur les utilisateurs et les ordinateurs, j'obtiens ceci :

slapadd: line 1: database #1 (dc=ufpa,dc=br) not configured to hold "o=UFPA"; no database configured for that naming context
_                       0.00% eta    31s elapsed            none spd   1.9 M/s
Closing DB...

J'ai également vidé la base de données originale en utilisant ldapsearch -x -D "cn=admin,o=UFPA" -w 'admin_passwd' -b "o=UFPA" -H ldap://localhost -LLL "*" "+" > ldap_dump.ldif

Et puis j'ai essayé de restaurer en utilisant ldapadd -Wx -D "cn=admin,dc=ufpa,dc=br" -h localhost -f ldap_dump.ldif

Mais c'est ce que je reçois :

adding new entry "o=UFPA"
ldap_add: Server is unwilling to perform (53)
        additional info: no global superior knowledge

Quelqu'un peut-il m'aider à résoudre ce problème ?

2voto

Lorsque vous voulez restaurer une cn=config à partir d'un autre serveur, il est préférable de commencer avec un répertoire de configuration vide (à mon avis). Sous Debian et Ubuntu, l'installateur créera la configuration de base pour vous, ce qui peut expliquer pourquoi il ne parvient pas à importer cn=config parce qu'il existe déjà.

Voici deux options :

  • ignorer les erreurs et poursuivre l'importation en utilisant le -c option pour slapadd
  • commencez avec un répertoire de configuration vierge et importez toute la configuration du fichier ldif.

Voici comment je m'y suis pris.

Sur l'ancien serveur :

slapcat -b cn=config > config.ldif

Sur le nouveau serveur :

# backup current config
tar -czf /var/backups/openldap.config-$(date +%y%m%d).gz /etc/ldap/slapd.d
# delete current config
rm -rf /etc/ldap/slapd.d/*
# import config file copied from old server
slapadd -F /etc/ldap/slapd.d/ -b cn=config -l config.ldif

Vous obtenez le no global superior knowledge erreur car OpenLDAP n'a pas de base de données pour stocker dn: dc=ufpa,dc=br dans. S'il est configuré correctement sur l'ancien serveur, la méthode ci-dessus devrait tout transférer sur le nouveau serveur. Ensuite, vous pouvez également sauvegarder et restaurer cette base de données comme suit.

Sur l'ancien serveur :

slapcat -b dc=ufpa,dc=br > ufpa.br.ldif

Sur le nouveau serveur :

# backup current database
tar -czf /var/backups/openldap.data-$(date +%y%m%d).tgz /var/lib/ldap
# delete current database
rm -rf /var/lib/ldap/*.*
# restore backup from old server
slapadd -b ufpa.br.ldif

Si vous obtenez une erreur indiquant qu'il n'est pas possible d'ajouter l'entrée dn="dc=ufpq,dc=br", alors quelque chose dans la sauvegarde de la configuration l'a probablement déjà créée. Essayez d'utiliser l'option -c sur le dernier slapadd commandement.

1voto

84104 Points 12538

Les personnes saines d'esprit utilisent syncrepl pour répliquer / sauvegarder leurs bases de données.


Vous avez omis trop de détails pour être davantage aidé. Par exemple, cela ne peut pas être la totalité, et certainement pas toutes les parties pertinentes, de la configuration de vos anciens serveurs. Il n'a pas de suffixes configurés.

1voto

wawm Points 26

Si vous ne pouvez pas utiliser -c comme slapadd sans erreur, essayez d'utiliser slapadd -F /etc/ldap/slapd.d/ -l ufpa.br.ldif . Assurez-vous que /var/lib/ldap est vide avant d'utiliser cette méthode et définissez la propriété après restauration à l'utilisateur ldap.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X