ใช้ Fedora Server บน VPS ต้องอัปเกรดบ่อยแค่ไหน

Fedora แต่ละรุ่นได้รับการอัปเดตความปลอดภัยนานเท่าใด

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

วันที่ที่กำหนดไว้ช่วยให้เห็นภาพชัดเจนขึ้น ณ เดือนสิงหาคม 2026 รุ่นที่ได้รับการสนับสนุนคือ Fedora 43 และ Fedora 44 โดย Fedora 44 เปิดตัวเมื่อวันที่ 28 เมษายน 2026 และมีกำหนดสิ้นสุดอายุการใช้งานในเดือนมิถุนายน 2027 ส่วน Fedora 42 เปิดตัวในเดือนเมษายน 2025 และสิ้นสุดอายุการใช้งานในเดือนพฤษภาคม 2026 ซึ่งเป็นเวลาสี่สัปดาห์หลังจากที่ Fedora 44 เปิดตัว ดังนั้นเซิร์ฟเวอร์ที่สร้างจากอิมเมจ Fedora 42 จึงหมดระยะเวลาการสนับสนุนในอีกสิบสามเดือนต่อมา โดยที่ไม่ได้เกิดจากความผิดพลาดของผู้ดูแลระบบแต่อย่างใด

Fedora เทียบกับ LTS ในหน่วยเดือน

LTS หมายถึงการสนับสนุนระยะยาว (Long Term Support) คือรุ่นที่ผู้ผลิตยังคงออกแพตช์ให้ต่อเนื่องเป็นเวลาหลายปีแทนที่จะเป็นเพียงไม่กี่เดือน EOL หมายถึงจุดสิ้นสุดอายุการใช้งาน (End of Life) ซึ่งเป็นวันที่การออกแพตช์จะยุติลง ต่อไปนี้คือสิ่งที่แต่ละโครงการประกาศไว้สำหรับรุ่นที่คุณจะติดตั้งในปัจจุบัน

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora ให้การสนับสนุน 13 เดือนต่อรุ่น Ubuntu LTS ให้การสนับสนุน 60 และรุ่นที่สร้างใหม่สำหรับองค์กรอย่าง AlmaLinux ให้การสนับสนุน 120 ให้มองคอลัมน์ที่สองเป็นภาระงานที่ต้องทำ ในระยะเวลา 10 ปี Fedora ต้องการการอัปเกรดระบบปฏิบัติการทั้งระบบประมาณ 10 ครั้ง เทียบกับ 2 ครั้งบน Ubuntu LTS ตัวเลข 36 เดือนของ Debian คือระยะเวลาการสนับสนุนความปลอดภัยตามปกติ และทีม LTS แยกต่างหากจะขยายระยะเวลาสนับสนุนรุ่นส่วนใหญ่ไปจนถึงประมาณ 5 ปี

ข้อมูลเหล่านี้คือระยะเวลาการสนับสนุนที่ประกาศไว้ ซึ่งตรวจสอบ ณ เดือนสิงหาคม 2026 ไม่ใช่การวัดค่า uptime เหตุผลที่รอบการออกรุ่นแตกต่างกันนั้นอยู่ใน ความแตกต่างระหว่าง Ubuntu LTS กับรุ่น interim บนเซิร์ฟเวอร์ สิ่งที่สำคัญในที่นี้คือปริมาณงานที่แต่ละรุ่นสร้างให้กับคุณ

สิ่งที่เกิดขึ้นจริงระหว่างการอัปเกรดเวอร์ชัน Fedora

DNF 5 เป็นตัวจัดการแพ็กเกจเริ่มต้นตั้งแต่ Fedora 41 เป็นต้นมา และ dnf จะเป็นผู้เรียกใช้งาน คำสั่ง system-upgrade เป็นส่วนหนึ่งของ dnf5 โดยตรง จึงไม่จำเป็นต้องติดตั้งปลั๊กอินเพิ่มเติม หากคุณย้ายมาจาก Debian หรือ Ubuntu คำสั่งส่วนใหญ่ที่คุณใช้ในชีวิตประจำวันจะมี คำสั่ง dnf ที่เทียบเท่ากับ apt แต่การอัปเกรดเวอร์ชันด้านล่างนี้เป็นงานเพียงไม่กี่อย่างที่ไม่มีคำสั่งเทียบเท่าโดยตรง ให้เริ่มจากเวอร์ชันปัจจุบันที่อัปเดตแพตช์ทั้งหมดแล้ว:

sudo dnf upgrade --refresh
sudo reboot

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

sudo dnf system-upgrade download --releasever=44

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

จากนั้นให้รันคำสั่ง:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status จะยืนยันว่าธุรกรรมถูกเตรียมไว้และรอการดำเนินการ ส่วน dnf system-upgrade reboot จะรีสตาร์ทเครื่องเข้าสู่โหมด offline transaction ซึ่งเป็นการบูตแบบจำกัดเพื่อรันธุรกรรม RPM โดยเฉพาะ วิธีนี้จำเป็นเพราะการแทนที่ glibc และ systemd ในขณะที่บริการต่างๆ กำลังทำงานอยู่จะทำให้ระบบติดตั้งไม่สมบูรณ์ เซิร์ฟเวอร์ของคุณจะไม่สามารถเข้าถึงได้ตลอดระยะเวลาของธุรกรรม ซึ่งปกติจะใช้เวลาหลายนาทีบน VPS ขนาดเล็ก จากนั้นเครื่องจะรีบูตอีกครั้งเข้าสู่เวอร์ชันใหม่ ให้วางแผนสำหรับการรีบูตสองครั้งและช่วงเวลาที่ SSH จะไม่ตอบสนอง

เมื่อระบบกลับมาทำงาน:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release ควรแสดงผลลัพธ์ในลักษณะเดียวกับ Fedora release 44 (Forty Four) คำสั่งย่อย log จะแสดงบันทึกธุรกรรมจากการบูตแบบ offline ซึ่งเป็นบันทึกเดียวที่ระบุสิ่งที่เกิดขึ้นในขณะที่คุณไม่มี shell ใช้งาน ส่วน distro-sync จะดึงข้อมูลที่เหลืออยู่ให้เป็นเวอร์ชันของรุ่นใหม่ และ repoquery --extras จะแสดงรายการแพ็กเกจที่ติดตั้งอยู่ซึ่งไม่อยู่ใน repository ที่เปิดใช้งานแล้ว ซึ่งเป็นจุดที่คุณจะพบไฟล์ตกค้างจาก repo ที่ไม่มีการเผยแพร่สำหรับเวอร์ชันใหม่

ให้ทำ snapshot ของดิสก์ก่อนขั้นตอนการดาวน์โหลด เนื่องจากธุรกรรมจะทำงานในขณะที่คุณไม่สามารถมองเห็นหน้าจอได้ ดังนั้นหากเกิดความล้มเหลวระหว่างการบูตแบบ offline คุณจะไม่สามารถเข้าถึงผ่าน SSH ได้ และวิธีเดียวที่จะเข้าถึงระบบคือผ่าน console ที่ผู้ให้บริการจัดเตรียมไว้ให้ เช่น VNC หรือ serial ตรวจสอบให้แน่ใจว่าคุณมี console หรือ snapshot ก่อนเริ่มดำเนินการ ไม่ใช่หลังจากนั้น

อีกหนึ่งการตรวจสอบที่ผู้คนมักมองข้าม:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

เมื่อแพ็กเกจมีการอัปเดตไฟล์คอนฟิกูเรชันเริ่มต้นใหม่และคุณได้แก้ไขไฟล์เดิมไว้ RPM จะไม่เขียนทับไฟล์ของคุณ แต่จะเขียนไฟล์เวอร์ชันใหม่ไว้ข้างๆ ในชื่อ .rpmnew ดังนั้น sshd หรือ nginx ของคุณจะยังคงทำงานเหมือนเดิมในเวอร์ชันเก่า ในขณะที่ค่าเริ่มต้นใหม่จะถูกเก็บไว้ในดิสก์โดยไม่มีการใช้งาน ให้อ่านไฟล์เหล่านั้นหลังการอัปเกรดทุกครั้ง การติดตั้ง rpmconf และรัน sudo rpmconf -a จะช่วยให้คุณตรวจสอบไฟล์เหล่านั้นทีละไฟล์และแสดงความแตกต่างให้เห็น

ที่เก็บซอฟต์แวร์จากภายนอกเป็นสาเหตุที่ทำให้การอัปเกรดล้มเหลว

แพ็กเกจทั้งหมดของ Fedora จะถูกอัปเดตพร้อมกันในวันเปิดตัว แต่ซอฟต์แวร์จากภายนอก Fedora จะอัปเดตตามกำหนดการของผู้พัฒนาเอง ที่เก็บซอฟต์แวร์ของผู้จำหน่ายส่วนใหญ่มักระบุ $releasever ไว้ใน URL ดังนั้นทันทีที่คุณอัปเกรด dnf จะเริ่มร้องขอ path ที่อาจจะยังไม่มีอยู่จริง

ตรวจสอบรายการที่คุณมีอยู่:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

สำหรับที่เก็บซอฟต์แวร์ที่ไม่ใช่ของ Fedora ให้ทดสอบกับรุ่นที่ต้องการอัปเกรดก่อนที่คุณจะดำเนินการใดๆ:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

หากผู้จำหน่ายได้เผยแพร่ซอฟต์แวร์สำหรับรุ่นนั้นแล้ว dnf จะดาวน์โหลด metadata และจบการทำงานโดยไม่มีข้อผิดพลาด แต่หากยังไม่มี คุณจะได้รับข้อผิดพลาด 404 สำหรับ path เช่น https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml และความล้มเหลวเดียวกันนี้จะทำให้ system-upgrade download หยุดทำงานในภายหลัง ในช่วงสัปดาห์แรกๆ หลังจากการเปิดตัว Fedora นี่เป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้การอัปเกรดไม่สามารถเริ่มต้นได้

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

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

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

จะเกิดอะไรขึ้นกับเซิร์ฟเวอร์ Fedora ที่พลาดช่วงเวลาอัปเดต

ไม่มีอะไรเกิดขึ้นในวันที่กำหนด แต่ปัญหาจะปรากฏขึ้นในครั้งถัดไปที่คุณเรียกใช้ package manager เนื่องจากรุ่นที่สิ้นสุดอายุการใช้งาน (End of life) จะถูกย้ายออกจากเครือข่าย mirror ไปยังคลังเก็บถาวร (archive) ส่งผลให้ dnf upgrade ล้มเหลวขณะดึงข้อมูล metadata โดยจะแสดงข้อผิดพลาด 404 บน URL ของ metalink สำหรับรุ่นที่คุณใช้งานอยู่:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

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

การแก้ไขสถานการณ์นี้สามารถทำได้แต่ใช้เวลานาน คุณสามารถเปลี่ยนจุดอ้างอิงของ repository ไปยังคลังเก็บถาวรของ Fedora ที่ https://dl.fedoraproject.org/pub/archive/fedora/linux/ แล้วดำเนินการอัปเกรดจากจุดนั้น Fedora กำหนดให้ข้ามรุ่นได้ครั้งละ 1 หรือ 2 รุ่นเท่านั้น ดังนั้นหากเซิร์ฟเวอร์ของคุณล้าหลังไป 4 รุ่น หมายความว่าคุณต้องทำหลายขั้นตอนต่อเนื่องกัน ซึ่งแต่ละขั้นตอนมีความเสี่ยงที่จะล้มเหลว และทุกขั้นตอนต้องดำเนินการโดยไม่มีการสนับสนุนจาก repository ปกติ สำหรับการใช้งานบน VPS การสร้างเซิร์ฟเวอร์ใหม่ด้วยอิมเมจปัจจุบันแล้วย้ายข้อมูลข้ามไปมักเป็นวิธีที่ใช้เวลาน้อยกว่าและปลอดภัยกว่า ซึ่งเป็นงานเดียวกับ สิบนาทีแรกบน VPS ใหม่

การอัปเดตอัตโนมัติจะแพตช์เฉพาะ release เท่านั้น ไม่ใช่การอัปเกรดเวอร์ชัน

Fedora สามารถติดตั้งอัปเดตตามเวลาที่กำหนดได้:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

การตั้งค่าจะอยู่ใน /etc/dnf/automatic.conf ซึ่งจะเขียนทับค่าเริ่มต้นที่มากับระบบใน /usr/share/dnf5/dnf5-plugins/automatic.conf โดย apply_updates จะถูกปิดไว้เป็นค่าเริ่มต้น ดังนั้นเมื่อติดตั้งเสร็จตัว timer จะดาวน์โหลดอัปเดตมาไว้แต่จะไม่ติดตั้งให้ upgrade_type ใช้เลือกระหว่าง default และ security ส่วน reboot รองรับค่า never, when-changed หรือ when-needed

กระบวนการนี้ช่วยให้ระบบของคุณเป็นปัจจุบันภายใน release นั้นๆ แต่จะไม่ย้าย Fedora 43 ไปเป็น Fedora 44 เนื่องจากกระบวนการอัปเกรดเวอร์ชันเป็นการดำเนินการที่ต้องตั้งใจทำแยกต่างหาก ซึ่งต้องรีบูตเข้าสู่สถานะ offline transaction นี่คือความแตกต่างในทางปฏิบัติเมื่อเทียบกับ LTS ใน Ubuntu นั้น การอัปเดตความปลอดภัยแบบอัตโนมัติ จะดูแลเครื่องให้ตลอดช่วงเวลา 5 ปีโดยไม่มีการเปลี่ยนเวอร์ชันเลย และการเปลี่ยนเวอร์ชันจะเป็นงานที่วางแผนไว้ เช่น การอัปเกรดจาก 24.04 ไป 26.04 ซึ่งจะเกิดขึ้นเพียงไม่กี่ปีครั้งเท่านั้น

เมื่อ Fedora เป็นตัวเลือกที่เหมาะสมสำหรับเซิร์ฟเวอร์

Fedora เป็นตัวเลือกที่ดีเมื่อความใหม่ของซอฟต์แวร์คือประเด็นสำคัญ

• คุณต้องการ kernel หรือ userspace ที่ใหม่กว่าเวอร์ชัน LTS ใดๆ: เช่น ฮาร์ดแวร์รุ่นล่าสุด หรือ stack ของ container และ systemd ที่ยังต้องใช้เวลาอีกหนึ่งปีกว่าจะเข้าสู่รุ่น enterprise นอกจากนี้ Fedora ยังอัปเดต kernel ไปยังเวอร์ชัน upstream ใหม่ๆ ตลอดช่วงอายุของ release ดังนั้นนี่จึงไม่ใช่แค่ข้อได้เปรียบเพียงครั้งเดียวตอนติดตั้ง
• คุณกำลังตรวจสอบสิ่งที่กำลังจะเข้าสู่ RHEL (Red Hat Enterprise Linux): Fedora เป็นต้นทางให้กับ CentOS Stream ซึ่งส่งต่อไปยัง RHEL ดังนั้นซอฟต์แวร์ที่ build และรันได้บน Fedora ในวันนี้ จึงถือเป็นการทดสอบเทียบกับแพลตฟอร์มระดับองค์กรที่จะเกิดขึ้นในอีกไม่กี่ปีข้างหน้า
• เครื่องมีอายุการใช้งานสั้นตามการออกแบบ: build runner หรือเครื่องทดสอบที่ถูกทำลายทิ้งในสองเดือนไม่มีวันถึงกำหนดสิ้นสุดอายุการใช้งาน (end of life) ตรรกะเดียวกันนี้ครอบคลุมถึง VM แบบใช้แล้วทิ้งที่คุณมอบให้ coding agents ซึ่งเครื่องเหล่านี้ถูกสร้างใหม่บ่อยกว่ารอบการ release ของ Fedora เสียอีก
• มีผู้รับผิดชอบการอัปเกรด: Fedora เหมาะสมกับเซิร์ฟเวอร์ที่มีเจ้าของระบุตัวตนชัดเจนและมีการบันทึกตารางเวลาไว้ แต่ไม่เหมาะอย่างยิ่งสำหรับเครื่องที่ทุกคนลืมไปแล้ว

ทางสายกลาง: แพ็กเกจเวอร์ชันปัจจุบันบนฐานระบบที่เสถียร

ผู้ใช้ส่วนใหญ่ที่ต้องการใช้งาน Fedora บนเซิร์ฟเวอร์มักต้องการเพียงแพ็กเกจเวอร์ชันปัจจุบันแค่ 2-3 รายการ ไม่ใช่ระบบปฏิบัติการเวอร์ชันปัจจุบันทั้งหมด ซึ่งสิ่งเหล่านี้สามารถแยกออกจากกันได้ คุณสามารถใช้ระบบปฏิบัติการแบบ LTS หรือระบบที่สร้างขึ้นใหม่จากซอร์สโค้ดระดับองค์กร (enterprise rebuild) เป็นฐาน แล้วดึงซอฟต์แวร์เวอร์ชันใหม่มาใช้เฉพาะในส่วนที่จำเป็นเท่านั้น Container image ช่วยให้คุณได้แอปพลิเคชันเวอร์ชันใหม่บนโฮสต์ที่คุณไม่จำเป็นต้องอัปเกรดเพื่อรองรับมันเลย (การรัน Docker บน VPS) การใช้ repository ของผู้ผลิตซอฟต์แวร์สำหรับแพ็กเกจที่คุณต้องการเพียงรายการเดียว เช่น PostgreSQL หรือ nginx จะช่วยให้ซอฟต์แวร์นั้นอัปเดตไปข้างหน้าโดยไม่กระทบต่อระบบฐาน

การแลกเปลี่ยนนี้มีความชัดเจนในทั้งสองทิศทาง Container ให้ userspace ใหม่บน kernel เดิมของโฮสต์ ดังนั้นมันจึงไม่ช่วยในกรณีที่คุณต้องการ kernel เวอร์ชันใหม่ ส่วน repository ของผู้ผลิตซอฟต์แวร์ให้แพ็กเกจใหม่หนึ่งรายการบนฐานระบบที่ผู้ผลิตอาจทดสอบมาน้อยกว่า ทั้งสองวิธีนี้ยังคงให้การอัปเดตความปลอดภัยของระบบฐานเป็นไปตามรอบเวลาของ LTS ซึ่งรอบเวลานี้เองคือส่วนที่ทำให้คุณต้องเสียเวลาทำ maintenance window ทุกปีหากใช้ Fedora

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

FAQ

Fedora แต่ละเวอร์ชันได้รับการสนับสนุนนานเท่าใด

ประมาณ 13 เดือน Fedora ออกเวอร์ชันใหม่ทุกหกเดือนโดยประมาณ และสนับสนุนแต่ละเวอร์ชันจนถึงสี่สัปดาห์หลังจากเวอร์ชันถัดไปสองลำดับ Fedora 44 เปิดตัวเมื่อวันที่ 28 เมษายน 2026 และมีกำหนดสิ้นสุดอายุการใช้งานในเดือนมิถุนายน 2027 เมื่อถึงกำหนดดังกล่าว เวอร์ชันนั้นจะหยุดได้รับอัปเดตความปลอดภัย และแพ็กเกจจะถูกย้ายออกจาก mirror ไปยังคลังเก็บถาวรของ Fedora

ฉันสามารถข้าม Fedora เวอร์ชันหนึ่งแล้วอัปเกรดข้ามสองเวอร์ชันพร้อมกันได้หรือไม่

ได้ ภายในขอบเขตที่กำหนด dnf system-upgrade download --releasever= รองรับการอัปเกรดไปยังเวอร์ชันที่ใหม่กว่าหนึ่งหรือสองลำดับ ซึ่งการกระโดดข้ามทีละสองเวอร์ชันคือวิธีการทำงานของรอบการอัปเกรดแบบปีละครั้ง การอัปเกรดที่มากกว่านั้นไม่ใช่เส้นทางที่รองรับ และทุกเวอร์ชันที่เพิ่มขึ้นจะเพิ่มโอกาสที่การเปลี่ยนชื่อแพ็กเกจหรือการเปลี่ยนแปลงรูปแบบ config จะทำให้การทำรายการล้มเหลว หากเครื่องมีเวอร์ชันที่ล้าหลังไปหลายเวอร์ชันและเกินกำหนดสิ้นสุดอายุการใช้งานแล้ว การติดตั้งใหม่ด้วยอิมเมจปัจจุบันมักจะเร็วกว่าการอัปเกรดต่อเนื่องหลายครั้ง

จะเกิดอะไรขึ้นหากเซิร์ฟเวอร์ Fedora ของฉันสิ้นสุดอายุการใช้งาน

ระบบจะยังคงทำงานต่อไปแต่จะไม่ได้รับการแพตช์อีก การเรียกใช้ dnf upgrade ครั้งถัดไปจะล้มเหลวด้วยข้อผิดพลาด 404 ที่ URL ของ metalink สำหรับเวอร์ชันของคุณ เนื่องจากเวอร์ชันที่สิ้นสุดอายุการใช้งานจะถูกย้ายไปยังคลังเก็บถาวรที่ dl.fedoraproject.org คุณสามารถเปลี่ยนเส้นทางไฟล์ repository ไปยังคลังเก็บถาวรนั้นเพื่ออัปเกรดแบบทีละขั้น หรือติดตั้งเซิร์ฟเวอร์ใหม่ด้วยเวอร์ชันที่ยังได้รับการสนับสนุน จนกว่าคุณจะดำเนินการอย่างใดอย่างหนึ่ง จะไม่มีอัปเดตความปลอดภัยใดเข้าถึงเครื่องได้และจะไม่สามารถติดตั้งแพ็กเกจใดๆ ได้

Fedora เป็นตัวเลือกที่ไม่ดีสำหรับเซิร์ฟเวอร์ที่ใช้งานจริง (production) ใช่หรือไม่

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