SLES Zypper HTTP 500: ค้นหาแหล่งเก็บข้อมูลที่ล้มเหลว

เมื่อzypper refreshพบข้อผิดพลาด HTTP 500 บน SLES ขั้นแรกให้ระบุว่า URL ของที่เก็บข้อมูลใดส่งคืนข้อผิดพลาดนั้น HTTP 500 หมายความว่าเซิร์ฟเวอร์ที่จัดการคำขอพบเงื่อนไขที่ไม่คาดคิด ผู้ตอบสนองอาจเป็นโฮสต์ของที่เก็บข้อมูล เซิร์ฟเวอร์ RMT ขององค์กร หรือพร็อกซี HTTP แยกที่เก็บข้อมูลที่ล้มเหลวและซ่อมแซมหรือรายงานปลายทางนั้นก่อนที่จะล้างเมตาเดตาในเครื่อง การสร้างแคชใหม่แบบบังคับไม่สามารถซ่อมแซมเซิร์ฟเวอร์ที่ยังคงส่งคืนข้อผิดพลาด 500 ได้

คู่มือการดูแลระบบและการอัปเกรด SLES 15 SP7 ฉบับปัจจุบันของ SUSE ได้บันทึกรายการคลังข้อมูลและคำสั่งรีเฟรช รวมถึงคำสั่งzypper refresh -fdbสำหรับการสร้างเมตาเดตาของคลังข้อมูลภายในเครื่องขึ้นใหม่ แต่ไม่ได้ระบุถึงเหตุการณ์ HTTP 500 ที่เกิดขึ้นทั่วทั้ง SLES ในปัจจุบัน วิธีแก้ไขที่ได้ผลจริงนั้นขึ้นอยู่กับว่า URL นั้นเป็นของ SUSE Customer Center, คลังข้อมูลภายใน หรือคลังข้อมูลของบุคคลที่สาม

มีแหล่งเก็บข้อมูลเพียงแห่งเดียวที่ล้มเหลว หรือหลายแห่งล้มเหลว?

เริ่มต้นด้วยการบันทึกชื่อเรียกแทน (alias) และ URL ของที่เก็บข้อมูล (repository) ไว้ บน SLES ให้รันคำสั่ง:

zypper repos -u

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

ถัดไป ให้รีเฟรชเฉพาะที่เก็บข้อมูลที่ได้รับผลกระทบโดยใช้ชื่อแทน:

sudo zypper refresh -f 'Vendor-App'

แทนที่Vendor-Appด้วยชื่อเรียกแทนที่ถูกต้องตามที่แสดงโดยzypper repos -u. วิธีนี้จะช่วยหลีกเลี่ยงข้อผิดพลาดซ้ำซ้อนจากแหล่งเก็บข้อมูลที่ไม่เกี่ยวข้อง และให้ผลลัพธ์ที่ตรงประเด็นเพื่อแชร์กับผู้ดูแลระบบ หากชื่อเรียกแทนมีช่องว่าง ให้คงเครื่องหมายอัญประกาศเดี่ยวไว้ เก็บ URL และเวลาที่เกิดข้อผิดพลาดไว้ แต่ให้ลบชื่อผู้ใช้ รหัสผ่าน โทเค็น หรือข้อมูลลับอื่นๆ ที่ฝังอยู่ก่อนส่งบันทึกหรือภาพหน้าจอ

เอนด์พอยต์เมตาเดตาเองส่งคืนรหัส HTTP 500 หรือไม่?

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

curl -sS -D - -o /dev/null --max-time 20 "$METADATA_URL"

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

ข้อความตอบกลับ 500 แตกต่างจากปัญหาแคชเมตาเดต้าในเครื่อง นอกจากนี้ยังแตกต่างจากความล้มเหลวของ DNS ข้อผิดพลาดของใบรับรอง TLS การหมดเวลา และการตอบสนองการตรวจสอบสิทธิ์ เช่น 401 หรือ 403 ข้อความเหล่านั้นต้องการการตรวจสอบที่แตกต่างกัน อย่าปิดใช้งานการตรวจสอบ TLS เปลี่ยนที่เก็บข้อมูลเป็น HTTP ธรรมดา หรือลบแคชซ้ำ ๆ เพื่อให้ข้อความ 500 หายไป สำหรับความหมายของ HTTP นั้น RFC 9110 กำหนดว่า 500 คือสภาวะเซิร์ฟเวอร์ที่ไม่คาดคิดซึ่งทำให้ไม่สามารถดำเนินการตามคำขอได้

ควรทำการซ่อมแซมตรงไหน?

• ที่เก็บข้อมูล SUSE Customer Center:ลองใหม่อีกครั้งหลังจากช่วงเวลาสั้นๆ หากความล้มเหลวดูเหมือนจะเป็นเพียงชั่วคราว หากปลายทางที่โฮสต์โดย SUSE เดียวกันยังคงส่งคืนรหัส 500 ให้บันทึกผลิตภัณฑ์ Service Pack สถาปัตยกรรม URL ของที่เก็บข้อมูล และเวลาที่เกิดความล้มเหลว จากนั้นตรวจสอบช่องทางการสนับสนุน SUSE ขององค์กรของคุณ ยืนยันรายละเอียดการลงทะเบียนและการสมัครใช้งานหากการตอบสนองบ่งชี้ถึงปัญหาด้านสิทธิ์หรือการเข้าถึง รหัส HTTP 500 เพียงอย่างเดียวไม่ได้บ่งชี้ว่าการสมัครใช้งานไม่ถูกต้อง
• RMT หรือเซิร์ฟเวอร์มิเรอร์ภายในอื่นๆ:ขอให้ผู้ดูแลระบบมิเรอร์ตรวจสอบบันทึกของเซิร์ฟเวอร์และรีเวิร์สพร็อกซีในช่วงเวลาที่บันทึกไว้ ยืนยันว่าที่เก็บข้อมูลที่ร้องขอเปิดใช้งานและซิงโครไนซ์แล้ว และตรวจสอบว่าไฟล์เมตาเดตาอยู่ที่พาธที่ให้บริการหรือไม่ เอกสารของ SUSE ระบุว่า RMT เป็นวิธีที่ไคลเอ็นต์ SLES สามารถดึงข้อมูลอัปเดตจากเซิร์ฟเวอร์ภายในเครื่องแทนการติดต่อ SCC โดยตรง
• แหล่งเก็บข้อมูลของบุคคลที่สาม:ตรวจสอบคำแนะนำแหล่งเก็บข้อมูลปัจจุบันของผู้จำหน่ายและยืนยันว่า URL ตรงกับเวอร์ชันและสถาปัตยกรรมของ SLES ที่ติดตั้งไว้ หากแหล่งที่มามีการเปลี่ยนแปลง ให้ทำการอัปเดตเฉพาะ URL ที่เผยแพร่โดยผู้จำหน่ายนั้นเท่านั้น ปิดใช้งานแหล่งเก็บข้อมูลหลังจากยืนยันแล้วว่าเป็นทางเลือกและไม่จำเป็นอีกต่อไป อย่าปิดใช้งานแหล่งอัปเดต SLES ที่จำเป็นเพื่อซ่อนข้อผิดพลาด

คุณสามารถตรวจสอบและเปลี่ยนแปลงสถานะของที่เก็บข้อมูลได้ด้วย Zypper หรือ YaST ตัวอย่างเช่นzypper modifyrepoคำสั่งที่ระบุไว้ในเอกสารสามารถปิดใช้งานที่เก็บข้อมูลโดยใช้นามแฝงได้ แต่เป็นการเลือกใช้งานชั่วคราว ไม่ใช่การซ่อมแซมแหล่งข้อมูลที่จำเป็นซึ่งล้มเหลว หลีกเลี่ยงการแก้ไข URL ของที่เก็บข้อมูลที่สร้างขึ้นโดยการคาดเดา โดยเฉพาะอย่างยิ่งหลังจากการย้าย Service Pack เนื่องจากที่เก็บข้อมูลผลิตภัณฑ์และการอัปเดตใช้เส้นทางเฉพาะเวอร์ชัน

คุณควรสร้างแคชเมตาเดต้าในเครื่องใหม่เมื่อใด?

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

sudo zypper refresh -f

หากขณะนี้ปลายทางตอบสนองแล้ว แต่ Zypper ยังคงรายงานว่าข้อมูลในที่เก็บข้อมูลภายในเครื่องล้าสมัยหรือไม่สอดคล้องกัน ส่วนการแก้ไขปัญหาของ SUSE SLES 15 SP7 แนะนำให้รีเฟรชเมตาเดต้าและสร้างฐานข้อมูลใหม่ทั้งหมดโดยใช้คำสั่งต่อไปนี้:

sudo zypper refresh -fdb

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

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

เริ่ม จากการรัน zypper refresh -f 'ALIAS'โค้ดสำหรับแหล่งที่มาที่เคยมีปัญหา จากนั้นจึงรันsudo zypper refresh -fสำหรับแหล่งเก็บข้อมูลที่เปิดใช้งานทั้งหมด การแก้ไขจะได้รับการยืนยันเมื่อดาวน์โหลดเมตาเดต้าของแหล่งเก็บข้อมูลที่ได้รับผลกระทบได้โดยไม่มีข้อผิดพลาด HTTP 500 และ Zypper ทำงานเสร็จสิ้นโดยไม่มีแหล่งที่มาที่เปิดใช้งานใดล้มเหลว หากยังมีแหล่งที่มาใดล้มเหลวอยู่ ให้เก็บ URL รหัสสถานะ ส่วนหัวการตอบกลับ และเวลาที่แน่นอนไว้ แล้วส่งให้เจ้าของปลายทางนั้น

ข้อมูลอ้างอิงอย่างเป็นทางการ

• คู่มือการดูแลระบบ SUSE SLES 15 SP7 — การจัดการที่เก็บข้อมูลและการรีเฟรชเมตาเดต้าแบบบังคับตามเอกสาร
• คู่มือการอัปเกรด SUSE SLES 15 SP7 — รายชื่อที่เก็บซอฟต์แวร์ที่ลงทะเบียนไว้และ URL ของแหล่งที่มา
• คู่มือเครื่องมือการทำมิเรอร์ที่เก็บข้อมูล (Repository Mirroring Tool: RMT) สำหรับ SUSE SLES 15 SP7 — การกำหนดค่าไคลเอ็นต์เพื่อใช้งาน RMT
• IETF RFC 9110: ความหมายของ HTTP — คำจำกัดความของรหัสสถานะ HTTP รวมถึง 500 Internal Server Error