วิธีติดตั้ง EPEL และเปิดใช้งาน CRB บน Rocky และ AlmaLinux

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

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

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

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

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

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

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

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

CRB คือ repository ที่ชื่อว่า CodeReady Builder ซึ่งในเวอร์ชัน 8 เรียกว่า PowerTools โดยเก็บส่วนประกอบสำหรับการพัฒนาของระบบ เช่น 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 มาสร้างใหม่สำหรับ Enterprise Linux รุ่นปัจจุบัน ดูแลโดยกลุ่ม 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 เท่านั้น และไม่ได้ป้องกันปัญหาจากแหล่งอื่นที่คุณเพิ่มเข้ามาในภายหลัง

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

อีกหนึ่งผลกระทบที่ควรทราบก่อนเปิดใช้งานคือ EPEL ถูกสร้างขึ้นโดยอ้างอิงกับ RHEL minor release รุ่นล่าสุด หากคุณคงเซิร์ฟเวอร์ไว้ที่ minor release รุ่นเก่า โดยใช้ mirror แบบแช่แข็งหรือ repository ของ vendor แพ็กเกจ 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 หรือ container จะไม่มีแพ็กเกจนี้มาให้ คำแนะนำของ 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 อื่นไม่ได้ทำตาม ผู้ให้บริการ repository สำหรับฐานข้อมูล, agent หรือ language runtime อาจจัดส่ง library ในเวอร์ชันของตนเองซึ่ง 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 ของผู้ให้บริการที่ควรจะให้เฉพาะ agent ของตนเองเท่านั้นสามารถกำหนดได้ด้วยบรรทัดเดียว

[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 9 มีเวอร์ชันนำหน้า RHEL 9 ดังนั้นการชี้เครื่อง Rocky 9 ไปที่ repository ของ Stream แม้เพียงครั้งเดียว หรือแม้แต่เพียงแพ็กเกจเดียว จะทำให้คุณได้แพ็กเกจที่มีเวอร์ชันสูงกว่าที่ Rocky จะปล่อยออกมา เมื่อถึงรอบการปล่อย minor release ถัดไปของ Rocky เวอร์ชันของแพ็กเกจนั้นใน repository จะต่ำกว่าที่คุณมีอยู่ ส่งผลให้ dnf upgrade จะไม่ดำเนินการใดๆ กับแพ็กเกจดังกล่าว เครื่องของคุณจึงกลายเป็นระบบที่ผสมผสานกันโดยไม่มีใครเคยทดสอบ และจะคงสภาพนั้นไปอีกหลายปีในขณะที่คุณเข้าใจผิดว่าระบบได้รับการแพตช์อยู่

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

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

การที่ repository ของผู้จำหน่ายซอฟต์แวร์ทับซ้อนกับแพ็กเกจใน AppStream เป็นรูปแบบที่ไม่รุนแรงของปัญหาเดียวกัน และบรรทัด includepkgs ด้านบนคือวิธีแก้ไข เครื่องมือสำหรับคอนเทนเนอร์มักเป็นกรณีที่พบบ่อยที่สุด เนื่องจาก containerd.io จาก repository ของ Docker เองจะขัดแย้งกับ runc จาก AppStream ดังนั้นต้องเลือกเอาอย่างใดอย่างหนึ่ง ตัดสินใจให้เด็ดขาด บันทึกการยกเว้นไว้ และปฏิบัติตามลำดับขั้นตอนที่ถูกต้อง: คู่มือ การติดตั้ง 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 ที่เพิ่มเข้ามาคือบุคคลที่สามที่สามารถส่งแพ็กเกจมาให้คุณได้ทุกเมื่อ และทุก repository จะทำให้การอัปเกรดเวอร์ชันหลักในอนาคตยากขึ้น

หากคุณยังตัดสินใจเลือกระหว่างสอง distribution นี้ โครงสร้างโดยรวมของทั้งสองระบบนั้นเหมือนกัน และ epel-release ก็ทำงานในลักษณะเดียวกัน ความแตกต่างที่แท้จริงอยู่ที่จุดอื่น: การเปรียบเทียบระหว่าง Rocky Linux และ AlmaLinux ได้ครอบคลุมถึงแนวคิดในการสร้างระบบใหม่ เนื่องจากปัจจุบัน 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 จะลบแพ็กเกจเหล่านั้นออกในการทำรายการเดียว ดังนั้นโปรดอ่านรายการที่จะถูกลบอย่างละเอียดก่อนกดยืนยัน