פתרון בעיות של OpenLDAP

אתם קוראים את מסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X.
מידע

בקטע הזה מפורט מידע והנחיות לפתרון בעיות ב-OpenLDAP.

פרוטוקול SMTP מושבת והמשתמשים צריכים לאפס את הסיסמה

תיאור הבעיה

כש-SMTP לא מוגדר בממשק המשתמש החדש של Edge, משתמשים חדשים שנוספים ל-Edge צריכים דרך להגדיר סיסמה.

הודעות שגיאה

Unknown username and password combination.

סיבות אפשריות

משתמשים חדשים לא יכולים לקבל אימייל מהקישור "שכחת את הסיסמה?" כדי להגדיר סיסמה, כי SMTP לא מוגדר.

רזולוציה

כדי לטפל בבעיה, אפשר לבצע אחת מהפעולות הבאות:

פתרון מס' 1: הגדרת שרת SMTP

מגדירים את שרת ה-SMTP כדי להגדיר סיסמה חדשה למשתמש. פרטים על הגדרת SMTP זמינים במאמר הגדרת שרת SMTP של Edge.

פתרון 2: שימוש ב-LDAP

אם אתם לא יכולים להגדיר את שרת ה-SMTP, אתם יכולים להשתמש בפקודות ה-LDAP הבאות כדי להגדיר סיסמה חדשה למשתמש:

  1. מנהל חשבון ארגוני קיים צריך להוסיף את המשתמש הספציפי בממשק המשתמש החדש של Edge (או בממשק המשתמש הקלאסי של Edge בגרסאות קודמות, כמו שמוצג בתמונה הבאה):

  2. משתמשים בפקודה ldapsearch כדי למצוא את השם הייחודי (dn) של המשתמש, ומפנים את הפלט לקובץ:
    ldapsearch -w Secret123 -D "cn=manager,dc=apigee,dc=com" -b "dc=apigee,dc=com" -LLL -x -H ldap://localhost:10389 > ldap.txt
    

    דוגמה לרשומה של DN של משתמש, יחד עם המאפיינים של המשתמש:

    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
  3. פותחים את הקובץ ldap.txt ומחפשים את ה-dn של המשתמש החדש שנוסף על סמך מאפיין האימייל של המשתמש החדש.
  4. מריצים את הפקודה ldappassword כדי להוסיף סיסמה למשתמש החדש באמצעות ה-DN שלו. בדוגמה הזו, אתם מגדירים את הסיסמה של המשתמש ל-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"
    
  5. מתחברים לממשק המשתמש החדש של Edge כמשתמש החדש עם הסיסמה שהוגדרה בשלב הקודם. המשתמש יכול להגדיר סיסמה חדשה אחרי שהוא מתחבר לממשק המשתמש.

LDAP is not Replicating

תיאור הבעיה

בהרבה התקנות של Edge יש כמה מרכזי נתונים, למשל DC-1 ו-DC-2. כשמתחברים לממשק המשתמש החדש של Edge ב-DC-1 כמנהלי ארגון, אפשר לראות את רשימת המשתמשים, אבל אותה רשימת משתמשים לא מופיעה בממשק המשתמש החדש של Edge ב-DC-2.

הודעות שגיאה

לא מופיעות שגיאות, אבל בממשק המשתמש החדש של Edge לא מוצגת רשימת המשתמשים שהייתה אמורה להיות משוכפלת בכל שרתי OpenLDAP.

סיבות אפשריות

בדרך כלל, הסיבה לבעיה הזו היא הגדרה שגויה של שכפול OpenLDAP, ולא ההתקנה עצמה. בנוסף, השכפול עלול להיפסק אם הרשת בין שרתי OpenLDAP לא מאפשרת תעבורה ביציאה 10389.

אבחון

כדי לאבחן את הבעיה:

  1. בודקים אם ldapsearch מחזיר נתונים מכל שרת OpenLDAP:
    ldapsearch -x -W -D "cn=manager,dc=apigee,dc=com" -b "dc=apigee,dc=com" -LLL -H ldap://HOST_IP:10389
  2. בודקים אם אפשר להתחבר לכל צומת OpenLDAP מצמתי OpenLDAP אחרים ביציאה 10389. אם telnet מותקן, משתמשים בפקודה הבאה:
    telnet <OpenLDAP_Peer_IP> 10389
    
  3. אם פרוטוקול telnet לא זמין, משתמשים ב-netcat כדי לבדוק את הקישוריות:

    nc -vz <OpenLDAP_Peer_IP> 10389
    
  4. בודקים את הגדרת הרפליקציה של סביבת זמן הריצה באמצעות הפקודה 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
    

    הפלט אמור להכיל הגדרות דומות לאלה:

    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
  5. בודקים את הגדרות זמן הריצה של מאפיין olcMultiProvider (לשעבר olcMirrorMode) באמצעות הפקודה ldapsearch כדי לוודא שהערך שלו הוא 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
    

    הפלט אמור להיראות כך:

    dn: olcDatabase={2}mdb,cn=config
    olcMultiProvider: TRUE
  6. בודקים את הכללים של iptables ו-tcp wrapper. צריך להסיר את כל הכללים שלא מאפשרים לשרתי OpenLDAP של הרשת השכנה לתקשר ביניהם. כדי להגדיר את הכללים בצורה מתאימה, צריך לפנות למנהל הרשת.
  7. מוודאים שהסיסמה של מערכת OpenLDAP זהה בכל צומת OpenLDAP.
  8. בודקים אם יש תווים מוסתרים בקובצי התצורה של ldif שמשמשים להגדרת רפליקציה של N-Way OpenLDAP. לשם כך, מריצים את הפקודה dos2unix על קובצי ה-LDIF שנוצרו כדי לעדכן את התצורה. בדרך כלל, קובץ ldif שמכיל תווים לא תקינים גורם לכך שהפקודה ldapmodify לא פועלת, ולכן יכול להיות שהשכפול לא יוגדר. מסירים את התווים הבעייתיים ושומרים את קובצי התצורה.

אם הבעיה נמשכת, פנו אל התמיכה של Apigee כדי לקבל עזרה בהגדרת שכפול N-Way OpenLDAP.

אי אפשר להפעיל את OpenLDAP

תיאור הבעיה

‫OpenLDAP לא מתחיל.

הודעות שגיאה

SLAPD Dead But Pid File Exists

סיבות אפשריות

הבעיה הזו נגרמת בדרך כלל בגלל קובץ נעילה שנשאר במערכת הקבצים וצריך להסיר אותו.

אבחון

כדי לאבחן את הבעיה:

  1. בודקים אם יש קובץ pid או קובץ נעילה של תהליך slapd של OpenLDAP במיקום הבא:
    /opt/apigee/var/run/apigee-openldap/apigee-openldap.lock
    /opt/apigee/var/run/apigee-openldap/apigee-openldap.pid
  2. מוחקים את קובץ הנעילה ואת קובץ ה-PID, אם הם נמצאו, ומנסים להפעיל מחדש את openldap.
     rm /opt/apigee/var/run/apigee-openldap/apigee-openldap.lock
     rm /opt/apigee/var/run/apigee-openldap/apigee-openldap.pid
  3. אם תהליך ה-slapd של OpenLDAP מתחיל, אפשר לדלג על השלבים הבאים.
  4. אם התהליך OpenLDAP slapd לא מתחיל, מנסים להריץ את slapd במצב ניפוי באגים ומחפשים שגיאות:
    slapd -h ldap://:10389/ -u apigee -F /opt/apigee/data/apigee-openldap/slapd.d -d 255
    
  5. שגיאות יכולות להצביע על בעיות במשאבים. בודקים את ניצול הזיכרון והמעבד (CPU) במערכת.
  6. בודקים את הגרסה של OpenLDAP ומשדרגים אם היא ישנה. בקטע תוכנות נתמכות אפשר לבדוק אילו גרסאות של OpenLDAP נתמכות.
    slapd -V
    
  7. כדי לפתור בעיות בתהליך slapd ולספק פלט של strace לתמיכה של Apigee, צריך להשתמש ב-strace:
    strace -tt -T -f -F -i -v -e read=all -s 8192 -e write=all -o /tmp/strace.out -p <pid>
    

פגם בנתונים ב-OpenLDAP

תיאור הבעיה

המשתמשים לא יכולים יותר להריץ קריאות ניהול או להתחבר לממשק המשתמש של New Edge. שימוש בכלי ldapsearch לשאילתת משתמשים עשוי להצביע על כך שהמשתמש קיים במאגר הנתונים של LDAP, או לזהות משתמשים או תפקידים חסרים אפשריים.

הודעות שגיאה

Unknown username and password combination.

סיבות אפשריות

בדרך כלל, הבעיה הזו מתרחשת בגלל נתונים פגומים ב-OpenLDAP. בדרך כלל, הנתונים של OpenLDAP לא נפגמים. אבל במקרים נדירים שבהם זה קורה, יכול להיות שהקבצים נפגמו בגלל כשל בדיסק המערכת או בגלל בעיות במקום בדיסק.

אבחון

  1. כדי לבדוק את המקום בכונן במערכת שבה מותקן OpenLDAP, משתמשים בפקודה הבאה:
    du -m /opt
    
  2. אם אתם רואים שהשימוש במקום בדיסק קרוב מאוד ל-100%, זה מצביע על כך שהגורם לבעיה הוא שנגמר המקום בדיסק במערכת.
  3. בודקים את העקביות של הנתונים בצמתי LDAP:
    1. בכל צומת LDAP, משווים בין מספר המשתמשים למספר התפקידים. מריצים את הפקודות הבאות ומשווים בין התוצאות.
      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 
      אם יש פער בספירה בין הצמתים, יכול להיות שהנתונים נפגמו.
    2. מאמתים את סטטוס הרפליקציה של LDAP. מריצים את הפקודה הבאה בכל צומת 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 
      אם הערך של contextCSN זהה בכל הצמתים, שכפול ה-LDAP פועל כמו שצריך.

רזולוציה

אם לא נשאר מקום בכונן במערכת או שנשאר מעט מאוד מקום, צריך להוסיף עוד מקום בכונן כדי להבטיח שיש מספיק מקום פנוי.

אחרי שיהיה לכם מספיק מקום בכונן, תוכלו להשתמש באחד מהפתרונות הבאים כדי לטפל בבעיה של נתוני LDAP פגומים:

  1. משחזרים את נתוני OpenLDAP מהגיבוי.
  2. מנקים את מסד הנתונים של OpenLDAP לפי השלבים הבאים:
    1. משביתים את Management Server 2 ואת LDAP2.
    2. משחזרים את LDAP1 מגיבוי של מכונה וירטואלית (או מגיבוי של Apigee).
    3. בודקים את Management Server 1 כדי לראות את ההפעלה והשחזור.
    4. אחרי שמוודאים שManagement Server 1 ו-LDAP1 פועלים בצורה תקינה, מתקינים מחדש את LDAP2 מאפס (כלומר, יוצרים מצב התחלתי ריק לחלוטין).
    5. מגדירים את LDAP2 במצב קריאה בלבד, כדי לאפשר ל-LDAP1 לשכפל ל-LDAP2.
    6. משתמשים ב-ldapsearch כדי לוודא שמספר השורות ב-LDAP1 וב-LDAP2 תואם.
    7. מפעילים מחדש את Management Server 2 ואת New Edge UI בצומת 2, ומוודאים שהם מופעלים.

הוראות מפורטות זמינות בכלי הציבורי למעקב אחר בעיות.

פתרון מס' 1: שחזור נתוני ה-LDAP מהגיבוי

מגבים צומת OpenLDAP פעיל. חשוב לבצע את הגיבוי באופן קבוע. במדריך התפעול של Apigee Private Cloud מפורטות השיטות המומלצות לגיבויים:

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

כדי לשחזר את נתוני OpenLDAP מגיבוי תקין, אפשר לפעול לפי השלבים הבאים.

  1. עוצרים את צומת OpenLDAP שבו צריך לשחזר את הנתונים:
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap stop
    
  2. משנים את הספרייה לספריית הנתונים של OpenLDAP:
    cd /opt/apigee/data/apigee-openldap
    
  3. מגבים את נתוני OpenLDAP הקיימים באמצעות הפקודה move:
    mv ldap ldap_orig
    
  4. עוברים למשתמש apigee:
    su apigee
    
  5. בספרייה /opt/apigee/data/apigee-openldap, יוצרים ספריית נתונים חדשה של OpenLDAP עם השם המקורי:
    mkdir ldap
    
  6. מגבים את ספריית המשנה ldap_orig/DB_CONFIG משלב 3 ומעתיקים אותה לספרייה openldap.
    cp ldap_orig/DB_CONFIG ldap
    
  7. כדי לשחזר נתונים מגיבוי שנוצר באמצעות slapcat, משתמשים ב-slapadd כדי לייבא את קובץ ה-ldif שמכיל את הנתונים התקינים:
    slapadd -F /opt/apigee/data/apigee-openldap/slapd.d -l /tmp/ldap-backup.ldif
    
  8. מפעילים את תהליך OpenLDAP:
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap start
    

פתרון מס' 2: ניקוי מסד הנתונים של LDAP

השלבים הבאים מוחקים את מסד הנתונים של OpenLDAP כדי להתחיל מחדש. אפשר להשתמש בפתרון הזה אם אין גיבוי נתונים של המצב האחרון שבו נתוני OpenLDAP פעלו.

  1. עוצרים את שירות OpenLDAP:
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap stop
    
  2. משנים את הספרייה לספריית הנתונים של OpenLDAP:
    cd /opt/apigee/data/apigee-openldap
    
  3. מגבים את נתוני OpenLDAP הקיימים באמצעות הפקודה move:
    mv ldap ldap_orig
    
  4. עוברים למשתמש apigee:
    su apigee
    
  5. יוצרים ספריית נתונים חדשה של OpenLDAP עם השם המקורי:
    mkdir ldap
    
  6. לוקחים את ספריית המשנה לגיבוי ldap_orig/DB_CONFIG משלב 3, ומעתיקים אותה לספריית openldap:
    cp ldap_orig/DB_CONFIG ldap
    
  7. מפעילים מחדש את תהליך OpenLDAP:
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap start
    
  8. מפעילים מחדש את שרת הניהול כדי לאלץ רענון של החיבורים ל-OpenLDAP:
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
    

פתרון מס' 3: איפוס OpenLDAP להתקנה בסיסית

אם פתרון מס' 2 לא פותר את הבעיה, אתם יכולים לאפס את OpenLDAP להתקנה בסיסית, כמו שמתואר בקטע הזה.

דרישות מוקדמות

כדי לאפס את OpenLDAP, אתם צריכים:

  • היכולת להריץ את ההגדרה עם פרטי כניסה של אדמין מערכת ו-root LDAP.
  • גישה לכלי ldapadd.
  • קובץ התצורה השקט המקורי שנשמר לצומת הניהול/LDAP.

כדי לאפס את OpenLDAP, פועלים לפי השלבים הבאים:

  1. מתקינים מחדש את OpenLDAP ואת שרת הניהול.
    1. עוצרים את השרת של openldap:
      apigee-service apigee-openldap stop
    2. מוחקים את תיקיית הנתונים הפגומה של openldap:
      rm -rf /opt/apigee/data/apigee-openldap
    3. מסירים את הרכיב openldap:
      apigee-service apigee-openldap uninstall
    4. מתקינים מחדש את הרכיב openldap באמצעות אותו קובץ תצורה ששימש להתקנה הראשונית:
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f configfile
      כאשר configfile הוא השם של קובץ התצורה.
    5. מתקינים מחדש את שרת הניהול באמצעות קובץ התצורה המקורי:
      /opt/apigee/apigee-setup/bin/setup.sh -p ms -f configfile

    אחרי שמבצעים את השלבים האלה, קריאות ל-Management API אמורות לפעול שוב באמצעות חשבון sysadmin בלבד. עם זאת, אי אפשר להתחבר לממשק המשתמש החדש של Edge, וקריאות ל-Management API עם משתמשים אחרים לא יפעלו.

  2. מוסיפים את הרשומות החסרות של openldap לארגונים שהיו קיימים לפני שהנתונים נפגמו.

    אחרי השלמת השלב שלמעלה, ב-openldap יהיו חסרים רשומות של ארגונים שהיו קיימים כשהתרחשה הפגיעה בנתונים. רוב הנתונים בפועל של הארגון, כמו חבילות שרת proxy, מאוחסנים ב-Cassandra או ב-Zookeeper ולא אובדים. עם זאת, הפעלת הסקריפט setup-org לא תוסיף באופן אוטומטי את נתוני openldap לארגונים שכבר קיימים ב-Cassandra וב-Zookeeper. צריך להוסיף את הנתונים האלה באופן ידני לכל ארגון שהיה קיים לפני הפגיעה בנתונים, לפי השלבים הבאים:

    1. יוצרים קובץ ldif בשם missingLDAP.ldif עם התוכן הבא:
      # 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: @@@

      כאשר orgname הוא הארגון שאתם מנסים ליצור מחדש.

    2. מוסיפים את ישויות ה-LDAP החסרות באמצעות הפקודה הבאה:
      ldapadd -x -w "OPENLDAP_ROOT_PASSWORD" -D "cn=manager,dc=apigee,dc=com" -H ldap://localhost:10389 -f missingLDAP.ldif

    השלבים שלמעלה ייצרו את הרשומות החסרות לארגון קיים, ואת ההרשאות של orgadmin לאותו ארגון. חוזרים על השלבים לכל ארגון שצריך ליצור מחדש. בשלב הזה, אפשר להוסיף משתמשי orgadmin לארגון, אבל תפקידי ברירת המחדל האחרים עדיין לא קיימים, ולכן צריך להוסיף אותם באמצעות השלב הבא.

  3. הוספת תפקידים והרשאות שמוגדרים כברירת מחדל לארגון קיים.

    מריצים את הפקודה הבאה באמצעות אותו קובץ תצורה ששימש בהתחלה להגדרת כל אחד מהארגונים הקיימים:

    /opt/apigee/apigee-service/bin/apigee-service apigee-provision create-roles -f configfile
  4. אחרי שמבצעים את התהליך הזה, צריך לבצע את הפעולות הבאות באופן ידני:

    • מוסיפים את כל התפקידים בהתאמה אישית שהיו קיימים לפני שהנתונים נפגמו באמצעות ממשק המשתמש החדש של Edge או Management API,
    • מוסיפים משתמשים לתפקידי המשתמשים הרלוונטיים.
  5. (אופציונלי) הגדרה מחדש של אימות חיצוני בניהול.

    אם ההגדרות לא השתנו, משחזרים את /opt/apigee/customer/application/management-server.properties. מכיוון שממשק המשתמש החדש של Edge לא הותקן מחדש, /opt/apigee/customer/application/management-ui.properties נשאר ללא שינוי אחרי שפרטי הכניסה לחשבון sysadmin שוחזרו בהתקנה החדשה של שרת הניהול.

  6. (אופציונלי) מתקינים מחדש את Apigee mTLS בצומת הניהול.

    אם Apigee mTLS הותקן בעבר, צריך לפעול לפי מדריך ההתקנה של Apigee mTLS כדי להתקין אותו מחדש בצומת של שרת הניהול.

אם הבעיה נמשכת, פנו אל התמיכה של Apigee כדי לקבל עזרה נוספת.