แก้ไขปัญหาหน้าจอว่างเปล่าของ Zimbra Webmail หลังจากป้อนข้อมูลประจำตัว

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

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

ขั้นแรก โปรดยืนยันความหมายของวลี “หน้าจอว่างเปล่าหลังจากเข้าสู่ระบบ”

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

รายละเอียดเหล่านี้จะช่วยจำกัดขอบเขตของปัญหา หากมีเพียงเบราว์เซอร์เดียวที่ล้มเหลว สถานะเบราว์เซอร์ในเครื่องหรือส่วนขยายอาจเป็นสาเหตุ หากบัญชีหนึ่งล้มเหลวในทุกเบราว์เซอร์ในขณะที่บัญชีอื่นใช้งานได้ ให้ตรวจสอบกล่องจดหมาย การตั้งค่า การแชร์ และบันทึกกล่องจดหมายของผู้ใช้นั้น หากผู้ใช้หลายคนล้มเหลวพร้อมกัน ให้ตรวจสอบบริการไคลเอ็นต์เว็บ พร็อกซี mailboxd และการเปลี่ยนแปลงเซิร์ฟเวอร์ล่าสุด ข้อมูลเหล่านี้เป็นเพียงเบาะแสในการวินิจฉัย ไม่ใช่หลักฐานที่แน่ชัด การดำเนินการ: จดบันทึกเวลา บัญชีที่ได้รับผลกระทบ เบราว์เซอร์ หน้าจอที่แน่นอน และ URL ที่เปลี่ยนแปลงไปหรือไม่ อย่าใส่รหัสผ่านหรือคุกกี้เซสชัน

ผู้ใช้สามารถลองอะไรได้อย่างปลอดภัยบ้าง?

1. ทดสอบในโหมดหน้าต่างส่วนตัวหรือเบราว์เซอร์อื่นที่รองรับ

เปิด URL ของ Zimbra ในหน้าต่างส่วนตัวหรือโหมดไม่ระบุตัวตน แล้วลงชื่อเข้าใช้หนึ่งครั้ง หากใช้งานได้ ให้ปิดใช้งานส่วนขยายของเบราว์เซอร์ที่แก้ไขหน้าเว็บ สคริปต์ คุกกี้ หรือพฤติกรรมความเป็นส่วนตัวชั่วคราว จากนั้นทดสอบโปรไฟล์ปกติอีกครั้ง ลองใช้เบราว์เซอร์ปัจจุบันตัวที่สองเพื่อเปรียบเทียบ วิธีนี้อาจช่วยเปิดเผยปัญหาเฉพาะโปรไฟล์ได้ แต่ไม่ได้แก้ไขปัญหาฝั่งเซิร์ฟเวอร์ที่ส่งผลกระทบต่อเบราว์เซอร์ทั้งหมด

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

2. หากการทดสอบหน้าต่างส่วนตัวทำงานได้ ให้ล้างเฉพาะข้อมูลเว็บไซต์ Zimbra เท่านั้น

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

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

3. ตรวจสอบว่าความล้มเหลวเกิดขึ้นกับบัญชีเดียวหรือไม่

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

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

ผู้ดูแลระบบ Zimbra ควรตรวจสอบอะไรเป็นอันดับแรก?

เริ่มต้นด้วยเวลาที่เกิดเหตุการณ์และขอบเขตที่ได้รับผลกระทบ จากนั้นเชื่อมโยงการเข้าสู่ระบบกับบันทึกของ Zimbra หน้าการแก้ไขปัญหาอย่างเป็นทางการของ Zimbra สำหรับการเข้าสู่ระบบที่ค้างอยู่แนะนำให้เริ่มต้นด้วยmailbox.logและตรวจสอบบันทึกอื่นๆ ที่เกี่ยวข้อง บันทึกอ้างอิงของ Zimbra แสดงรายการ/opt/zimbra/log/mailbox.log, audit.log, nginx.access.log, nginx.log, และzmmailboxd.outโดยเตือนว่าตำแหน่งของบันทึกขึ้นอยู่กับการใช้งาน

บนเซิร์ฟเวอร์ที่จัดการคำขอที่ได้รับผลกระทบ ผู้ดูแลระบบสามารถตรวจสอบบันทึกที่เกี่ยวข้องในขณะที่จำลองปัญหาได้:

su - zimbra
tail -f /opt/zimbra/log/mailbox.log /opt/zimbra/log/nginx.access.log /opt/zimbra/log/nginx.log

ใช้เฉพาะเส้นทางที่มีอยู่ในระบบของคุณเท่านั้น ในการติดตั้งแบบหลายเซิร์ฟเวอร์ บันทึกของพร็อกซีและกล่องจดหมายอาจอยู่บนโฮสต์ที่แตกต่างกัน หยุดการบันทึกแบบเรียลไทม์ด้วย Ctrl+C หลังจากการจำลองที่ควบคุมได้หนึ่งครั้ง การดำเนินการ: จับคู่เวลาหนึ่งกับคำขอของไคลเอ็นต์และมองหาการตรวจสอบสิทธิ์ที่สำเร็จตามด้วยคำขอกล่องจดหมาย พร็อกซี หรือไคลเอ็นต์เว็บที่ล้มเหลว แชร์ข้อความที่ตัดตอนมาสั้น ๆ แทนที่จะแชร์บันทึกฉบับเต็มที่มีข้อมูลส่วนบุคคล

แหล่งที่มา: บทความการแก้ไขปัญหาหลังการเข้าสู่ระบบของ Zimbraและเอกสารอ้างอิงไฟล์บันทึกของ Zimbra

ข้อผิดพลาดของพร็อกซีและกล่องจดหมายส่งผลต่อการวินิจฉัยอย่างไร?

หากผู้ใช้เข้าถึง Zimbra ผ่าน Zimbra Proxy โปรดตรวจสอบบันทึกของพร็อกซี รวมถึงบันทึกของเซิร์ฟเวอร์เมลบ็อกซ์ด้วย เอกสารอ้างอิงการแก้ไขปัญหาพร็อกซีของ Zimbra ระบุnginx.logและnginx.access.logอธิบายว่าการตอบสนอง 502 และ 503 เป็นความล้มเหลวของต้นทางหรือบริการ คำแนะนำระบุว่า 503 มักเกิดขึ้นเมื่อกระบวนการ Jetty mailboxd ไม่พร้อมใช้งาน การตอบสนอง 5xx เป็นเบาะแสที่ชัดเจนกว่าหน้าว่างเปล่า แต่คำขอและโฮสต์ที่แน่นอนยังคงมีความสำคัญ

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

ผู้ดูแลระบบสามารถใช้ยูทิลิตี้ควบคุม Zimbra เพื่อตรวจสอบสถานะการให้บริการได้:

su - zimbra
zmcontrol status

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

ปัญหานี้เป็นปัญหาเฉพาะเวอร์ชันของเว็บไคลเอ็นต์เมื่อใด?

เอกสารวิกิของ Zimbra รวบรวมกรณีหน้าว่างที่เกิดขึ้นหลังจากการอัปเกรดเป็น ZCS เวอร์ชันเก่าๆ บางเวอร์ชัน บทความหนึ่งระบุว่าวิธีการแก้ไขการลงทะเบียนบริการใช้ได้กับ ZCS 8.6 และ 8.7.0/8.7.1 และแสดงการตอบสนอง 404 จากเว็บไคลเอ็นต์ อีกบทความหนึ่งกล่าวถึงสถานการณ์การแก้ไขแพทช์เวอร์ชัน 8.8.15 และ 9.0.0 ที่มีข้อผิดพลาดในการเริ่มต้น mailboxd และการตอบสนอง 503 กรณีเหล่านี้เป็นกรณีเฉพาะเวอร์ชัน ไม่ใช่คำแนะนำทั่วไปสำหรับระบบ Zimbra ในปัจจุบัน

อย่าคัดลอกคำสั่งหรือลบไฟล์เซิร์ฟเวอร์เพียงเพราะอาการดูคล้ายกัน ก่อนอื่นให้ตรวจสอบเวอร์ชัน Zimbra ระดับแพทช์ ประวัติการอัปเกรด การตอบสนอง HTTP และรูปแบบข้อผิดพลาดที่อธิบายไว้ในบทความที่เกี่ยวข้องให้แน่ชัด บทความในวิกิเป็นหน้าแก้ไขปัญหาแบบเก่า และบางหน้าถูกทำเครื่องหมายว่าอยู่ในระหว่างการพัฒนา การดำเนินการ: หากรูปแบบข้อผิดพลาดและเวอร์ชันตรงกัน ให้ผู้ดูแลระบบ Zimbra หรือผู้ให้บริการสนับสนุนตรวจสอบวิธีแก้ไขกับเวอร์ชันที่ติดตั้งก่อนทำการเปลี่ยนแปลงใดๆ ตรวจสอบบทความหน้าว่างในอดีตและกรณี mailboxd/Jetty แยกต่างหากสำหรับขอบเขตที่ระบุไว้

ควรใช้เครื่องมือสำหรับนักพัฒนาเบราว์เซอร์เฉพาะเมื่อบันทึกของเซิร์ฟเวอร์ไม่ชัดเจนเท่านั้น

ผู้ดูแลระบบหรือช่างเทคนิคฝ่ายสนับสนุนสามารถตรวจสอบแผงเครือข่ายและคอนโซลของเบราว์เซอร์ขณะที่กำลังจำลองปัญหาได้ ให้มองหา JavaScript หรือไฟล์สไตล์ชีตที่ล้มเหลว การเปลี่ยนเส้นทางซ้ำๆ คำขอที่ถูกบล็อก คำเตือนเนื้อหาผสม และการเรียกใช้ API หรือ SOAP ที่ล้มเหลว การเข้าสู่ระบบสำเร็จแล้วตามด้วยข้อผิดพลาด 404 สำหรับไฟล์ฝั่งไคลเอ็นต์เว็บ ชี้ไปยังเลเยอร์ที่แตกต่างจากข้อผิดพลาด 502/503 จากบริการกล่องจดหมาย ข้อผิดพลาด JavaScript อาจระบุถึงความล้มเหลวฝั่งไคลเอ็นต์ แต่ข้อผิดพลาดแรกที่มองเห็นได้นั้นไม่ใช่สาเหตุหลักเสมอไป

การดำเนินการ: บันทึกเส้นทางการร้องขอที่ล้มเหลว รหัสสถานะ เวลา และข้อความคอนโซลที่ปกปิดข้อมูลบางส่วน อย่าแชร์ไฟล์ HAR ที่ไม่ได้กรอง ส่วนหัวการอนุญาต การตอบสนองการเข้าสู่ระบบ เนื้อหากล่องจดหมาย หรือคุกกี้: สิ่งเหล่านี้อาจเปิดเผยข้อมูลประจำตัวเซสชันที่ใช้งานอยู่และข้อความส่วนตัว หากการร้องขอทุกครั้งสำเร็จ แต่หน้าเว็บยังคงว่างเปล่า ให้เปรียบเทียบกับเบราว์เซอร์อื่นและตรวจสอบการปรับแต่งฝั่งไคลเอ็นต์หรือข้อบกพร่องของเว็บไคลเอ็นต์เฉพาะรุ่น

คุณตรวจสอบการซ่อมแซมได้อย่างไร?

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

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