Linux มีหลายรูปแบบ: วิธีทำงานกับการกระจายแบบใดก็ได้

การสร้างแอปพลิเคชันสำรองข้อมูลที่ทำงานกับการกระจายใดๆ ไม่ใช่เรื่องง่าย เพื่อให้แน่ใจว่า Veeam Agent สำหรับ Linux ทำงานบนการกระจายตั้งแต่ Red Hat 6 และ Debian 6 ไปจนถึง OpenSUSE 15.1 และ Ubuntu 19.04 คุณต้องแก้ไขปัญหาต่างๆ มากมาย โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่าผลิตภัณฑ์ซอฟต์แวร์มีโมดูลเคอร์เนล

บทความนี้สร้างขึ้นจากเนื้อหาจากการกล่าวสุนทรพจน์ในที่ประชุม ลินุกซ์ปีเตอร์ 2019.

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

ผู้จัดการแพ็คเกจ .deb กับ .rpm

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

ในโลกของแพ็คเกจ deb ระดับความเข้ากันได้นั้นน่าทึ่งมาก แพ็คเกจเดียวกันนี้ติดตั้งและทำงานได้ดีทั้งบน Debian 6 และ Ubuntu 19.04 มาตรฐานสำหรับกระบวนการสร้างแพ็คเกจและการทำงานร่วมกับพวกเขาซึ่งวางอยู่ในการแจกแจง Debian แบบเก่ายังคงมีความเกี่ยวข้องใน Linux Mint และระบบปฏิบัติการระดับประถมศึกษารุ่นใหม่ ดังนั้น ในกรณีของ Veeam Agent สำหรับ Linux หนึ่งแพ็คเกจ deb สำหรับแต่ละแพลตฟอร์มฮาร์ดแวร์ก็เพียงพอแล้ว

แต่ในโลกของแพ็คเกจ rpm ความแตกต่างนั้นยิ่งใหญ่ ประการแรกเนื่องจากมีผู้จัดจำหน่ายอิสระสองรายคือ Red Hat และ SUSE ซึ่งความเข้ากันได้นั้นไม่จำเป็นเลย ประการที่สอง ผู้จัดจำหน่ายเหล่านี้มีชุดแจกจ่ายจากสิ่งเหล่านั้น การสนับสนุนและการทดลอง ไม่จำเป็นต้องมีความเข้ากันได้ระหว่างกัน ปรากฎว่า el6, el7 และ el8 มีแพ็คเกจของตัวเอง แยกแพ็คเกจสำหรับ Fedora แพ็คเกจสำหรับ SLES11 และ 12 และแพ็คเกจแยกต่างหากสำหรับ openSUSE ปัญหาหลักคือการขึ้นต่อกันและชื่อแพ็คเกจ

ปัญหาการพึ่งพา

น่าเสียดายที่แพ็คเกจเดียวกันมักจะลงเอยด้วยชื่อที่แตกต่างกันในการแจกแจงที่แตกต่างกัน ด้านล่างนี้เป็นรายการการขึ้นต่อกันของแพ็คเกจ veeam บางส่วน

สำหรับ EL7:
สำหรับ SLES 12:

• libblkid
• libgcc
• libstdc ++
• ncurses-libs
• ฟิวส์-libs
• ไฟล์-libs
• veamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc ++ 6
• libmagic1
• ลิบฟิวส์2
• veamsnap-kmp=3.0.2.1185

ด้วยเหตุนี้ รายการการขึ้นต่อกันจึงไม่ซ้ำกันสำหรับการแจกจ่าย

สิ่งที่แย่กว่านั้นคือเมื่อเวอร์ชันอัปเดตเริ่มซ่อนอยู่ใต้ชื่อแพ็คเกจเก่า

ตัวอย่าง:

แพ็คเกจนี้ได้รับการอัพเดตใน Fedora 24 พยาบาล ตั้งแต่เวอร์ชัน 5 ถึงเวอร์ชัน 6 ผลิตภัณฑ์ของเราสร้างขึ้นด้วยเวอร์ชัน 5 เพื่อให้มั่นใจว่าสามารถใช้งานร่วมกับเวอร์ชันเก่าได้ หากต้องการใช้ไลบรารีเวอร์ชันเก่าที่ 5 บน Fedora 24 ฉันต้องใช้แพ็คเกจนี้ ncurses-compat-libs.

ด้วยเหตุนี้ Fedora จึงมีสองแพ็คเกจที่มีการขึ้นต่อกันที่แตกต่างกัน

ที่น่าสนใจยิ่งขึ้นไปอีก หลังจากการอัพเดตการแจกจ่ายครั้งถัดไป แพ็คเกจ ncurses-compat-libs ด้วยไลบรารีเวอร์ชัน 5 ปรากฏว่าไม่พร้อมใช้งาน มีราคาแพงสำหรับผู้จัดจำหน่ายที่จะลากไลบรารีเก่าไปไว้ในเวอร์ชันใหม่ของการแจกจ่าย หลังจากนั้นครู่หนึ่ง ปัญหาเกิดซ้ำอีกครั้งในการแจกแจง SUSE

เป็นผลให้การแจกแจงบางส่วนต้องยกเลิกการพึ่งพาอย่างชัดเจน ncurses-libsและแก้ไขผลิตภัณฑ์เพื่อให้สามารถทำงานกับไลบรารีเวอร์ชันใดก็ได้

อย่างไรก็ตามใน Red Hat เวอร์ชัน 8 จะไม่มีแพ็คเกจเมตาอีกต่อไป หลามซึ่งหมายถึงความเก่าแก่ที่ดี หลาม 2.7. มี python2 и หลาม3.

ทางเลือกแทนผู้จัดการแพ็คเกจ

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

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

Flatpak ยังช่วยให้คุณเรียกใช้แอปพลิเคชันในแซนด์บ็อกซ์โดยใช้ Linux Containers แนวคิดแซนด์บ็อกซ์ก็ถูกนำมาใช้เช่นกัน AppImage.

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

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

ปัญหาที่สองคือการกระจายที่ได้รับความนิยมในสภาพแวดล้อมองค์กรจาก Red Hat และ SUSE ยังไม่รองรับ Snappy และ Flatpak

ในเรื่องนี้ Veeam Agent สำหรับ Linux ไม่พร้อมใช้งาน snapcraft.io ไม่เลย flathub.org.

เพื่อสรุปคำถามเกี่ยวกับตัวจัดการแพ็คเกจ ฉันอยากจะทราบว่ามีตัวเลือกในการละทิ้งตัวจัดการแพ็คเกจไปพร้อมกันโดยการรวมไฟล์ไบนารี่และสคริปต์เพื่อติดตั้งเป็นแพ็คเกจเดียว

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

อัปเดตปัญหา

แม้ว่าปัญหาการขึ้นต่อกันทั้งหมดจะได้รับการแก้ไข โปรแกรมอาจทำงานแตกต่างกันในการแจกจ่ายเดียวกัน มันเกี่ยวกับการอัปเดต

มี 3 กลยุทธ์ในการอัปเดต:

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

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

แพลตฟอร์มฮาร์ดแวร์ที่หลากหลาย

แพลตฟอร์มฮาร์ดแวร์ที่แตกต่างกันเป็นปัญหาที่เฉพาะเจาะจงกับโค้ดเนทีฟเป็นส่วนใหญ่ อย่างน้อยที่สุด คุณจะต้องรวบรวมไบนารีสำหรับแต่ละแพลตฟอร์มที่รองรับ

ในโครงการ Veeam Agent สำหรับ Linux เรายังไม่สามารถสนับสนุนอะไรทำนองนี้ RISC ได้

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

การเชื่อมโยงแบบคงที่และ/หรือแบบไดนามิก

แต่คำถามคือ “จะเชื่อมโยงกับไลบรารี่ได้อย่างไร - แบบไดนามิกหรือแบบคงที่” คุ้มค่าที่จะพูดคุย

ตามกฎแล้ว แอปพลิเคชัน C/C++ ภายใต้ Linux จะใช้การลิงก์แบบไดนามิก วิธีนี้ใช้งานได้ดีหากแอปพลิเคชันสร้างขึ้นเพื่อการแจกจ่ายเฉพาะโดยเฉพาะ

หากงานคือการครอบคลุมการแจกแจงต่างๆ ด้วยไฟล์ไบนารี่เดียว คุณจะต้องมุ่งเน้นไปที่การแจกแจงที่เก่าที่สุดที่รองรับ สำหรับเรา นี่คือ Red Hat 6 ซึ่งมี gcc 4.4 ซึ่งแม้แต่มาตรฐาน C++11 ก็ไม่รองรับ อย่างเต็มที่.

เราสร้างโครงการของเราโดยใช้ gcc 6.3 ซึ่งรองรับ C++ 14 อย่างสมบูรณ์ โดยปกติแล้ว ในกรณีนี้ บน Red Hat 6 คุณจะต้องพกพา libstdc++ และบูสต์ไลบรารี่ติดตัวไปด้วย วิธีที่ง่ายที่สุดคือการเชื่อมโยงไปยังสิ่งเหล่านั้นแบบคงที่

แต่น่าเสียดาย ไม่ใช่ว่าทุกไลบรารีจะสามารถเชื่อมโยงแบบคงที่ได้

ประการแรก ไลบรารีระบบ เช่น ลิฟฟิวส์, libblkid จำเป็นต้องเชื่อมโยงแบบไดนามิกเพื่อให้แน่ใจว่าสามารถทำงานร่วมกับเคอร์เนลและโมดูลได้

ประการที่สอง มีความละเอียดอ่อนเกี่ยวกับใบอนุญาต

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

โดยทั่วไป การใช้การเชื่อมโยงแบบไดนามิกจะป้องกันไม่ให้คุณไม่ต้องจัดเตรียมสิ่งใดๆ

การสร้างแอปพลิเคชัน C/C++

หากต้องการสร้างแอปพลิเคชัน C/C++ สำหรับแพลตฟอร์มและการแจกจ่ายที่แตกต่างกัน ก็เพียงพอที่จะเลือกหรือสร้าง gcc เวอร์ชันที่เหมาะสม และใช้คอมไพเลอร์ข้ามสำหรับสถาปัตยกรรมเฉพาะ และประกอบชุดไลบรารีทั้งหมด งานนี้ค่อนข้างเป็นไปได้แต่ค่อนข้างลำบาก และไม่มีการรับประกันว่าคอมไพเลอร์และไลบรารีที่เลือกจะมีเวอร์ชันที่ใช้งานได้

ข้อได้เปรียบที่ชัดเจน: โครงสร้างพื้นฐานนั้นง่ายขึ้นอย่างมาก เนื่องจากกระบวนการสร้างทั้งหมดสามารถทำได้ในเครื่องเดียว นอกจากนี้ การรวบรวมไบนารีหนึ่งชุดสำหรับสถาปัตยกรรมหนึ่งๆ ก็เพียงพอแล้ว และคุณสามารถจัดแพ็คเกจเป็นแพ็คเกจสำหรับการแจกจ่ายที่แตกต่างกันได้ นี่คือวิธีการสร้างแพ็คเกจ veeam สำหรับ Veeam Agent สำหรับ Linux

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

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

นี่คือวิธีการคอมไพล์แพ็คเกจ KMOD ของโมดูลเคอร์เนล veemsnap สำหรับการแจกแจง Red Hat

เปิดบริการสร้าง

เพื่อนร่วมงานจาก SUSE พยายามใช้จุดกึ่งกลางในรูปแบบของบริการพิเศษสำหรับการรวบรวมแอปพลิเคชันและการประกอบแพ็คเกจ - openbuildservice.

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

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

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

นอกจากนี้ การสนับสนุนสำหรับการแจกแจงอื่น ๆ เช่น Red Hat มีการใช้งานค่อนข้างแย่ซึ่งเป็นที่เข้าใจได้

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

ในโครงสร้างพื้นฐานของเรา การใช้ OpenBuildService แพคเกจ KMP ที่หลากหลายทั้งหมดของโมดูลเคอร์เนล veamsnap สำหรับการแจกแจง SUSE ได้รับการประกอบขึ้น

ต่อไป ฉันอยากจะพูดถึงปัญหาเฉพาะของโมดูลเคอร์เนล

เคอร์เนล ABI

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

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

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

อย่างไรก็ตาม สถานการณ์นี้ไม่เหมาะกับกลุ่มองค์กรเป็นพิเศษ ผู้จัดจำหน่ายรหัสที่เป็นกรรมสิทธิ์ต้องการแจกจ่ายผลิตภัณฑ์ในรูปแบบไบนารีที่คอมไพล์แล้ว

ผู้ดูแลระบบไม่ต้องการเก็บเครื่องมือการพัฒนาไว้บนเซิร์ฟเวอร์ที่ใช้งานจริงด้วยเหตุผลด้านความปลอดภัย ผู้จัดจำหน่าย Enterprise Linux เช่น Red Hat และ SUSE ตัดสินใจว่าจะสามารถรองรับ kABI ที่เสถียรสำหรับผู้ใช้ของตนได้ ผลลัพธ์คือแพ็คเกจ KMOD สำหรับ Red Hat และแพ็คเกจ KMP สำหรับ SUSE

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

Red Hat อ้างสิทธิ์ความเข้ากันได้ของ kABI สำหรับการเผยแพร่ตลอดวงจรชีวิตทั้งหมด นั่นคือโมดูลที่ประกอบขึ้นสำหรับ rhel 6.0 (เผยแพร่เดือนพฤศจิกายน 2010) ควรทำงานกับเวอร์ชัน 6.10 (เผยแพร่เดือนมิถุนายน 2018) ด้วย และนี่ก็เกือบ 8 ปีแล้ว แน่นอนว่างานนี้ค่อนข้างยาก
เราได้บันทึกหลายกรณีที่โมดูล veemsnap หยุดทำงานเนื่องจากปัญหาความเข้ากันได้ของ kABI

หลังจากที่โมดูล veeamsnap ที่คอมไพล์สำหรับ RHEL 7.0 กลับกลายเป็นว่าเข้ากันไม่ได้กับเคอร์เนลจาก RHEL 7.5 แต่โหลดและรับประกันว่าเซิร์ฟเวอร์จะขัดข้อง เราจึงละทิ้งการใช้ความเข้ากันได้ของ kABI สำหรับ RHEL 7 โดยสิ้นเชิง

ปัจจุบัน แพ็คเกจ KMOD สำหรับ RHEL 7 มีแอสเซมบลีสำหรับแต่ละเวอร์ชันรีลีสและสคริปต์ที่โหลดโมดูล

SUSE เข้าใกล้งานความเข้ากันได้ของ kABI อย่างระมัดระวังมากขึ้น โดยให้ความเข้ากันได้ของ kABI ภายใน Service Pack เดียวเท่านั้น

ตัวอย่างเช่นการเปิดตัว SLES 12 เกิดขึ้นในเดือนกันยายน 2014 และ SLES 12 SP1 ก็มีอยู่แล้วในเดือนธันวาคม 2015 นั่นคือผ่านไปมากกว่าหนึ่งปีเล็กน้อย แม้ว่าทั้งสองรุ่นจะใช้เคอร์เนล 3.12 แต่ kABI ก็เข้ากันไม่ได้ แน่นอนว่าการรักษาความเข้ากันได้ของ kABI ไว้เพียงหนึ่งปีนั้นง่ายกว่ามาก รอบการอัปเดตโมดูลเคอร์เนลประจำปีไม่ควรทำให้เกิดปัญหากับผู้สร้างโมดูล

จากนโยบาย SUSE นี้ เราจึงไม่ได้บันทึกปัญหาใด ๆ เกี่ยวกับความเข้ากันได้ของ kABI ในโมดูล veamsnap ของเรา จริงอยู่ จำนวนแพ็คเกจสำหรับ SUSE นั้นเกือบจะมากกว่าลำดับความสำคัญ

แพตช์และแบ็คพอร์ต

แม้ว่าผู้จัดจำหน่ายจะพยายามรับรองความเข้ากันได้ของ kABI และความเสถียรของเคอร์เนล แต่พวกเขายังพยายามปรับปรุงประสิทธิภาพและกำจัดข้อบกพร่องของเคอร์เนลที่เสถียรนี้

ในเวลาเดียวกันนอกเหนือจาก "การทำงานกับข้อผิดพลาด" ของพวกเขาเองแล้วนักพัฒนาของการตรวจสอบเคอร์เนล Linux ระดับองค์กรยังเปลี่ยนแปลงเคอร์เนลวานิลลาและโอนไปยังเคอร์เนลที่ "เสถียร"

บางครั้งสิ่งนี้นำไปสู่สิ่งใหม่ ข้อผิดพลาด.

ใน Red Hat 6 รุ่นล่าสุด มีข้อผิดพลาดเกิดขึ้นในการอัปเดตเล็กน้อยข้อใดข้อหนึ่ง มันนำไปสู่ความจริงที่ว่าโมดูล veamsnap รับประกันว่าระบบจะขัดข้องเมื่อมีการเผยแพร่สแน็ปช็อต เมื่อเปรียบเทียบแหล่งที่มาของเคอร์เนลก่อนและหลังการอัปเดต เราพบว่าแบ็คพอร์ตต้องตำหนิ มีการแก้ไขที่คล้ายกันใน vanilla kernel เวอร์ชัน 4.19 เพียงว่าการแก้ไขนี้ทำงานได้ดีในเคอร์เนลวานิลลา แต่เมื่อถ่ายโอนไปยัง "เสถียร" 2.6.32 ปัญหาก็เกิดขึ้นกับสปินล็อค

แน่นอนว่าทุกคนย่อมมีข้อผิดพลาดอยู่เสมอ แต่จะคุ้มไหมที่จะลากโค้ดจาก 4.19 ไปเป็น 2.6.32 ซึ่งเสี่ยงต่อความเสถียร?.. ฉันไม่แน่ใจ...

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

เมื่อฉันพยายามสร้างโมดูลบนเคอร์เนล 4.4 จาก SLES 12 SP3 ฉันรู้สึกประหลาดใจที่พบฟังก์ชันการทำงานจาก vanilla 4.8 ในนั้น ในความคิดของฉัน การใช้บล็อก I/O ของเคอร์เนล 4.4 จาก SLES 12 SP3 นั้นคล้ายคลึงกับเคอร์เนล 4.8 มากกว่าเคอร์เนล 4.4 ที่เสถียรรุ่นก่อนหน้าจาก SLES12 SP2 ฉันไม่สามารถตัดสินได้ว่าเปอร์เซ็นต์ของโค้ดถูกถ่ายโอนจากเคอร์เนล 4.8 ไปยัง SLES 4.4 สำหรับ SP3 แต่ฉันไม่สามารถเรียกเคอร์เนลว่าเป็น 4.4 ที่เสถียรแบบเดียวกันได้

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

เป็นผลให้โค้ดมีคำสั่งการคอมไพล์แบบมีเงื่อนไขแปลกๆ มากเกินไป

นอกจากนี้ยังมีโปรแกรมแก้ไขที่เปลี่ยนแปลง API เคอร์เนลที่จัดทำเอกสารไว้
เจอกระจายครับ KDE นีออน 5.16 และรู้สึกประหลาดใจมากที่เห็นว่าการเรียก lookup_bdev ในเวอร์ชันเคอร์เนลนี้เปลี่ยนรายการพารามิเตอร์อินพุต

ในการรวมเข้าด้วยกัน ฉันต้องเพิ่มสคริปต์ลงใน makefile ที่ตรวจสอบว่าฟังก์ชัน lookup_bdev มีพารามิเตอร์ mask หรือไม่

การลงนามโมดูลเคอร์เนล

แต่กลับเข้าสู่ประเด็นการกระจายบรรจุภัณฑ์กันดีกว่า

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

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

ปัญหาที่นี่คือสามารถสร้างใบรับรองในเคอร์เนล (ผู้จัดจำหน่ายใช้) หรือต้องเขียนลงในหน่วยความจำแบบไม่ลบเลือนของ EFI โดยใช้ยูทิลิตี้ โมกุติล. คุณประโยชน์ โมกุติล เมื่อติดตั้งใบรับรอง คุณจะต้องรีบูทระบบ และแม้กระทั่งก่อนที่จะโหลดเคอร์เนลระบบปฏิบัติการ ผู้ดูแลระบบจะแจ้งให้โหลดใบรับรองใหม่

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

EFI บนเครื่องเสมือน

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

ไฮเปอร์ไวเซอร์บางตัวไม่รองรับ EFI VMWare vSphere รองรับ EFI ตั้งแต่เวอร์ชัน 5 เป็นต้นไป
Microsoft Hyper-V ยังได้รับการสนับสนุน EFI โดยเริ่มจาก Hyper-V สำหรับ Windows Server 2012R2

อย่างไรก็ตาม ในการกำหนดค่าเริ่มต้น ฟังก์ชันนี้จะถูกปิดใช้งานสำหรับเครื่อง Linux ซึ่งหมายความว่าไม่สามารถติดตั้งใบรับรองได้

ใน vSphere 6.5 ให้ตั้งค่าตัวเลือก Boot การรักษาความปลอดภัย เป็นไปได้เฉพาะในเว็บอินเตอร์เฟสเวอร์ชันเก่าซึ่งทำงานผ่าน Flash Web UI บน HTML-5 ยังตามหลังอยู่มาก

การแจกแจงแบบทดลอง

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

อย่างไรก็ตาม การแจกแจงดังกล่าวกลายเป็นช่องทางที่สะดวกสำหรับการทดลองใช้วิธีแก้ปัญหาเชิงทดลองใหม่ๆ ตัวอย่างเช่น Fedora, OpenSUSE Tumbleweed หรือ Debian เวอร์ชันที่ไม่เสถียร พวกเขาค่อนข้างมีเสถียรภาพ พวกเขามีโปรแกรมเวอร์ชันใหม่อยู่เสมอและมีเคอร์เนลใหม่อยู่เสมอ ในหนึ่งปี ฟังก์ชันการทดลองนี้อาจไปอยู่ใน RHEL, SLES หรือ Ubuntu ที่อัปเดตแล้ว

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

คุณสามารถศึกษารายการการแจกแจงที่รองรับอย่างเป็นทางการในปัจจุบันสำหรับเวอร์ชัน 3.0 ที่นี่. แต่รายการการจัดจำหน่ายที่แท้จริงซึ่งผลิตภัณฑ์ของเราสามารถใช้ได้นั้นกว้างกว่ามาก

โดยส่วนตัวแล้วฉันสนใจการทดลองกับ Elbrus OS หลังจากเสร็จสิ้นแพ็คเกจ veeam ผลิตภัณฑ์ของเราก็ได้รับการติดตั้งและใช้งานได้ ฉันเขียนเกี่ยวกับการทดลองนี้กับHabré in статье.

การสนับสนุนสำหรับการแจกแจงใหม่ยังคงดำเนินต่อไป เรากำลังรอเวอร์ชัน 4.0 ที่จะเปิดตัว เบต้ากำลังจะปรากฏตัว ดังนั้นโปรดจับตาดูให้ดี มีอะไรใหม่!

ที่มา: will.com