แก้ไขข้อผิดพลาด 500 ที่เกิดขึ้นระหว่างการรีเฟรชที่เก็บข้อมูล Zypper ใน SLES

ตัวอย่างประกอบ:ลองนึกภาพว่าผู้ดูแลระบบ SLES ชื่อมายา กำลังดำเนินการsudo zypper refreshหลังจากช่วงเวลาการบำรุงรักษาตามปกติ ที่เก็บข้อมูลหนึ่งส่งคืนข้อความ “ข้อผิดพลาด 500: ข้อผิดพลาดภายในเซิร์ฟเวอร์” ในขณะที่ที่เก็บข้อมูลอื่นๆ รีเฟรชได้ ตัวอย่างของมายาเป็นเพียงสมมติฐาน แต่แสดงให้เห็นถึงประเด็นสำคัญในการวินิจฉัย: HTTP 500 เป็นการตอบสนองจากเซิร์ฟเวอร์หรือตัวกลาง เช่น พร็อกซี ไม่ใช่หลักฐานว่าแคชเมตาเดต้าในเครื่องของ Zypper เสียหาย

เพื่อแก้ไขปัญหาการรีเฟรชข้อมูลใน Zypper repository ที่ล้มเหลวใน SUSE Linux Enterprise Server (SLES) ขั้นแรกให้ระบุ repository และ URL ที่ล้มเหลวอย่างแม่นยำ จากนั้นตรวจสอบว่าการตอบสนองมาจาก SUSE Customer Center (SCC) เซิร์ฟเวอร์ Repository Mirroring Tool (RMT) ภายใน หรือพร็อกซีเครือข่าย ลองรีเฟรชข้อมูลเมตาแบบบังคับอีกครั้งหลังจากตรวจสอบปลายทางแล้ว การลงทะเบียนเครื่องใหม่หรือการลบการกำหนดค่า repository โดยไม่มีหลักฐานอาจทำให้การวินิจฉัยปัญหายากขึ้น

ข้อผิดพลาด HTTP 500 ระหว่างการรีเฟรชบอกอะไรคุณบ้าง

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

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

1. ระบุแหล่งที่มาของข้อมูลและบันทึกข้อผิดพลาดที่เกิดขึ้นอย่างแม่นยำ

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

sudo zypper refresh

จากนั้นแสดงรายการนามแฝงของที่เก็บข้อมูลและ URL ที่กำหนดค่าไว้:

zypper lr -u

จับคู่ชื่อแทน (alias) ที่ล้มเหลวในผลลัพธ์การรีเฟรชกับ URI ในรายการนี้ URI ที่โฮสต์อยู่ที่ RMT ขององค์กรหรือเซิร์ฟเวอร์มิเรอร์ส่วนตัวอื่น ๆ ควรตรวจสอบกับผู้ดูแลระบบของเซิร์ฟเวอร์นั้น URI ที่ชี้ไปยังบริการ SUSE สาธารณะ ควรตรวจสอบจากเครือข่ายที่ได้รับผลกระทบ และถ้าเป็นไปได้ ให้ตรวจสอบจากเครือข่ายที่สองหรือไคลเอ็นต์ SLES อื่นด้วย

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

2. ตรวจสอบว่าข้อผิดพลาดนั้นเกิดขึ้นที่เครื่องภายใน (local), ที่เครื่องอื่น (shared) หรือที่เครื่องต้นทาง (upstream)

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

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

curl -sS -L -D - -o /dev/null 'https://repository.example.invalid/path/to/metadata'

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

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

3. ตรวจสอบการตั้งค่าพร็อกซีและเครือข่าย

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

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

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

4. ตรวจสอบการลงทะเบียน SLES และ URL ของที่เก็บข้อมูล

สำหรับแหล่งเก็บข้อมูลที่ได้รับผ่านการลงทะเบียน SUSE โปรดตรวจสอบผลิตภัณฑ์และโมดูลที่ลงทะเบียนไว้ในระบบ:

SUSEConnect -s
zypper lr -u

เอกสารของ SUSE ใช้SUSEConnect -sสำหรับตรวจสอบผลิตภัณฑ์ที่ติดตั้งในเครื่องและสถานะของผลิตภัณฑ์เหล่านั้น รวมzypper lr -uถึงแสดงรายการที่เก็บข้อมูลพร้อม URI ของแหล่งที่มา เปรียบเทียบผลลัพธ์กับเวอร์ชัน SLES และโมดูลที่เครื่องนี้ควรใช้งาน หาก URI ไม่ถูกต้องหรือล้าสมัย อาจทำให้เกิดข้อผิดพลาดจากปลายทางที่เลิกใช้งาน ไม่ตรงกัน หรือกำหนดค่าไม่ถูกต้อง

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

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

5. ลองรีเฟรชหน้าเว็บอีกครั้งแบบบังคับหลังจากที่ปลายทางกลับมาใช้งานได้ปกติแล้ว

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

sudo zypper refresh

หากเมตาเดต้ายังคงดูเก่าหรือไม่สมบูรณ์ ให้ใช้ฟังก์ชันการรีเฟรชแบบเต็มรูปแบบตามที่เอกสารของ SUSE ระบุไว้:

sudo zypper refresh -fdb

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

6. จัดการกับ repository เสริมที่เสียหายหนึ่งรายการอย่างปลอดภัย

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

sudo zypper modifyrepo --disable REPOSITORY_ALIAS

ใช้นามแฝงที่ถูกต้องจากzypper lrและบันทึกการเปลี่ยนแปลง การปิดใช้งานที่เก็บข้อมูลอาจป้องกันการอัปเดตซอฟต์แวร์ที่ติดตั้งจากที่เก็บข้อมูลนั้น อย่าปิดใช้งานที่เก็บข้อมูลการอัปเดตหลักของ SLES เป็นวิธีแก้ปัญหาแบบเหมาหมด และอย่าลบคำจำกัดความของที่เก็บข้อมูลเพียงเพื่อระงับข้อผิดพลาด เปิดใช้งานที่เก็บข้อมูลที่ถูกปิดใช้งานชั่วคราวอีกครั้งหลังจากผู้ดูแลระบบยืนยันการกู้คืนแล้ว

sudo zypper modifyrepo --enable REPOSITORY_ALIAS

คู่มือการดูแลระบบ SLES อธิบายวิธีการเปิดใช้งานและปิดใช้งานที่เก็บข้อมูล (repository zypper modifyrepo) พฤติกรรมของที่เก็บข้อมูลและตัวเลือกที่มีให้ใช้งานอาจแตกต่างกันไปตามเวอร์ชันของ Zypper ที่ติดตั้ง โปรดตรวจสอบzypper help modifyrepoบนเครื่องโฮสต์หากไวยากรณ์ของตัวเลือกแตกต่างกัน

ตรวจสอบการซ่อมแซม

เสร็จสิ้นด้วยการรีเฟรชระบบอย่างหมดจด และตรวจสอบว่าที่เก็บข้อมูลใดบ้างที่เปิดใช้งานและกำหนดเวลาให้รีเฟรช:

sudo zypper refresh
zypper lr -u

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

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

เมื่อใดควรยกระดับปัญหา

ติดต่อทีมมิเรอร์หรือพร็อกซีเมื่อไคลเอนต์หลายรายได้รับข้อความตอบกลับเดียวกันจากเอนด์พอยต์ภายใน ติดต่อเจ้าของที่เก็บข้อมูลหรือฝ่ายสนับสนุน SUSE เมื่อสามารถจำลองข้อผิดพลาดได้กับเอนด์พอยต์ SUSE อย่างเป็นทางการหลังจากตรวจสอบเส้นทางเครือข่ายภายในและการลงทะเบียนแล้ว โปรดระบุรุ่น SLES และ Service Pack, ชื่อเรียกแทนของที่เก็บข้อมูล, ชื่อโฮสต์ (โดยลบรายละเอียดเส้นทางที่ละเอียดอ่อนออก), เวลาและเขตเวลา, ว่าที่เก็บข้อมูลอื่น ๆ รีเฟรชหรือไม่ และสถานะ HTTP หรือข้อความแสดงข้อผิดพลาดที่กรองแล้ว หลักฐานเหล่านี้จะช่วยให้เจ้าของบริการติดตามคำขอที่ล้มเหลวโดยไม่ต้องเปิดเผยรหัสการลงทะเบียนหรือข้อมูลประจำตัว