Îmi pare rău dacă acest lucru a fost întrebat anterior, dar când am căutat probleme similare, am primit rezultate de genul aceste (asta nu are sens pentru mine).
Am încercat să configurez 389-ds folosind documentația Red Hat Directory Server 11 pe două servere Rocky Linux 8.6 complet actualizate. Serverele mele sunt supplier1.example.com și supplier2.example.com și se află pe aceeași subrețea. Am configurat fișierul /etc/hosts al fiecărui server folosind IP-ul și numele de gazdă privat și am verificat conectivitatea prin ping IP-ul și numele de gazdă al celuilalt server. Porturile 389 și 636 sunt deschise pentru TCP. Sufixele partajate sunt „dc=example,dc=com.
Instanțele serverului de directoare au fost create folosind modul interactiv al dscreate (LDAP peste TCP 389, LDAPS peste TCP 636, certificate autosemnate etc.). Bănuiesc că problema se află undeva cu acele certificate autosemnate și o lipsă de încredere între cele două sisteme, dar nu știu cum să încep nici măcar să corectez asta.
Vă mulțumesc că ați citit asta.
Folosind exemplele de comenzi de mai jos, am reușit să creez acorduri de replicare...
Server 1:
sudo dsconf -D "cn=Directory Manager" ldap://supplier1.example.com replicare \
enable --suffix="dc=example,dc=com" --role="furnizor" --replica-id=2 \
--bind-dn="cn=manager de replicare,cn=config" --bind-passwd="parolă"
sudo dsconf -D "cn=Directory Manager" ldap://supplier1.example.com repl-agmt \
create --suffix="dc=example,dc=com" --host="supplier2.example.com" --port=389 \
--conn-protocol=LDAP --bind-dn="cn=manager de replicare,cn=config" \
--bind-passwd="parolă" --bind-method=SIMPLU --init \
exemplu-acord-furnizor1-la-furnizor2
Server 2:
dsconf -D "cn=Directory Manager" ldap://supplier2.example.com replicare \
enable --suffix="dc=example,dc=com" --role="furnizor" --replica-id=1 \
--bind-dn="cn=manager de replicare,cn=config" --bind-passwd="parolă"
sudo dsconf -D "cn=Directory Manager" ldap://supplier2.example.com repl-agmt \
create --suffix="dc=example,dc=com" --host="supplier1.example.com" --port=389 \
--conn-protocol=LDAP --bind-dn="cn=manager de replicare,cn=config" \
--bind-passwd="parolă" --bind-method=SIMPLU --init \
exemplu-acord-furnizor2-la-furnizor1
Documentația a cerut inițial ca comenzile acordului de replicare să utilizeze LDAPS peste 636, dar când am încercat, replicarea a eșuat întotdeauna. Iată un fragment din alergare
$ ldapsearch -x -b "cn=arborele de cartografiere,cn=config" -D "cn=Manager director" -w parola objectClass=nsDS5ReplicationAgreement -LL
...
nsds5replicaLastUpdateStatus: Eroare (-2) Problemă de conectare la replica - Eroare LDAP: Eroare locală (eroare de conectare)
nsds5replicaLastUpdateStatusJSON: {"state": "red", "ldap_rc": "-2", "ldap_rc_text": "Eroare locală", "repl_rc": "16", "repl_rc_text": "eroare de conectare", "data": „2022-05-26T21:58:31Z”, „message”: „Eroare (-2) Problemă de conectare la replica - Eroare LDAP: eroare locală (eroare de conectare)”}
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 20220526212655Z
nsds5replicaLastInitEnd: 19700101000000Z
nsds5replicaLastInitStatus: Eroare (-2) - Eroare LDAP: Eroare locală - nu s-a primit niciun răspuns
nsds5replicaLastInitStatusJSON: {"state": "red", "ldap_rc": "-2", "ldap_rc_text": "Eroare locală", "repl_rc": "255", "repl_rc_text": "niciun răspuns primit", "conn_rc" : "0", "conn_rc_text": "operațiune reușită", "date": "2022-05-26T21:27:10Z", "message": "Eroare (-2) - Eroare LDAP: eroare locală - nu a primit niciun răspuns "}