Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Rozwiązywanie problemów z OpenLDAP

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

W tej sekcji znajdziesz informacje i wskazówki dotyczące rozwiązywania problemów z OpenLDAP.

SMTP jest wyłączony, a użytkownicy muszą zresetować hasło

Krótki opis problemu

Gdy SMTP nie jest skonfigurowany w nowym interfejsie Edge, nowi użytkownicy dodani do Edge muszą mieć możliwość ustawienia hasła.

Komunikaty o błędach

Unknown username and password combination.

Możliwe przyczyny

Nowi użytkownicy nie mogą otrzymać e-maila z linkiem „Nie pamiętasz hasła?”, aby ustawić hasło, ponieważ SMTP nie jest skonfigurowany.

Rozdzielczość

Ten problem możesz rozwiązać na jeden z tych sposobów:

Rozwiązanie 1. Skonfiguruj serwer SMTP

Skonfiguruj serwer SMTP, aby ustawić nowe hasło użytkownika. Szczegółowe informacje o konfigurowaniu SMTP znajdziesz w artykule Konfigurowanie serwera SMTP Edge.

Rozwiązanie 2. Użyj LDAP

Jeśli nie możesz skonfigurować serwera SMTP, użyj tych poleceń LDAP, aby ustawić nowe hasło użytkownika:

Dotychczasowy administrator organizacji musi dodać konkretnego użytkownika w nowym interfejsie Edge (lub w klasycznym interfejsie Edge w starszych wersjach, jak pokazano na tym obrazie):

Użyj polecenia ldapsearch , aby znaleźć nazwę wyróżniającą użytkownika (dn) i przekierować dane wyjściowe do pliku:

ldapsearch -w Secret123 -D "cn=manager,dc=apigee,dc=com" -b "dc=apigee,dc=com" -LLL -x -H ldap://localhost:10389 > ldap.txt

Oto przykład wpisu dn użytkownika wraz z jego atrybutami:

dn:uid=f7a4a4a5-7c43-4168-a47e-6e9a1417cc29,ou=users,ou=global,dc=apigee,dc=com
mail: apigee_validator@apigee.com
userPassword:: e1NTSEF9b0FrMFFXVmFjbWRxM1BVaFZzMnllWGZMdkNvNjMwNTJlUDZYN3c9PQ=
 =
uid: f7a4a4a5-7c43-4168-a47e-6e9a1417cc29
objectClass: inetOrgPerson
sn: Validator
cn: apigee

Otwórz plik ldap.txt i znajdź nazwę wyróżniającą nowego użytkownika, który został dodany na podstawie atrybutu e-maila nowego użytkownika.
Uruchom polecenie ldappassword , aby dodać hasło dla nowego użytkownika za pomocą jego nazwy wyróżniającej. W tym przykładzie ustawiasz hasło użytkownika na Apigee123:
```
ldappasswd -x -H ldap://localhost:10389 -D "cn=manager,dc=apigee,dc=com" -W -s Apigee123
"uid=f7a4a4a5-7c43-4168-a47e-6e9a1417cc29,ou=users,ou=global,dc=apigee,dc=com"
```
Zaloguj się w nowym interfejsie Edge jako nowy użytkownik z hasłem zdefiniowanym w poprzednim kroku. Po zalogowaniu się w interfejsie użytkownik może ustawić nowe hasło.

LDAP nie replikuje

Krótki opis problemu

Wiele instalacji Edge ma kilka centrów danych, np. DC-1 i DC-2. Gdy zalogujesz się w nowym interfejsie Edge w DC-1 jako administrator organizacji, możesz wyświetlić listę użytkowników, ale ta sama lista nie pojawia się w nowym interfejsie Edge w DC-2.

Komunikaty o błędach

Nie pojawiają się żadne błędy. Nowy interfejs Edge nie wyświetla listy użytkowników, która powinna być replikowana na wszystkich serwerach OpenLDAP.

Możliwe przyczyny

Przyczyną tego problemu jest zwykle nieprawidłowo skonfigurowana konfiguracja replikacji OpenLDAP, a nie sama instalacja. Replikacja może też zostać przerwana, jeśli sieć między serwerami OpenLDAP nie zezwala na ruch na porcie 10389.

Diagnostyka

Aby zdiagnozować problem, wykonaj te czynności:

Sprawdź, czy ldapsearch zwraca dane z każdego serwera OpenLDAP:

ldapsearch -x -W -D "cn=manager,dc=apigee,dc=com" -b "dc=apigee,dc=com" -LLL -H ldap://HOST_IP:10389

Sprawdź, czy możesz połączyć się z każdym węzłem OpenLDAP z innych węzłów OpenLDAP na porcie 10389. Jeśli masz zainstalowany program telnet, użyj tego polecenia:
```
telnet <OpenLDAP_Peer_IP> 10389
```
Jeśli telnet nie jest dostępny, użyj netcat, aby sprawdzić łączność:
```
nc -vz <OpenLDAP_Peer_IP> 10389
```

Sprawdź konfigurację replikacji środowiska wykonawczego za pomocą polecenia ldapsearch:

ldapsearch -o ldif-wrap=no -D cn=admin,cn=config -H ldap://:10389 -LLL -x -w LDAP_ADMIN_PASSWORD -b "cn=config" "(olcSyncrepl=*)" olcSyncrepl

Dane wyjściowe powinny zawierać konfigurację podobną do tej:

dn: olcDatabase={2}mdb,cn=config
olcSyncrepl: {0}rid=001 provider=ldap://OTHER_LDAP_SERVER:10389/ binddn="cn=manager,dc=apigee,dc=com" bindmethod=simple credentials=LDAP_PASSWORD searchbase="dc=apigee,dc=com" attrs="*,+" type=refreshAndPersist retry="60 1 300 12 7200 +" timeout=1

Sprawdź konfigurację środowiska wykonawczego atrybutu olcMultiProvider (wcześniej olcMirrorMode) za pomocą ldapsearch w celu sprawdzenia, czy jest on ustawiony na TRUE:

ldapsearch -o ldif-wrap=no -D cn=admin,cn=config -H ldap://:10389 -LLL -x -w LDAP_ADMIN_PASSWORD -b "cn=config" "(olcMultiProvider=*)" olcMultiProvider olcMirrorMode

Dane wyjściowe powinny wyglądać tak:

dn: olcDatabase={2}mdb,cn=config
olcMultiProvider: TRUE

Sprawdź reguły iptables i tcp wrapper. Usuń wszystkie reguły, które uniemożliwiają komunikację między serwerami OpenLDAP. Skontaktuj się z administratorem sieci aby odpowiednio skonfigurować reguły.
Upewnij się, że hasło systemowe OpenLDAP jest takie samo w każdym węźle OpenLDAP.
Sprawdź, czy w plikach konfiguracyjnych ldif używanych do konfigurowania replikacji OpenLDAP N-Way nie ma ukrytych znaków. W tym celu uruchom polecenie dos2unix w plikach ldif utworzonych w celu zaktualizowania konfiguracji. Zwykle plik w formacie LDIF zawierający nieprawidłowe znaki powoduje, że polecenie ldapmodify nie działa, a replikacja danych może nie zostać skonfigurowana. Usuń wszystkie nieprawidłowe znaki i zapisz pliki konfiguracyjne.

Jeśli problem nadal występuje, skontaktuj się z zespołem pomocy Apigee, aby uzyskać pomoc w konfigurowaniu replikacji OpenLDAP N-Way.

Nie można uruchomić OpenLDAP

Krótki opis problemu

OpenLDAP nie uruchamia się.

Komunikaty o błędach

SLAPD Dead But Pid File Exists

Możliwe przyczyny

Ten problem jest zwykle spowodowany plikiem blokady, który pozostał w systemie plików i należy go usunąć.

Diagnostyka

Aby zdiagnozować ten problem, wykonaj te czynności:

Sprawdź, czy w tej lokalizacji znajduje się plik blokady lub plik pid procesu OpenLDAP slapd:

/opt/apigee/var/run/apigee-openldap/apigee-openldap.lock
/opt/apigee/var/run/apigee-openldap/apigee-openldap.pid

Jeśli znajdziesz plik blokady i plik pid, usuń je i spróbuj ponownie uruchomić OpenLDAP.

 rm /opt/apigee/var/run/apigee-openldap/apigee-openldap.lock
 rm /opt/apigee/var/run/apigee-openldap/apigee-openldap.pid

Jeśli proces OpenLDAP slapd się uruchomi, pomiń te czynności.
Jeśli proces OpenLDAP slapd się nie uruchomi, spróbuj uruchomić slapd w trybie debugowania i poszukaj błędów:
```
slapd -h ldap://:10389/ -u apigee -F /opt/apigee/data/apigee-openldap/slapd.d -d 255
```
Błędy mogą wskazywać na problemy z zasobami. Sprawdź wykorzystanie pamięci i procesora w systemie.
Sprawdź wersję OpenLDAP i zaktualizuj ją, jeśli jest stara. Obsługiwane wersje OpenLDAP znajdziesz w sekcji Obsługiwane oprogramowanie.
```
slapd -V
```
Użyj strace, aby rozwiązać problemy z procesem slapd i przekazać dane wyjściowe strace do zespołu pomocy Apigee:
```
strace -tt -T -f -F -i -v -e read=all -s 8192 -e write=all -o /tmp/strace.out -p <pid>
```

Uszkodzenie danych OpenLDAP

Krótki opis problemu

Użytkownicy nie mogą już wykonywać wywołań zarządzania ani logować się w nowym interfejsie Edge UI. Użycie narzędzia ldapsearch do wysyłania zapytań do użytkowników może wskazywać, że użytkownik istnieje w magazynie danych LDAP, lub może wskazywać na brakujących użytkowników lub role.

Komunikaty o błędach

Unknown username and password combination.

Możliwe przyczyny

Ten problem może być spowodowany uszkodzeniem danych OpenLDAP. Dane OpenLDAP zwykle nie ulegają uszkodzeniu. W rzadkich przypadkach uszkodzenie może być spowodowane awarią dysku systemowego lub problemami z miejscem na dysku.

Diagnostyka

Sprawdź miejsce na dysku w systemie, w którym jest zainstalowany OpenLDAP, za pomocą tego polecenia:
```
du -m /opt
```
Jeśli widzisz, że używane miejsce na dysku jest bardzo bliskie 100%, oznacza to, że przyczyną tego problemu jest brak miejsca na dysku w systemie.

Sprawdź spójność danych w węzłach LDAP:

W każdym węźle LDAP porównaj liczbę użytkowników i ról. Uruchom te polecenia i porównaj wyniki.

ldapsearch -o ldif-wrap=no -b "ou=users,ou=global,dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w PASSWORD|wc -l
ldapsearch -o ldif-wrap=no -b "ou=resources,ou=global,dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w PASSWORD|wc -l

Rozbieżność w liczbie między węzłami sugeruje możliwe uszkodzenie danych.

Sprawdź stan replikacji LDAP. Uruchom to polecenie w każdym węźle LDAP.

  ldapsearch -x -LLL -H ldap://ldap_ip:10389 -s base -b 'dc=apigee,dc=com' contextCSN dn: dc=apigee,dc=com -D "cn=manager,dc=apigee,dc=com" -w PASSWORD dn: dc=apigee,dc=com

Jeśli wartość contextCSN jest identyczna we wszystkich węzłach, replikacja LDAP działa prawidłowo.

Rozdzielczość

Jeśli w systemie brakuje miejsca na dysku lub jest on bliski wyczerpania, dodaj więcej miejsca na dysku, aby zapewnić wystarczającą dostępność.

Gdy będziesz mieć wystarczającą ilość miejsca na dysku, użyj jednego z tych rozwiązań, aby rozwiązać problem z uszkodzeniem danych LDAP:

Przywróć dane OpenLDAP z kopii zapasowej.
Wyczyść bazę danych OpenLDAP, wykonując te czynności:
1. Wyłącz serwer zarządzania 2 i LDAP2.
2. Przywróć LDAP1 z kopii zapasowej maszyny wirtualnej (lub kopii zapasowej Apigee).
3. Sprawdź serwer zarządzania 1 pod kątem uruchomienia i odzyskiwania.
4. Gdy serwer zarządzania 1 i LDAP1 będą działać prawidłowo, zainstaluj ponownie LDAP2 od zera (tworząc całkowicie pustą tablicę).
5. Skonfiguruj LDAP2 w trybie tylko do odczytu, aby LDAP1 mógł replikować do LDAP2.
6. Użyj ldapsearch, aby sprawdzić, czy liczba wierszy w LDAP1 i LDAP2 jest zgodna.
7. Uruchom ponownie serwer zarządzania 2 i nowy interfejs Edge w węźle 2 i sprawdź, czy uruchamiają się prawidłowo.

Szczegółowe instrukcje znajdziesz w publicznym narzędziu do śledzenia problemów.

Rozwiązanie 1. Przywróć dane LDAP z kopii zapasowej

Utwórz kopię zapasową w działającym węźle OpenLDAP. Kopia zapasowa powinna być wykonywana regularnie. Sprawdzone metody tworzenia kopii zapasowych znajdziesz w przewodniku po operacjach w Apigee Private Cloud:

slapcat -F /opt/apigee/data/apigee-openldap/slapd.d -l /tmp/ldap-backup.ldif

Aby przywrócić dane OpenLDAP z prawidłowej kopii zapasowej, wykonaj te czynności.

Zatrzymaj węzeł OpenLDAP, dla którego należy przywrócić dane:

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap stop

Zmień katalog na katalog danych OpenLDAP:
```
cd /opt/apigee/data/apigee-openldap
```
Utwórz kopię zapasową istniejących danych OpenLDAP za pomocą polecenia move:
```
mv ldap ldap_orig
```
Przełącz się na użytkownika apigee:
```
su apigee
```
W katalogu /opt/apigee/data/apigee-openldap utwórz nowy katalog danych OpenLDAP o oryginalnej nazwie:
```
mkdir ldap
```
Utwórz kopię zapasową podkatalogu ldap_orig/DB_CONFIG z kroku 3 i skopiuj ją do katalogu openldap.
```
cp ldap_orig/DB_CONFIG ldap
```
Aby przywrócić dane z kopii zapasowej utworzonej za pomocą slapcat, użyj slapadd, aby zaimportować plik ldif, który zawiera prawidłowe dane:
```
slapadd -F /opt/apigee/data/apigee-openldap/slapd.d -l /tmp/ldap-backup.ldif
```

Uruchom proces OpenLDAP:

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap start

Rozwiązanie 2. Wyczyść bazę danych LDAP

Te czynności powodują wyczyszczenie bazy danych OpenLDAP, aby można było zacząć od nowa. To rozwiązanie można zastosować, jeśli nie ma kopii zapasowej danych z ostatniego stanu, w którym dane OpenLDAP działały.

Zatrzymaj usługę OpenLDAP:

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap stop

Zmień katalog na katalog danych OpenLDAP:
```
cd /opt/apigee/data/apigee-openldap
```
Utwórz kopię zapasową istniejących danych OpenLDAP za pomocą polecenia move:
```
mv ldap ldap_orig
```
Przełącz się na użytkownika apigee:
```
su apigee
```
Utwórz nowy katalog danych OpenLDAP o oryginalnej nazwie:
```
mkdir ldap
```
Utwórz kopię zapasową podkatalogu ldap_orig/DB_CONFIG z kroku 3 i skopiuj ją do katalogu openldap directory:
```
cp ldap_orig/DB_CONFIG ldap
```

Uruchom ponownie proces OpenLDAP:

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap start

Uruchom ponownie serwer zarządzania, aby wymusić odświeżenie połączeń z OpenLDAP:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
```

Rozwiązanie 3. Zresetuj OpenLDAP do podstawowej instalacji

Jeśli rozwiązanie 2 nie rozwiąże problemu, możesz zresetować OpenLDAP do podstawowej instalacji, jak opisano w tej sekcji.

Wymagania wstępne

Aby zresetować OpenLDAP, musisz spełnić te wymagania wstępne:

Możliwość uruchomienia konfiguracji za pomocą danych logowania administratora systemu i roota LDAP.
Dostęp do narzędzia ldapadd.
Zapisany oryginalny cichy plik konfiguracyjny dla węzła zarządzania/LDAP.

Uwaga: przed zresetowaniem OpenLDAP utwórz kopię zapasową plików konfiguracyjnych /opt/apigee/customer/application.

Aby zresetować OpenLDAP:

Zainstaluj ponownie OpenLDAP i serwer zarządzania.
1. Zatrzymaj serwer openldap:
```
apigee-service apigee-openldap stop
```
2. Usuń uszkodzony folder danych openldap:
```
rm -rf /opt/apigee/data/apigee-openldap
```
3. Odinstaluj komponent openldap:
```
apigee-service apigee-openldap uninstall
```
4. Zainstaluj ponownie komponent openldap za pomocą tego samego pliku konfiguracyjnego, który został użyty do początkowej instalacji:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ld -f configfile
```
  gdzie configfile to nazwa pliku konfiguracyjnego.
5. Zainstaluj ponownie serwer zarządzania za pomocą oryginalnego pliku konfiguracyjnego:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ms -f configfile
```
Po wykonaniu tych czynności wywołania interfejsu API zarządzania Google Analytics powinny ponownie działać tylko na koncie sysadmin. Nie można jednak zalogować się w nowym interfejsie Edge, a wywołania interfejsu API zarządzania Google Analytics z innymi użytkownikami nie będą działać.

Dodaj brakujące wpisy openldap dla organizacji, które istniały przed uszkodzeniem.

Po wykonaniu powyższego kroku w openldap będą brakować wpisy dla organizacji, które istniały w momencie wystąpienia uszkodzenia. Większość rzeczywistych danych organizacji, takich jak pakiety proxy, jest przechowywana w Cassandra lub Zookeeper i nie jest utracona. Uruchomienie skryptu setup-org nie spowoduje jednak automatycznego dodania danych openldap dla organizacji, które już istnieją w Cassandra i Zookeeper. Te dane należy dodać ręcznie dla każdej organizacji, która istniała przed uszkodzeniem, wykonując te czynności:

Utwórz plik w formacie LDIF o nazwie missingLDAP.ldif z tą treścią:

# orgname, organizations, apigee.com
dn: o=orgname,ou=organizations,dc=apigee,dc=com
objectClass: organization
O: orgname

# userroles, orgname, organizations, apigee.com
dn: ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com
ou: userroles
objectClass: organizationalUnit

# orgadmin, userroles, orgname, organizations, apigee.com
dn: cn=orgadmin,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com
objectClass: organizationalRole
cn: orgadmin
roleOccupant: uid=admin,ou=users,ou=global,dc=apigee,dc=com

# resources, orgadmin, userroles, orgname, organizations, apigee.com
dn: ou=resources,cn=orgadmin,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com
ou: resources
objectClass: organizationalUnit

# @@@, resources, orgadmin, userroles, orgname, organizations, apigee.com
dn: cn=@@@,ou=resources,cn=orgadmin,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com
roleOccupant: ou=delete,ou=permissions,dc=apigee,dc=com
roleOccupant: ou=get,ou=permissions,dc=apigee,dc=com
roleOccupant: ou=put,ou=permissions,dc=apigee,dc=com
labeledURI: /
objectClass: organizationalRole
objectClass: labeledURIObject
cn: @@@

gdzie orgname to nazwa organizacji, którą próbujesz utworzyć ponownie.

Dodaj brakujące encje LDAP za pomocą tego polecenia:

ldapadd -x -w "OPENLDAP_ROOT_PASSWORD" -D "cn=manager,dc=apigee,dc=com" -H ldap://localhost:10389 -f missingLDAP.ldif

Powyższe czynności spowodują utworzenie brakujących wpisów dla istniejącej organizacji oraz uprawnień orgadmin dla tej organizacji. Powtórz te czynności dla każdej organizacji, którą trzeba utworzyć ponownie. W tym momencie możesz dodać użytkowników orgadmin do organizacji, ale inne role domyślne jeszcze nie istnieją, więc musisz je dodać w następnym kroku.

Dodaj brakujące role i uprawnienia domyślne do istniejącej organizacji.

Uruchom to polecenie za pomocą tego samego pliku konfiguracyjnego, który został użyty do początkowego skonfigurowania dowolnej z istniejących organizacji:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision create-roles -f configfile
```

Po wykonaniu tej procedury musisz ręcznie:

dodaj wszystkie role niestandardowe, które istniały przed uszkodzeniem, za pomocą nowego interfejsu Edge lub interfejsu API zarządzania Google Analytics,
dodaj użytkowników do odpowiednich ról.

(Opcjonalnie) Przywróć konfigurację uwierzytelniania zewnętrznego w Management.

Przywróć plik /opt/apigee/customer/application/management-server.properties, jeśli konfiguracja się nie zmieniła. Ponieważ nowy interfejs Edge nie został ponownie zainstalowany, /opt/apigee/customer/application/management-ui.properties pozostaje taki sam po przywróceniu danych logowania do konta sysadmin w nowej instalacji serwera zarządzania.
(Opcjonalnie) Zainstaluj ponownie Apigee mTLS w węźle Management.

Jeśli Apigee mTLS został wcześniej zainstalowany, zainstaluj go ponownie w węźle serwera zarządzania, korzystając z przewodnika instalacji Apigee mTLS.

Jeśli problem nadal występuje, skontaktuj się z zespołem pomocy Apigee.