วิธีติดตั้ง EPEL และ CRB บน Rocky Linux และ AlmaLinux

เหตุใด dnf จึงหาแพ็กเกจที่คุณต้องการไม่พบ

EPEL และ CRB เป็น repository สองแห่งที่เซิร์ฟเวอร์ Rocky Linux หรือ AlmaLinux ที่ติดตั้งใหม่ไม่ได้เปิดใช้งานมาให้แต่แรก ซึ่งเป็นสาเหตุที่ทำให้ dnf install htop บนเครื่องใหม่ตอบกลับมาด้วย No match for argument: htop และตามด้วย Error: Unable to find a match: htop ระบบไม่ได้เสียหายและไม่มี mirror ใดล่ม การแจกจ่ายซอฟต์แวร์พื้นฐานตั้งใจให้มีชุดแพ็กเกจขนาดเล็กมาให้แต่แรก ส่วน CRB นั้นมีอยู่จริงแต่ถูกปิดไว้ และ EPEL เป็น repository ของชุมชนแยกต่างหากที่คุณต้องเพิ่มเข้าไปเอง

บน Ubuntu แพ็กเกจเดียวกันจะอยู่ใน universe และ universe ก็ถูกเปิดใช้งานไว้ในเกือบทุก cloud image คำถามนี้จึงไม่เคยเกิดขึ้น ในขณะที่ตระกูล Red Hat มีการแบ่งแพ็กเกจที่แตกต่างออกไปและตั้งค่าเริ่มต้นมาให้ค่อนข้างน้อย วิธีแก้ไขมีเพียง 3 คำสั่ง ส่วนที่เหลือของคู่มือนี้คือสิ่งที่ไม่มีใครบอกคุณในช่วงสัปดาห์แรก: สิ่งที่ repository เหล่านี้รับประกัน สิ่งที่ไม่ได้ให้คำมั่นสัญญา และวิธีป้องกันไม่ให้ repository ของบุคคลที่สามเข้ามาควบคุมระบบพื้นฐานของคุณอย่างเงียบๆ

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

BaseOS, AppStream และ CRB คืออะไร

BaseOS คือตัวระบบปฏิบัติการเอง ประกอบด้วย kernel, glibc, systemd และ userland หลัก เวอร์ชันของซอฟต์แวร์ในส่วนนี้จะถูกแช่แข็งไว้ตลอดอายุการใช้งานของ major release โดยจะมีการ backport แพตช์ความปลอดภัยเข้ามาในเวอร์ชันที่แช่แข็งเหล่านั้น ดังนั้นเลขเวอร์ชันที่ดูเก่าใน BaseOS ไม่ได้หมายความว่าเป็นแพ็กเกจที่ไม่ได้อัปเดต แต่เป็นเวอร์ชันเก่าที่ผ่านการแพตช์แล้ว ซึ่งเป็นหัวใจสำคัญของการแจกจ่ายซอฟต์แวร์ระดับองค์กร

AppStream เก็บสิ่งที่ทำงานอยู่บนระบบ เช่น เว็บเซิร์ฟเวอร์, ฐานข้อมูล, language runtime, โปรแกรมแก้ไขข้อความ และ monitoring agent ในเวอร์ชัน 8 ซอฟต์แวร์ส่วนใหญ่ใน AppStream ถูกส่งมอบในรูปแบบโมดูลที่มี stream ให้เลือกหลากหลาย ทำให้ dnf module list มีความสำคัญและคุณต้องเลือก เช่น เลือก PHP stream ใด stream หนึ่ง แต่ในเวอร์ชัน 9 ได้ยกเลิกความเป็นโมดูลเกือบทั้งหมด ดังนั้นบน Rocky 9 และ Alma 9 คุณมักจะได้ซอฟต์แวร์เวอร์ชันเดียวโดยไม่ต้องเปิดใช้งานโมดูลก่อน

Extras ถูกเปิดใช้งานโดยค่าเริ่มต้นและมีขนาดเล็กมาก ส่วนใหญ่เก็บแพ็กเกจสำหรับ release ของ repository อื่นๆ ซึ่งเป็นที่มาของ epel-release รายละเอียดนี้คือเหตุผลที่คุณไม่จำเป็นต้องเชื่อถือ URL สุ่มเพื่อติดตั้ง EPEL บน Rocky หรือ Alma

CRB คือ repository ของ CodeReady Builder ซึ่งในเวอร์ชัน 8 เรียกว่า PowerTools มันเก็บส่วนประกอบสำหรับการ build ของระบบ เช่น development headers, static libraries รวมถึงเครื่องมือทดสอบและเอกสารที่แพ็กเกจจำเป็นต้องใช้ในระหว่างการ build มันถูกติดตั้งอยู่บน mirror แล้วแต่จะถูกปิดใช้งานไว้โดยค่าเริ่มต้น ในผลิตภัณฑ์ของ Red Hat เอง เนื้อหาเดียวกันนี้เรียกว่า CodeReady Linux Builder ซึ่งมาพร้อมกับการสมัครสมาชิก โดย Red Hat ระบุว่าเนื้อหาส่วนนี้ไม่ครอบคลุมอยู่ในการสนับสนุน ซึ่ง Rocky และ Alma ได้รับสืบทอดทั้งเนื้อหาและการตั้งค่าปิดใช้งานโดยค่าเริ่มต้นนี้มาด้วย

สำหรับผู้อ่านที่มาจาก Debian หรือ Ubuntu: main จะรวมแพ็กเกจสำหรับรันไทม์และ -dev headers ไว้ในที่เก็บเดียวกัน ดังนั้นจึงไม่มี CRB ให้ต้องเปิดใช้งาน สิ่งที่ใกล้เคียงกับ EPEL มากที่สุดคือ universe ซึ่งดูแลโดยชุมชนและไม่มีการรับประกันการสนับสนุนจากผู้จำหน่าย

EPEL คืออะไรและใครเป็นผู้ดูแล

EPEL ย่อมาจาก Extra Packages for Enterprise Linux เป็นโครงการของ Fedora โดยเป็นการนำแพ็กเกจที่มีอยู่ใน Fedora มาสร้างใหม่ (rebuild) สำหรับรุ่น Enterprise ในปัจจุบัน ดูแลโดยกลุ่ม EPEL Special Interest Group ซึ่งส่วนใหญ่เป็นอาสาสมัครจากชุมชน Fedora ทาง Red Hat เป็นผู้สนับสนุนโครงสร้างพื้นฐานในการ build และ mirror รวมถึงมีวิศวกรของ Red Hat บางส่วนช่วยดูแลแพ็กเกจในโครงการ ความสัมพันธ์มีเพียงเท่านี้ EPEL ไม่ใช่ผลิตภัณฑ์ของ Red Hat จึงไม่มีสัญญาการสนับสนุนและไม่มี SLA (Service Level Agreement) สำหรับแพ็กเกจ EPEL ไม่ว่าจะใช้งานบน RHEL หรือบนระบบที่สร้างใหม่ (rebuild)

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

ระยะเวลาการสนับสนุนนั้นแตกต่างจาก distribution หลัก ซึ่งเป็นจุดที่มักสร้างปัญหาในปีที่ 3 แพ็กเกจใน BaseOS จะถูกแช่เวอร์ชันไว้ตลอดอายุการใช้งาน 10 ปีของรุ่นหลัก แต่ผู้ดูแล EPEL ให้คำมั่นสัญญาในช่วงเวลาที่สั้นกว่ามาก คืออย่างน้อยหนึ่งรุ่นย่อย (minor release) ของ RHEL หรือ 13 เดือน แล้วแต่ระยะเวลาใดจะสั้นกว่า ในทางปฏิบัติแพ็กเกจส่วนใหญ่ได้รับการดูแลนานกว่านั้นมาก บางแพ็กเกจถูกยกเลิกเมื่อผู้ดูแลเปลี่ยนไป และบางแพ็กเกจอาจข้ามไปยังเวอร์ชันหลักใหม่ในระหว่างที่ distro ของคุณยังใช้งานอยู่ เนื่องจาก EPEL อ้างอิงตาม Fedora ดังนั้นการทำ dnf upgrade ตามปกติอาจทำให้คุณได้รับเครื่องมือเวอร์ชันหลักใหม่บนเครื่องที่คุณคิดว่ามีความเสถียร และแพ็กเกจที่คุณใช้งานอยู่อาจหยุดการอัปเดตโดยไม่มีการแจ้งเตือนใดๆ ถึงคุณ นอกจากนี้เวอร์ชันใหม่จะไม่มีผลกับบริการที่กำลังทำงานอยู่ ดังนั้น needs-restarting คือเครื่องมือที่จะบอกคุณว่ามี process ใดบ้างที่ยังคงใช้ binary เวอร์ชันเก่าอยู่หลังจากที่การทำรายการเสร็จสิ้น

อีกหนึ่งผลกระทบที่ควรทราบก่อนเปิดใช้งานคือ EPEL ถูกสร้างขึ้นโดยอ้างอิงกับ RHEL รุ่นย่อยล่าสุด หากคุณคงเซิร์ฟเวอร์ไว้ที่รุ่นย่อยเก่าโดยใช้ mirror แบบแช่เวอร์ชันหรือ repository ของผู้จำหน่าย แพ็กเกจ EPEL อาจต้องการ library พื้นฐานที่ใหม่กว่าที่คุณมี dnf จะรายงานว่าเป็น dependency ที่ขาดหายไป ซึ่งดูเหมือนปัญหาจาก mirror ทั้งที่จริงแล้วเป็นปัญหาความเหลื่อมล้ำของเวอร์ชัน (version skew)

การเปิดใช้งาน CRB และติดตั้ง EPEL บน Rocky หรือ Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled ควรแสดงรายการ baseos, appstream, extras, crb และ epel ในขณะนี้ คุณอาจเห็นรายการ epel-cisco-openh264 ขนาดเล็กซึ่ง epel-release เป็นผู้เพิ่มเข้ามา หาก crb หายไปจากรายการดังกล่าว แสดงว่าขั้นตอนการเปิดใช้งานไม่สำเร็จ ซึ่งส่วนถัดไปจะอธิบายถึงสาเหตุ

บน Rocky 8 และ Alma 8 คลังซอฟต์แวร์ยังคงใช้ชื่อว่า PowerTools ดังนั้นคำสั่งตรงกลางจึงเปลี่ยนเป็น sudo dnf config-manager --set-enabled powertools รหัสของคลังซอฟต์แวร์มีความสำคัญที่ตัวอักษรพิมพ์เล็กและพิมพ์ใหญ่ เอกสารเก่าของ CentOS 8 มักสะกดว่า PowerTools โดยใช้ตัวพิมพ์ใหญ่ ซึ่งจะไม่ตรงกับค่าที่ระบบต้องการ สำหรับ AlmaLinux 10 คลังซอฟต์แวร์ CRB จะถูกเปิดใช้งานโดยค่าเริ่มต้นตั้งแต่เวอร์ชัน 10.0 เป็นต้นไป (มีการเปลี่ยนแปลงในเดือนกันยายน 2025) ดังนั้นคุณจึงต้องทำเพียงขั้นตอน epel-release เท่านั้น

epel-release มาจาก extras ซึ่งถูกเปิดใช้งานอยู่แล้ว จึงไม่มี URL ที่ต้องเชื่อถือและไม่มีกุญแจที่ต้องนำเข้าด้วยตนเอง แพ็กเกจจะเขียน /etc/yum.repos.d/epel.repo และติดตั้งกุญแจสำหรับลงนามของ EPEL ไว้ที่ /etc/pki/rpm-gpg/ ให้ยืนยันค่า gpgcheck=1 ในไฟล์ดังกล่าว และให้เพิกเฉยต่อคำแนะนำใดๆ ที่บอกให้คุณข้ามข้อผิดพลาดเรื่องลายเซ็นด้วย --nogpgcheck การตรวจสอบลายเซ็นที่ล้มเหลวหมายความว่าแพ็กเกจนั้นไม่ใช่สิ่งที่อ้างว่าเป็น หรือนาฬิกาในระบบของคุณไม่ถูกต้อง

บน Rocky นั้น epel-release จะติดตั้งตัวช่วยขนาดเล็กไว้ที่ /usr/bin/crb ด้วย ดังนั้น sudo crb enable และ crb status จึงทำหน้าที่เดียวกันโดยไม่ต้องใช้ปลั๊กอิน ให้ตรวจสอบว่าคุณมีเครื่องมือนี้หรือไม่ด้วย command -v crb ก่อนที่จะใช้งาน เนื่องจากเครื่องมือนี้ไม่ได้มีอยู่ในทุกสาขาของทุกการแจกจ่ายแบบ rebuild

เพื่อพิสูจน์ว่า EPEL สามารถเข้าถึงได้จริง ไม่ใช่แค่มีชื่ออยู่ในรายการ ให้ลองเรียกหาแพ็กเกจที่มีเฉพาะในคลังนี้เท่านั้น:

dnf repoquery --repo=epel htop

คำสั่งนี้จะแสดงชื่อแพ็กเกจ เวอร์ชัน และสถาปัตยกรรม หากไม่มีการตอบสนองใดๆ แสดงว่าคลังซอฟต์แวร์ถูกเปิดใช้งานแล้วแต่ไม่ส่งข้อมูลกลับ ซึ่งมักเป็นปัญหาที่ตัว mirror หรือ metadata ไม่ใช่ปัญหาที่การตั้งค่า ดังนั้นให้ลองใช้ sudo dnf clean all && sudo dnf makecache ในลำดับถัดไป

เหตุใด dnf จึงแจ้งว่าไม่มีคำสั่ง config-manager

นี่เป็นปัญหาแรกที่ผู้ใช้มักพบ และมักเกิดขึ้นกับอิมเมจระบบปฏิบัติการที่ผู้ให้บริการ VPS ส่วนใหญ่จัดเตรียมไว้ให้

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager เป็นปลั๊กอิน ไม่ใช่คำสั่งย่อยที่มีมาในตัวของ dnf โดยจะมาพร้อมกับแพ็กเกจ dnf-plugins-core ซึ่งการติดตั้งเซิร์ฟเวอร์แบบเต็มรูปแบบจะดึงแพ็กเกจนี้มาด้วย แต่การติดตั้งแบบ minimal, cloud image และ container image จะตัดส่วนนี้ออกไป คำแนะนำของ dnf ทำงานได้เพราะแพ็กเกจได้ประกาศความสามารถเสมือน (virtual capability) นั้นไว้แล้ว:

sudo dnf install -y 'dnf-command(config-manager)'

ให้ใส่เครื่องหมายคำพูดครอบคำสั่ง เนื่องจากวงเล็บเป็นไวยากรณ์ของ shell หากไม่ใส่เครื่องหมายคำพูดจะทำให้เกิดข้อผิดพลาดทางไวยากรณ์แทนที่จะเป็นข้อผิดพลาดจาก dnf

หากคุณไม่สามารถติดตั้งปลั๊กอินได้เนื่องจาก repository ที่คุณต้องการถูกปิดใช้งานอยู่ ให้แก้ไขไฟล์แทน โดยค้นหาว่าไฟล์ใดเก็บส่วนการตั้งค่าดังกล่าวไว้ จากนั้นเปิดไฟล์และตั้งค่า enabled=1 ภายใต้ส่วน [crb]:

grep -rl crb /etc/yum.repos.d/

นี่คือสิ่งที่ config-manager เขียนลงไป ดังนั้นการทำด้วยตนเองจึงให้ผลลัพธ์ที่ไม่แตกต่างกัน โดยสามารถใช้ dnf repolist --enabled เพื่อตรวจสอบผลลัพธ์ได้

แพ็กเกจ EPEL บางรายการจะไม่ติดตั้งจนกว่าจะเปิดใช้งาน CRB

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

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

สาเหตุเกิดจาก CRB ถูกปิดใช้งาน ทำให้ dnf ไม่สามารถมองเห็น repository เพียงแห่งเดียวที่มีไลบรารีดังกล่าว ให้ตรวจสอบสองสิ่งนี้ตามลำดับ:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

หากคำสั่งที่สองระบุชื่อแพ็กเกจในขณะที่การติดตั้งปกติยังคงล้มเหลว แสดงว่า CRB ถูกปิดอยู่ ข้อผิดพลาดประเภทนี้พบได้บ่อยจน AlmaLinux ตัดสินใจเปิดใช้งาน CRB เป็นค่าเริ่มต้นในเวอร์ชัน 10 เพื่อป้องกันไม่ให้ปัญหานี้เกิดขึ้น --enablerepo=crb สามารถใช้เป็น flag สำหรับการติดตั้งแบบครั้งเดียวได้เช่นกัน แต่หากคุณใช้งาน EPEL ควรเปิดใช้งาน CRB ทิ้งไว้ถาวร เนื่องจากการอัปเดต EPEL ในครั้งถัดไปอาจดึง dependency ใหม่จาก CRB เข้ามาโดยที่คุณไม่ได้รับคำเตือนล่วงหน้า

แพ็กเกจนี้มาจาก repository ใด

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

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

dnf info บนแพ็กเกจที่ติดตั้งแล้วจะแสดงบรรทัด From repo ออกมา dnf list installed จะแสดงข้อมูลเดียวกันในคอลัมน์ที่สามโดยมี @ นำหน้า ดังนั้น @epel หมายความว่าติดตั้งมาจาก EPEL และ @System หมายความว่า dnf ไม่ทราบแหล่งที่มา ซึ่งมักเกิดจากการที่มีคนรัน rpm -i บนไฟล์ที่ดาวน์โหลดมา บรรทัด repoquery จะแสดงจำนวนแพ็กเกจแยกตาม repository ซึ่งเป็นวิธีที่เร็วที่สุดในการตรวจสอบว่าเซิร์ฟเวอร์ที่คุณรับช่วงมามีแพ็กเกจสี่สิบรายการจาก repository ที่คุณไม่เคยรู้จักมาก่อน คำสั่งสุดท้ายจะแสดงรายการสิ่งที่ repository หนึ่งมอบให้คุณอย่างละเอียด และรายการสินค้าคงคลังนั้นคือสิ่งที่คุณจำเป็นต้องมีก่อนตัดสินใจลบ repository ดังกล่าวออก

นิสัยการใช้งาน apt ในกรณีนี้คือ apt-cache policy <package> และ คำสั่งที่เทียบเท่ากันระหว่าง dnf และ apt เป็นสิ่งที่ควรเปิดค้างไว้ในแท็บที่สองตลอดเดือนแรก เพราะแนวคิดต่างๆ นั้นสอดคล้องกันอย่างชัดเจนแม้ว่า flag จะไม่เหมือนกันก็ตาม

ฉันจะป้องกันไม่ให้ repository ของบุคคลที่สามเข้ามาแทนที่แพ็กเกจพื้นฐานได้อย่างไร?

EPEL ให้คำมั่นว่าจะไม่ทำเช่นนี้ แต่ repository อื่นไม่ได้ทำตาม ผู้ให้บริการซอฟต์แวร์สำหรับฐานข้อมูล, เอเจนต์ หรือรันไทม์ของภาษาโปรแกรม อาจจัดส่งไลบรารีในเวอร์ชันของตนเองซึ่งมีอยู่ใน BaseOS ด้วย และ dnf จะติดตั้งแพ็กเกจเหล่านั้นให้ เนื่องจากกฎพื้นฐานของ dnf นั้นเรียบง่าย: เวอร์ชันที่สูงกว่าจะเป็นฝ่ายชนะ ไม่ว่าจะมาจากแหล่งใดก็ตาม

การควบคุมสองประการสามารถจัดการงานส่วนใหญ่ได้ และทั้งสองอย่างนี้อยู่ในไฟล์ repository ภายใต้ /etc/yum.repos.d/

priority= เป็นตัวตัดสินว่า repository ใดจะเป็นฝ่ายชนะเมื่อมีมากกว่าหนึ่งแห่งที่มีแพ็กเกจชื่อเดียวกัน ตัวเลขที่ต่ำกว่าจะเป็นฝ่ายชนะและค่าเริ่มต้นคือ 99 ดังนั้นให้กำหนดตัวเลขที่ต่ำให้กับ repository พื้นฐานของคุณ และกำหนดตัวเลขที่สูงให้กับ repository ของบุคคลที่สาม จากนั้น dnf จะเลือกแพ็กเกจพื้นฐานแม้ว่าเวอร์ชันของบุคคลที่สามจะใหม่กว่าก็ตาม dnf รุ่นใหม่สามารถจัดการเรื่องนี้ได้ด้วยตัวเอง ดังนั้นแพ็กเกจ yum-plugin-priorities แบบแยกส่วนในยุค CentOS 7 จึงไม่ใช่คำตอบสำหรับปัญหานี้อีกต่อไป

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

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

ในเวอร์ชัน 8 มีการตั้งค่าอีกหนึ่งอย่างที่ควรทราบ แพ็กเกจจาก repository ของบุคคลที่สามอาจถูกซ่อนไว้เมื่อ AppStream module มีชื่อเดียวกัน และ module_hotfixes=1 ในส่วนของ repository นั้นจะบอกให้ dnf หยุดการกรองแพ็กเกจดังกล่าว หากแพ็กเกจมองเห็นได้ด้วย dnf repoquery แต่ไม่สามารถติดตั้งบนเครื่องเวอร์ชัน 8 ได้ นั่นมักจะเป็นสาเหตุของปัญหา เวอร์ชัน 9 ได้ยกเลิกการใช้ module เกือบทั้งหมดแล้ว ดังนั้นปัญหานี้จึงแทบไม่เกิดขึ้นในเวอร์ชันดังกล่าว

หากต้องการล็อกแพ็กเกจไว้ที่เวอร์ชันใดเวอร์ชันหนึ่ง ให้ติดตั้ง python3-dnf-plugin-versionlock และใช้ sudo dnf versionlock add <package> ซึ่งเทียบเท่ากับ apt-mark hold โปรดสังเกตความแตกต่างที่มักทำให้ผู้ที่ย้ายมาจาก Debian สับสน: ใน apt ค่า Pin-Priority ที่สูงกว่าจะเป็นฝ่ายชนะ แต่ใน dnf ค่า priority ที่ต่ำกว่าจะเป็นฝ่ายชนะ

เหตุผลที่การผสม repository ของ RHEL ที่ใกล้เคียงกันทำให้เซิร์ฟเวอร์อัปเกรดไม่ได้

Rocky, Alma, CentOS Stream, Oracle Linux และ RHEL มีความใกล้เคียงกันมากจนสามารถติดตั้งแพ็กเกจข้ามกันได้ แต่ก็มีความแตกต่างกันมากพอที่จะทำให้ผลลัพธ์ที่ได้กลายเป็นระบบที่ไม่มีใครสามารถสนับสนุนได้ เหตุผลที่ระบบเหล่านี้ใกล้เคียงกัน และเหตุผลที่ CentOS Stream ในปัจจุบันวางตำแหน่งอยู่หน้า RHEL แทนที่จะอยู่เคียงข้างกันนั้น คือ เรื่องราวของการที่ Red Hat Linux แยกตัวออกเป็น Fedora และ RHEL รวมถึงสิ่งที่เกิดขึ้นกับ CentOS

กลไกที่เป็นปัญหาคือหมายเลขเวอร์ชัน CentOS Stream 9 ทำงานล้ำหน้ากว่า RHEL 9 ดังนั้นการชี้เซิร์ฟเวอร์ Rocky 9 ไปยัง repository ของ CentOS Stream แม้เพียงครั้งเดียว หรือแม้แต่เพียงแพ็กเกจเดียว จะทำให้คุณได้แพ็กเกจที่มีเวอร์ชันสูงกว่าสิ่งที่ Rocky จะปล่อยออกมาในอนาคต เมื่อมีการปล่อย minor release ถัดไปของ Rocky เวอร์ชันของแพ็กเกจเหล่านั้นใน repository จะต่ำกว่าเวอร์ชันที่คุณมีอยู่ ส่งผลให้ dnf upgrade ไม่ยอมดำเนินการใดๆ กับแพ็กเกจดังกล่าว เครื่องของคุณจึงรันด้วยชุดซอฟต์แวร์ที่ไม่มีใครเคยทดสอบ และสถานะนี้จะคงอยู่ไปอีกหลายปีในขณะที่คุณเข้าใจผิดว่าระบบได้รับการแพตช์อยู่ตลอดเวลา

อาการที่พบคือ dnf upgrade รายงานว่าไม่มีงานต้องทำ ในขณะที่ sudo dnf distro-sync เสนอให้ดาวน์เกรดแพ็กเกจจำนวนมาก distro-sync คือเครื่องมือสำหรับแก้ไขปัญหานี้ โดยจะบังคับให้แพ็กเกจที่ติดตั้งอยู่ทั้งหมดตรงกับสิ่งที่ repository ที่เปิดใช้งานอยู่นำเสนอ รวมถึงการดาวน์เกรดด้วย ให้ปิดการใช้งาน repository ภายนอกก่อน จากนั้นจึงรันคำสั่ง แล้วตรวจสอบรายการที่ระบบเสนอให้ทำก่อนที่จะตอบตกลง การซ่อมแซมจะล้มเหลวหาก RPM เวอร์ชันเก่าไม่มีอยู่บน mirror แล้ว และในจุดนั้น การสร้างเซิร์ฟเวอร์ใหม่จาก image ที่สะอาดจะรวดเร็วและปลอดภัยกว่าการพยายามแก้ไขปัญหา dependency solver

สิ่งที่หลงเหลือจากยุค ELevate เป็นอีกรูปแบบหนึ่งของปัญหานี้ ELevate คือเครื่องมือย้ายระบบของ AlmaLinux ที่สร้างบน Leapp ซึ่งใช้สำหรับย้ายเซิร์ฟเวอร์ CentOS 7 ไปยังเวอร์ชันใหม่หรือแปลงระหว่างการ rebuild การย้ายระบบที่เร่งรีบจะทิ้งไฟล์ repository ของ EL7 ไว้ใน /etc/yum.repos.d/ และยังมีแพ็กเกจ EL7 ติดตั้งค้างอยู่ ให้ค้นหาแพ็กเกจเหล่านี้ด้วย rpm -qa | grep el7 แพ็กเกจแต่ละตัวคือสิ่งที่ไม่มี repository ที่เปิดใช้งานอยู่ใดสามารถอัปเดตได้ และการรัน Leapp ในภายหลังจะรายงานว่าแพ็กเกจเหล่านี้ไม่สามารถแมปได้ ซึ่งจะกลายเป็นตัวขัดขวางการอัปเกรดที่คุณต้องแก้ไขด้วยตนเอง ให้จัดการลบออกในขณะที่เซิร์ฟเวอร์ยังทำงานปกติ ไม่ใช่ในวันที่คุณจำเป็นต้องทำการอัปเกรดครั้งใหญ่

การที่ repository ของผู้จำหน่ายซอฟต์แวร์ (vendor repository) ทับซ้อนกับแพ็กเกจใน AppStream เป็นรูปแบบที่ไม่รุนแรงของปัญหาเดียวกัน และบรรทัด includepkgs ด้านบนคือวิธีแก้ไข เครื่องมือสำหรับจัดการ container มักเป็นกรณีที่พบบ่อยที่สุด เนื่องจาก containerd.io จาก repository ของ Docker เองเกิดความขัดแย้งกับ runc จาก AppStream ดังนั้นคุณต้องเลือกเอาอย่างใดอย่างหนึ่ง ตัดสินใจให้เด็ดขาด บันทึกการตั้งค่า exclusion ไว้ และปฏิบัติตามลำดับขั้นตอนที่ถูกต้อง โดย คู่มือการติดตั้ง Docker บน Rocky Linux ได้ระบุไว้ว่าควรลบแพ็กเกจใดของ distribution ออกก่อน

การเปลี่ยนจาก apt เป็น dnf สำหรับ repository

• /etc/apt/sources.list.d/*.sources เปลี่ยนเป็น /etc/yum.repos.d/*.repo โดยที่ไฟล์เดียวสามารถเก็บ [sections] ได้หลายรายการ ซึ่งแต่ละรายการจะมี id ของตัวเอง
• add-apt-repository universe เปลี่ยนเป็น dnf install epel-release โดยมีความแตกต่างคือ universe ยังคงอยู่ในคลังซอฟต์แวร์ของ Ubuntu เอง ในขณะที่ EPEL เป็นโครงการแยกต่างหาก
• apt update ไม่มีคำสั่งเทียบเท่าที่คุณต้องจำ dnf จะรีเฟรช metadata ตามกำหนดเวลาของมันเอง และ dnf makecache จะเป็นการบังคับให้รีเฟรชทันที
• apt-cache policy <pkg> เปลี่ยนเป็น dnf info <pkg> และใช้ dnf list --showduplicates <pkg> เพื่อดูทุกเวอร์ชันที่มีให้เลือก
• apt-mark hold เปลี่ยนเป็น dnf versionlock add จาก python3-dnf-plugin-versionlock
• การทำ Pinning ใน /etc/apt/preferences.d/ จะเปลี่ยนเป็น priority= ในส่วนของ repository โดยที่ตัวเลขจะทำงานในทิศทางตรงกันข้าม
• dpkg -S /path/to/file เปลี่ยนเป็น rpm -qf /path/to/file

การอัปเดตอัตโนมัติเป็นการถ่ายโอนแนวคิดมากกว่าการใช้ไวยากรณ์ เนื่องจากไม่มี unattended-upgrades ในที่นี้ ทั้งตัวตั้งเวลา (timer), ไฟล์คอนฟิก และคำถามที่ว่าควร reboot หรือไม่ ได้ถูกครอบคลุมไว้ใน dnf-automatic บน Rocky และ Alma

จำกัดรายการ repository ให้สั้นที่สุด

เปิดใช้งาน CRB, ติดตั้ง epel-release จากนั้นให้บันทึกสิ่งที่คุณทำและเหตุผลไว้ ไม่ว่าจะในระบบจัดการ configuration ของคุณหรือในไฟล์ข้อความธรรมดาบนเซิร์ฟเวอร์ บันทึกนี้มีค่ามากกว่าที่คิดเมื่อเซิร์ฟเวอร์ใช้งานมานาน 3 ปีและมีผู้อื่นเข้ามาดูแลต่อ

ค้นหาก่อนที่จะเพิ่ม repository ใหม่ ให้รัน dnf search ตามด้วย dnf info แล้วจึงค่อยพิจารณาเพิ่ม repository ใหม่ สิ่งที่ผู้คนมักเปิดใช้งาน EPEL เพื่อติดตั้งนั้น หลายอย่างมีอยู่ใน AppStream อยู่แล้ว ตัวอย่างที่ชัดเจนที่สุดคือการตรวจสอบประสิทธิภาพของระบบ เนื่องจาก Performance Co-Pilot มีมาให้ใน repository หลัก และไม่จำเป็นต้องใช้ซอฟต์แวร์จากภายนอก ทุก repository ที่เพิ่มเข้ามาคือบุคคลที่สามที่สามารถส่งแพ็กเกจมาให้คุณได้ทุกเมื่อ และแต่ละแห่งจะทำให้การอัปเกรดเวอร์ชันหลักในอนาคตยากขึ้น

หากคุณยังตัดสินใจเลือกระหว่างสอง distribution นี้ โครงสร้างโดยรวมของทั้งคู่เหมือนกัน และ epel-release ก็ทำงานได้เหมือนกัน ความแตกต่างที่แท้จริงอยู่ที่อื่น: การเปรียบเทียบระหว่าง Rocky Linux และ AlmaLinux ครอบคลุมถึงแนวคิดในการสร้างใหม่ (rebuild) เนื่องจากปัจจุบัน AlmaLinux มุ่งเน้นที่ความเข้ากันได้ของ ABI (application binary interface) แทนที่จะเป็นการสร้างใหม่แบบบรรทัดต่อบรรทัด

FAQ

ฉันจะเปิดใช้งาน EPEL บน Rocky Linux 9 หรือ AlmaLinux 9 ได้อย่างไร?

ให้รัน sudo dnf install -y dnf-plugins-core ตามด้วย sudo dnf config-manager --set-enabled crb และ sudo dnf install -y epel-release จากนั้นยืนยันด้วย dnf repolist --enabled ซึ่งควรแสดงรายการ baseos, appstream, extras, crb และ epel คุณต้องเปิดใช้งาน CRB ก่อนติดตั้งแพ็กเกจจาก EPEL เนื่องจากแพ็กเกจจำนวนมากต้องอาศัยไลบรารีที่มีเฉพาะใน CRB เท่านั้น สำหรับเวอร์ชัน 8 รหัสของ repository คือ powertools แทนที่จะเป็น crb

การเปิดใช้งาน EPEL บนเซิร์ฟเวอร์ที่ใช้งานจริงมีความปลอดภัยหรือไม่?

EPEL ถูกใช้งานอย่างแพร่หลายและสร้างขึ้นภายใต้นโยบายที่ว่าแพ็กเกจของ EPEL จะไม่ทับซ้อนกับแพ็กเกจจาก distribution หลัก ดังนั้นการเปิดใช้งานจึงไม่ส่งผลกระทบต่อสิ่งที่ BaseOS หรือ AppStream มอบให้ ข้อควรระวังคือเรื่องการสนับสนุน: EPEL เป็นโครงการอาสาสมัครของ Fedora ซึ่งไม่มีข้อตกลงระดับการให้บริการ (SLA) และผู้ดูแลแพ็กเกจอาจให้การสนับสนุนเพียงแค่ RHEL minor release เดียวหรือ 13 เดือนเท่านั้น ควรทำรายการแพ็กเกจที่ติดตั้งไว้ด้วย dnf repository-packages epel list installed และใช้ dnf versionlock กับแพ็กเกจ EPEL ใดก็ตามที่บริการซึ่งต้องติดต่อกับลูกค้าจำเป็นต้องใช้งาน

ทำไม dnf ถึงแจ้งว่าไม่มีคำสั่ง config-manager?

เพราะ config-manager เป็นปลั๊กอินของ dnf ไม่ใช่คำสั่งพื้นฐานที่ติดตั้งมาพร้อมกับระบบ และอิมเมจแบบ minimal หรือ container มักจะไม่มี dnf-plugins-core ติดตั้งมาให้ ข้อความแจ้งเตือนได้ระบุวิธีแก้ไขไว้แล้วคือ sudo dnf install -y 'dnf-command(config-manager)' โดยต้องใส่เครื่องหมายคำพูดเพื่อให้ shell ไม่อ่านค่าในวงเล็บ หากคุณยังไม่สามารถติดตั้งสิ่งใดได้ ให้รัน grep -rl crb /etc/yum.repos.d/ แล้วเปิดไฟล์ที่ระบุ จากนั้นตั้งค่า enabled=1 ในส่วน [crb] ด้วยตนเอง

CRB และ PowerTools แตกต่างกันอย่างไร?

ทั้งสองคือ repository เดียวกันแต่ใช้ชื่อเรียกต่างกัน เวอร์ชัน 8 เรียกว่า PowerTools โดยมีรหัสคือ powertools ส่วนเวอร์ชัน 9 ขึ้นไปเรียกว่า CRB โดยมีรหัสคือ crb และผลิตภัณฑ์ของ Red Hat เองเรียกเนื้อหาส่วนนี้ว่า CodeReady Linux Builder มันประกอบด้วย development headers, static libraries และเครื่องมือสำหรับการ build โดยจะถูกปิดใช้งานไว้เป็นค่าเริ่มต้นบน Rocky และ AlmaLinux 9 สำหรับ AlmaLinux 10 จะเปิดใช้งานเป็นค่าเริ่มต้นตั้งแต่เวอร์ชัน 10.0 ดังนั้นให้ตรวจสอบ dnf repolist --enabled ก่อนรันคำสั่งเปิดใช้งานในเวอร์ชันดังกล่าว

ฉันจะลบ EPEL ออกโดยไม่ทำให้ระบบเสียหายได้อย่างไร?

ให้ทำรายการแพ็กเกจก่อนด้วย dnf repository-packages epel list installed เพราะการลบเพียงแพ็กเกจ epel-release จะไม่ลบสิ่งที่ติดตั้งมาจาก EPEL ออกไป แพ็กเกจเหล่านั้นจะยังคงอยู่ในดิสก์โดยไม่มีแหล่งอัปเดตและไม่ได้รับแพตช์ความปลอดภัยโดยไม่มีการแจ้งเตือนใดๆ ให้คุณตัดสินใจทีละแพ็กเกจว่าจะลบหรือแทนที่แพ็กเกจที่ไม่ต้องการแล้ว จากนั้นจึงค่อยรัน sudo dnf remove epel-release หากมีบางอย่างจาก EPEL ที่ไม่ได้ถูกแทนที่และจำเป็นต้องลบออกจริงๆ sudo dnf repository-packages epel remove จะล้างรายการทั้งหมดในการทำรายการเดียว ดังนั้นโปรดอ่านรายการที่ระบบเสนอให้ลบอย่างละเอียดก่อนกดยืนยัน