แก้ไขปัญหาการบูตล้มเหลวของ Zimbra ที่แสดงข้อความ “LDAP Server Not Responding”: คู่มือการกู้คืนเชิงปฏิบัติ

เมื่อ Zimbra เกิดข้อผิดพลาดระหว่างการเริ่มต้นทำงาน เช่น ข้อผิดพลาดดังกล่าวLDAP server not respondingคำถามสำคัญไม่ได้อยู่ที่ว่าจะทำให้ข้อความนั้นหายไปได้อย่างไร เป้าหมายที่แท้จริงคือการกู้คืนการพึ่งพา LDAP ให้กลับมาใช้งานได้ตามปกติ ยืนยันว่า Zimbra สามารถอ่านการกำหนดค่าได้อีกครั้ง และหลีกเลี่ยงการเปลี่ยนแปลงบริการที่ไม่เกี่ยวข้องในขณะที่ยังไม่ทราบสาเหตุที่แท้จริง

คู่มือนี้มุ่งเน้นที่ผลลัพธ์ดังกล่าว โดยใช้คำสั่งที่ Zimbra ได้บันทึกไว้สำหรับสถานะบริการ การตรวจสอบ LDAP การกำหนดค่าภายใน การตรวจสอบใบรับรอง และ URL LDAP แบบหลายเซิร์ฟเวอร์ ตัวอย่างใช้ชื่อโฮสต์ที่เป็นตัวแทน เช่นldap1.example.com; โปรดแทนที่ด้วยค่าจากระบบของคุณเอง

การฟื้นตัวที่ประสบความสำเร็จควรมีลักษณะอย่างไร

ก่อนที่จะเปลี่ยนแปลงอะไรก็ตาม ให้กำหนดจุดสิ้นสุดให้ชัดเจน การซ่อมแซมจะน่าเชื่อถือเมื่อเป็นไปตามเงื่อนไขต่อไปนี้ทั้งหมด:

• ldap statusรายงานslapdกระบวนการที่กำลังทำงานอยู่บนโหนด LDAP
• zmcontrol statusรายงานว่า LDAP และบริการ Zimbra ที่เกี่ยวข้องกำลังทำงานอยู่บนโฮสต์ที่ได้รับผลกระทบ
• ชื่อโฮสต์ LDAP แปลงเป็นที่อยู่ตามที่คาดไว้จากโหนด Zimbra ที่ได้รับผลกระทบ
• สามารถเข้าถึงพอร์ต LDAP ที่กำหนดค่าไว้ได้แล้ว
• หากมีการใช้ TLS ระบบจะตรวจสอบความถูกต้องของห่วงโซ่ใบรับรอง และข้อผิดพลาด TLS ก่อนหน้านี้ก็จะหายไป
• ในการใช้งานแบบหลายเซิร์ฟเวอร์ จะต้องมีโฮสต์ LDAP ที่ใช้งานได้ ldap_urlและldap_master_urlถูกต้องตามลำดับที่ต้องการ
• หลังจากรีสตาร์ทแล้ว/var/log/zimbra.logจะไม่แสดงข้อความแจ้งว่าการเชื่อมต่อ LDAP ล้มเหลวซ้ำอีกต่อไป

หากการตรวจสอบข้อใดข้อหนึ่งยังคงล้มเหลว ให้แก้ไขปัญหาในส่วนนั้นต่อไปแทนที่จะรีสตาร์ท Zimbra ทั้งหมดซ้ำๆ

ข้อมูลอ้างอิงโดยย่อ: อาการและการตรวจครั้งต่อไป

1. ตรวจสอบว่า LDAP หยุดทำงานหรือไม่

เรียกใช้การตรวจสอบสถานะในฐานะzimbraผู้ใช้:

su - zimbra
zmcontrol status
ldap status

เอกสารการแก้ไขปัญหา LDAP ของ Zimbra แนะนำให้ตรวจสอบว่าslapdกระบวนการทำงานอยู่จริงหรือไม่ จากนั้นยืนยันว่า Zimbra รู้จักกระบวนการนั้นด้วยldap statusคำสั่ง `ls -l` หาก LDAP ไม่ทำงานในเครื่อง ให้ตรวจสอบกระบวนการ LDAP ก่อนที่จะแก้ไขปัญหาเมลบ็อกซ์, MTA, พร็อกซี หรือเว็บเซอร์วิส LDAP เป็นส่วนประกอบสำคัญของการกำหนดค่า ดังนั้นบริการปลายทางอาจล้มเหลวได้ง่ายๆ เพียงเพราะไม่สามารถอ่านข้อมูลการกำหนดค่าได้

อ้างอิง: เอกสารการแก้ไขปัญหา Zimbra LDAPและเอกสารอ้างอิงคำสั่ง zmcontrol ของ Zimbra

2. ตรวจสอบ URL ของ LDAP ก่อนเปลี่ยนบริการ

บนโหนดที่ได้รับผลกระทบ ให้ตรวจสอบเอนด์พอยต์ LDAP ในเครื่อง:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url

ในเอกสารประกอบการใช้งาน Zimbra 10 แบบหลายเซิร์ฟเวอร์ldap_urlระบุว่า `<replicas>` คือเซิร์ฟเวอร์ LDAP ที่โหนดควรสอบถาม ในขณะที่ ` ldap_master_url<master endpoint>` คือจุดสิ้นสุดหลักหรือชุดหลักที่ใช้สำหรับการเขียนข้อมูล Zimbra ยังระบุด้วยว่า URL ของสำเนาควรปรากฏก่อน URL หลักใน `<replicas>` ldap_urlโดยที่ URL หลักจะยังคงอยู่ในรายการ

การตรวจสอบนี้มีความสำคัญอย่างยิ่งหลังจากการย้ายเซิร์ฟเวอร์ การเปลี่ยน LDAP การกำหนดหมายเลข IP ใหม่ การกู้คืนระบบจากภัยพิบัติ หรือการอัปเกรดแบบค่อยเป็นค่อยไป เซิร์ฟเวอร์ LDAP ที่ทำงานได้อย่างสมบูรณ์แบบก็ไม่สามารถช่วยโหนด Zimbra ที่ยังคงพยายามติดต่อชื่อโฮสต์ที่เลิกใช้งานแล้วได้

ตรวจสอบการแก้ไขชื่อและการเชื่อมต่อ TCP

getent hosts ldap1.example.com
nc -zv ldap1.example.com 389

หาก DNS ส่งคืนที่อยู่ที่ไม่ถูกต้อง ให้แก้ไขการแปลงชื่อโดเมนก่อน หาก DNS ถูกต้องแต่ไม่สามารถเข้าถึงพอร์ตได้ ให้ตรวจสอบการกำหนดเส้นทางเครือข่าย ไฟร์วอลล์ของโฮสต์ กลุ่มความปลอดภัย หรือตัวรับฟังของดีมอน LDAP อย่าเปลี่ยนรหัสผ่าน LDAP เพียงเพราะการเชื่อมต่อ TCP หมดเวลา เนื่องจากเวลาหมดเวลาจะเกิดขึ้นก่อนที่ระบบจะประเมินข้อมูลรับรองการเชื่อมต่อได้

คู่มือการติดตั้ง Zimbra Daffodil v10 แบบหลายเซิร์ฟเวอร์ฉบับปัจจุบัน ระบุไว้อย่างชัดเจนว่า โหนดที่ไม่ใช้ LDAP ต้องติดต่อกับเซิร์ฟเวอร์หลัก LDAP ในระหว่างการกำหนดค่า และระบุว่าการติดตั้งจะไม่สามารถดำเนินการต่อได้หากไม่สามารถติดต่อเซิร์ฟเวอร์ได้ โปรดดูคู่มือการติดตั้ง Zimbra Daffodil v10 แบบหลายเซิร์ฟเวอร์

3. อ่านบันทึกก่อนตัดสินใจว่าจะซ่อมอะไร

ใช้บันทึกข้อมูลส่วนกลางของ Zimbra เพื่อระบุประเภทของความล้มเหลว:

tail -n 100 /var/log/zimbra.log

ให้มองหารูปแบบมากกว่าแค่บรรทัดเดียว หมวดหมู่ทั่วไป ได้แก่ การหมดเวลาการเชื่อมต่อ การปฏิเสธการเชื่อมต่อ ข้อผิดพลาดเกี่ยวกับชื่อโฮสต์ ความล้มเหลวในการเชื่อมต่อ หรือข้อผิดพลาดในการตรวจสอบ TLS หมวดหมู่มีความสำคัญเพราะแต่ละหมวดหมู่ต้องการวิธีการแก้ไขที่แตกต่างกัน

• หมดเวลาหรือไม่มีเส้นทาง:ให้ตรวจสอบ DNS, การกำหนดเส้นทาง, ไฟร์วอลล์ หรือโฮสต์ที่ใช้งานไม่ได้
• การเชื่อมต่อถูกปฏิเสธ:สามารถเข้าถึงโฮสต์ได้ แต่ไม่มีสิ่งใดรับการเชื่อมต่อบนพอร์ตที่กำหนดค่าไว้ หรือไฟร์วอลล์ในเครื่องกำลังปฏิเสธการเชื่อมต่ออยู่
• ข้อผิดพลาดในการตรวจสอบ TLS/SSL:โปรดตรวจสอบใบรับรองและห่วงโซ่ความเชื่อถือ
• หาก พบข้อผิดพลาดในการตรวจสอบสิทธิ์หรือการเชื่อมต่อ ให้ตรวจสอบรหัสผ่าน LDAP หรือข้อมูลประจำตัวการจำลองข้อมูลในภายหลัง

เมื่อใบรับรองเป็นปัญหา

Zimbra ได้บันทึกกรณีที่การสื่อสาร LDAP ล้มเหลวเนื่องจาก CA ระดับรากหรือระดับกลางหมดอายุ คำสั่งตรวจสอบที่มีประโยชน์สำหรับใบรับรองเชิงพาณิชย์คือ:

/opt/zimbra/bin/zmcertmgr verifycrt comm   commercial.key commercial.crt commercial_ca.crt

เรียกใช้โปรแกรมจากไดเร็กทอรีที่มีไฟล์ใบรับรองทางการค้าที่เกี่ยวข้อง ซึ่งโดยทั่วไปจะอยู่ใน/opt/zimbra/ssl/zimbra/commercial/. หากการตรวจสอบล้มเหลว ให้แก้ไขห่วงโซ่ใบรับรองแทนที่จะปิดใช้งานการตรวจสอบ TLS เป็นทางลัด

อ้างอิง: คำแนะนำของ Zimbra สำหรับกรณี Root CA หมดอายุ และความล้มเหลวของ LDAP TLS

4. แก้ไขเอนด์พอยต์ LDAP ที่ล้าสมัยหลังจากตรวจสอบความถูกต้องของการแทนที่แล้วเท่านั้น

หากชื่อโฮสต์ที่กำหนดค่าไว้ล้าสมัยและคุณได้ตรวจสอบแล้วว่าเซิร์ฟเวอร์ LDAP ที่ใช้งานอยู่นั้นถูกต้อง ให้ทำการอัปเดตการกำหนดค่าในเครื่องในฐานะzimbraผู้ใช้ ตัวอย่างเช่น:

zmlocalconfig -e ldap_url="ldap://ldap1.example.com:389"
zmlocalconfig -e ldap_master_url="ldap://ldap1.example.com:389"

สำหรับการใช้งานที่มีเซิร์ฟเวอร์สำรอง ให้ใช้โทโพโลยีที่ระบุไว้สำหรับสภาพแวดล้อมของคุณ แทนที่จะลดรายการเหลือเพียงเซิร์ฟเวอร์เดียว เอกสารเวอร์ชัน 10 ของ Zimbra มีตัวอย่างที่เซิร์ฟเวอร์สำรองจะถูกจัดลำดับก่อนสำหรับการอ่าน และเซิร์ฟเวอร์หลักยังคงรวมอยู่ด้วย สภาพแวดล้อมที่มีเซิร์ฟเวอร์หลักหลายตัวมีข้อกำหนดลำดับเฉพาะของตนเอง

อย่าคัดลอก URL ตัวอย่างเหล่านี้โดยตรง โปรดตรวจสอบโปรโตคอล ชื่อโฮสต์ พอร์ต และบทบาทหลัก/สำรองที่ต้องการก่อน หากการใช้งานของคุณใช้ LDAPS หรือ StartTLS โปรดรักษารูปแบบการรักษาความปลอดภัยไว้ แทนที่จะเปลี่ยนไปใช้ LDAP แบบธรรมดาโดยไม่แจ้งให้ทราบล่วงหน้าเพื่อให้การเริ่มต้นระบบสำเร็จ

5. รีสตาร์ทหนึ่งครั้ง จากนั้นตรวจสอบความถูกต้องของห่วงโซ่การพึ่งพาโดยรวมทั้งหมด

หลังจากแก้ไขสาเหตุที่แท้จริงของปัญหาแล้ว ให้รีสตาร์ท Zimbra:

zmcontrol restart

จากนั้นตรวจสอบ:

ldap status
zmcontrol status

การรีสตาร์ทที่แค่เปลี่ยนข้อความแสดงข้อผิดพลาดนั้นไม่เพียงพอ ตรวจสอบ/var/log/zimbra.logการเชื่อมต่อที่ล้มเหลวซ้ำอีกครั้ง และทดสอบการดำเนินการของผู้ดูแลระบบหรือผู้ใช้ตามปกติที่เหมาะสมกับบทบาทของเซิร์ฟเวอร์

6. สภาพแวดล้อมแบบหลายเซิร์ฟเวอร์จำเป็นต้องมีการตรวจสอบการจำลองข้อมูลเพิ่มเติม

หากคุณใช้งาน LDAP replicas หรือ multiple masters เซิร์ฟเวอร์อาจยังคงเข้าถึงได้แม้ว่าการจำลองข้อมูลจะไม่สมบูรณ์ Zimbra ได้จัดทำเอกสารเกี่ยวกับzmreplchkยูทิลิตี้สำหรับตรวจสอบความถูกต้องของการจำลองข้อมูลไว้ดังนี้:

/opt/zimbra/libexec/zmreplchk

สำหรับระบบมัลติมาสเตอร์ เอกสารของ Zimbra ระบุว่าผลลัพธ์ที่ปกติคือสถานะซิงค์กันโดยมีรหัสข้อผิดพลาดเป็น 0 ขั้นตอนการกู้คืนที่แน่นอนจะขึ้นอยู่กับว่าคุณใช้การจำลองแบบมาสเตอร์เดียว การจำลองแบบมัลติมาสเตอร์ หรือการย้ายข้อมูลที่กำลังดำเนินการอยู่

โปรดดูคำแนะนำเกี่ยวกับการจำลองแบบมัลติมาสเตอร์ LDAP ของ Zimbraและเอกสารประกอบการใช้งานหลายเซิร์ฟเวอร์ของ Zimbra 10 ฉบับ ปัจจุบัน

เมื่อใดควรเปลี่ยนทิศทางการแก้ไขปัญหา

อย่ามองว่านี่เป็นเพียงปัญหาการเชื่อมต่อธรรมดา หากข้อใดข้อหนึ่งต่อไปนี้เป็นจริง:

• slapdเครื่องจะไม่เริ่มทำงานถึงแม้ว่าการตั้งค่าชื่อโฮสต์และพอร์ตจะถูกต้องแล้วก็ตาม
• รายงานบันทึกข้อผิดพลาดระบุถึงข้อผิดพลาดของฐานข้อมูลแบ็กเอนด์หรือที่เก็บข้อมูล LDAP มากกว่าข้อผิดพลาดของเครือข่าย
• การจำลองข้อมูลยังคงไม่ตรงกันแม้ว่าการเชื่อมต่อจะกลับมาใช้งานได้แล้วก็ตาม
• รหัสผ่านจะแตกต่างกันระหว่างเซิร์ฟเวอร์หลัก (master) และเซิร์ฟเวอร์สำรอง (replica) ของ LDAP หลังจากทำการย้ายข้อมูลแล้ว
• ตัวรับฟัง LDAP ไม่สามารถเชื่อมต่อได้ เนื่องจากชื่อโฮสต์ที่กำหนดค่าไว้ไม่ได้เป็นของเซิร์ฟเวอร์อีกต่อไป

ในขั้นตอนนี้ ปัญหาอาจเกี่ยวข้องกับการกู้คืนฐานข้อมูล LDAP ข้อมูลรับรองการจำลองแบบ สถานะการย้ายข้อมูล หรือข้อมูลประจำตัวของเซิร์ฟเวอร์ มากกว่าเงื่อนไขพื้นฐานที่ว่า “เซิร์ฟเวอร์ไม่ตอบสนอง” เอกสารการย้ายข้อมูลของ Zimbra ระบุไว้อย่างชัดเจนว่า DNS ความไม่ตรงกันของชื่อโฮสต์ รหัสผ่านการกำหนดค่าภายในเครื่องที่ไม่ถูกต้อง และการอ้างอิงที่ล้าสมัยไปยังเซิร์ฟเวอร์ LDAP เก่า ล้วนสามารถขัดขวางการเริ่มต้น LDAP ได้

สิ่งที่ไม่ควรทำ

• อย่าลบไฟล์ฐานข้อมูล LDAP ในขั้นตอนการแก้ไขปัญหาเบื้องต้น
• อย่ารีเซ็ตรหัสผ่าน LDAP ก่อนที่จะพิสูจน์ได้ว่าการตรวจสอบสิทธิ์เป็นสาเหตุของปัญหาในส่วนนั้น
• อย่าลบเซิร์ฟเวอร์หลักออกจาก URL ของ LDAP ทุกแห่งเพียงเพราะเซิร์ฟเวอร์สำรองตัวใดตัวหนึ่งตอบสนองอยู่
• อย่าปิดใช้งานการตรวจสอบ TLS เพียงเพื่อให้การเชื่อมต่อสำเร็จ
• อย่ารันซ้ำโดยzmcontrol restartไม่ตรวจสอบบันทึกผลลัพธ์ก่อน

รายการตรวจสอบการกู้คืนขั้นสุดท้าย

• ชื่อโฮสต์ LDAP แปลงเป็นโฮสต์ที่ต้องการ
• สามารถเข้าถึงพอร์ต LDAP จากโหนด Zimbra ที่ได้รับผลกระทบได้
• ldap_urlและldap_master_urlให้ตรงกับโครงสร้างปัจจุบัน
• ห่วงโซ่ใบรับรอง TLS จะใช้งานได้หากมีการใช้ LDAP ที่เข้ารหัส
• ldap statusslapdกำลังดำเนินการรายงาน
• zmcontrol statusแสดงให้เห็นว่าบริการที่จำเป็นกำลังทำงานอยู่
• การจำลองข้อมูลจะซิงค์กันในกรณีที่สามารถทำได้
• /var/log/zimbra.logไม่แสดงข้อผิดพลาด LDAP ซ้ำอีกต่อไปแล้ว

ข้อจำกัดหลักของกระบวนการนี้คือ “เซิร์ฟเวอร์ LDAP ไม่ตอบสนอง” เป็นเพียงอาการของความสัมพันธ์ระหว่างส่วนต่างๆ ไม่ใช่สาเหตุหลักเพียงอย่างเดียว อาจเกิดจากกระบวนการ LDAP ที่หยุดทำงาน URL ที่ล้าสมัย DNS ที่เสียหาย พอร์ตถูกบล็อก ความล้มเหลวของใบรับรอง ปัญหาการจำลองข้อมูล หรือข้อมูลประจำตัวที่ไม่ถูกต้อง ดังนั้น วิธีที่ปลอดภัยที่สุดคือ ตรวจสอบแต่ละชั้นตามลำดับ และแก้ไขเฉพาะชั้นที่ล้มเหลวเท่านั้น