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 ให้มองคอลัมน์ที่สองเป็นภาระงานที่ต้องทำ ในช่วงเวลาสิบปี Fedora ต้องการการอัปเกรดระบบปฏิบัติการทั้งหมดประมาณ 10 ครั้ง เทียบกับ 2 ครั้งบน Ubuntu LTS ตัวเลข 36 เดือนของ Debian คือการสนับสนุนความปลอดภัยตามปกติ และมีทีม LTS แยกต่างหากที่จะขยายระยะเวลาการสนับสนุนรุ่นส่วนใหญ่ไปจนถึงประมาณห้าปี

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

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

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

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 ขนาดเล็ก จากนั้นเครื่องจะรีบูตอีกครั้งเข้าสู่รุ่นใหม่ ให้วางแผนสำหรับการรีบูต 2 ครั้งและช่วงเวลาที่ 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 จะแสดงบันทึกธุรกรรมจากการบูตแบบออฟไลน์ ซึ่งเป็นบันทึกเดียวที่ระบุสิ่งที่เกิดขึ้นในขณะที่คุณไม่มี shell ใช้งาน ส่วน distro-sync จะดึงสิ่งที่ยังค้างอยู่ให้เป็นเวอร์ชันของรุ่นใหม่ และ repoquery --extras จะแสดงรายการแพ็กเกจที่ติดตั้งอยู่ซึ่งไม่มีใน repository ที่เปิดใช้งานแล้ว ซึ่งเป็นจุดที่คุณจะพบไฟล์ตกค้างจาก repo ที่ไม่ได้ออกเวอร์ชันสำหรับรุ่นใหม่

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

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

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

เมื่อแพ็กเกจมีการออกไฟล์ config เริ่มต้นใหม่และคุณได้แก้ไขไฟล์เดิมไว้ 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 ที่พลาดช่วงเวลาสนับสนุน

ไม่มีสิ่งใดเกิดขึ้นในวันนั้นโดยตรง ความล้มเหลวจะปรากฏขึ้นในครั้งถัดไปที่คุณเรียกใช้ตัวจัดการแพ็กเกจ รุ่นที่สิ้นสุดอายุการใช้งาน (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 กำหนดให้ข้ามรุ่นได้ครั้งละหนึ่งหรือสองรุ่นเท่านั้น ดังนั้นหากเซิร์ฟเวอร์ของคุณล้าหลังไปสี่รุ่น หมายความว่าคุณต้องทำการอัปเกรดหลายครั้งติดต่อกัน ซึ่งแต่ละครั้งมีความเสี่ยงที่จะล้มเหลว และทุกขั้นตอนต้องดำเนินการโดยไม่มีการสนับสนุนด้านความปลอดภัย สำหรับการใช้งานบน 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 จะถูกปิดไว้เป็นค่าเริ่มต้น ดังนั้นหากไม่ได้ตั้งค่าอะไรเพิ่มเติม ตัวจับเวลาจะดาวน์โหลดอัปเดตมาไว้แต่จะไม่ติดตั้งสิ่งใดเลย upgrade_type ใช้สำหรับเลือกระหว่าง default และ security ส่วน reboot รองรับค่า never, when-changed หรือ when-needed

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

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

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

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