Я пытаюсь сделать резервную копию сервера LDAP с версии 2.4.23 на новую версию 2.4.40. Во время начальной настройки пакета мне задают вопрос, на который я отвечаю фактическими фактами о базе данных, пытаясь получить ту же конфигурацию старого сервера. Но как только я заканчиваю настройку, становится заметно, что она не дала ожидаемой конфигурации.
Вот конфигурация старого сервера (приобретенного с 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
И это то, что я получаю от только что установленного сервера (с 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
Попытка импортировать файлы, созданные со старого сервера, дает следующее:
slapadd: could not add entry dn="cn=config" (line=1):
_ 0.35% eta none elapsed none spd 2.0 M/s
Closing DB...
И если я попытаюсь импортировать только информацию о пользователях и компьютерах, я получу следующее:
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...
Я также сбросил исходную базу данных, используя ldapsearch -x -D "cn=admin,o=UFPA" -w 'admin_passwd' -b "o=UFPA" -H ldap://localhost -LLL "*" "+" > ldap_dump.ldif
А потом попытался восстановить с помощью ldapadd -Wx -D "cn=admin,dc=ufpa,dc=br" -h localhost -f ldap_dump.ldif
Но вот что я получаю:
adding new entry "o=UFPA"
ldap_add: Server is unwilling to perform (53)
additional info: no global superior knowledge
Может ли кто-нибудь помочь мне с этой проблемой?
Когда вы хотите восстановить полную cn = config резервное копирование с другого сервера, лучше всего начать с пустой директории config (на мой взгляд). В Debian и Ubuntu установщик создаст для вас базовую конфигурацию, что может быть причиной того, что он не может импортировать cn=config, потому что он уже существует.
Вот 2 варианта:
-c возможность slapadd Вот как я это сделал.
На старом сервере:
slapcat -b cn=config > config.ldif
На новом сервере:
# 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
Вы получаете no global superior knowledge ошибка, потому что OpenLDAP не имеет базы данных для хранения dn: dc=ufpa,dc=br in. Если он настроен правильно на старом сервере, вышеуказанный метод должен передать все это на новый сервер. Затем вы также можете сделать резервную копию и восстановить эту базу данных, как показано ниже.
На старом сервере:
slapcat -b dc=ufpa,dc=br > ufpa.br.ldif
На новом сервере:
# 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
Если вы получаете сообщение об ошибке, которое не может добавить запись dn = "dc = ufpq, dc = br", значит, что-то в резервной копии конфигурации, вероятно, уже создало ее. Попробуйте использовать -c вариант на последнем slapadd команда.
Вменяемые люди используют syncrepl для репликации / резервного копирования своих баз данных.
Вы упустили слишком много деталей, чтобы вам помочь. Например, это не может быть всей и, конечно же, не всех соответствующих частей конфигурации ваших старых серверов. У него нет настроенных суффиксов.
Если вы не можете использовать -c в качестве slapadd с ошибкой, попробуйте использовать slapadd -F /etc/ldap/slapd.d/ -l ufpa.br.ldif. Перед использованием убедитесь, что / var / lib / ldap пусто, и после восстановления установите владельца ldap.