Fedora Server-ஐ VPS-ல் பயன்படுத்துவது எப்படி?

Fedora release-க்கு எவ்வளவு காலம் பாதுகாப்பு மேம்படுத்தல்கள் (security updates) கிடைக்கும்?

ஒரு Fedora server-ன் ஆயுட்காலம் முழுவதும், ஆண்டுக்கு ஒருமுறை அதன் version-ஐ upgrade செய்ய வேண்டியது அவசியம். Fedora தோராயமாக ஒவ்வொரு ஆறு மாதத்திற்கும் ஒரு புதிய release-ஐ வெளியிடுகிறது. ஒவ்வொரு release-ம், அதற்கு அடுத்த இரண்டு பதிப்புகள் வெளியான நான்கு வாரங்கள் வரை ஆதரவு (support) பெறும். இது தோராயமாக 13 மாதங்கள் வரையிலான மேம்படுத்தல்களை வழங்குகிறது. அந்தத் தேதிக்குப் பிறகு, அந்த release-க்கு எந்தவிதமான பாதுகாப்புத் திருத்தங்களும் (security fixes) வழங்கப்படாது. server தொடர்ந்து இயங்கும், ஆனால் அதில் உள்ள package-களை யாரும் patch செய்ய மாட்டார்கள்.

தேதிகளைக் கொண்டு இதைப் புரிந்துகொள்ளலாம். ஆகஸ்ட் 2026 நிலவரப்படி, Fedora 43 மற்றும் Fedora 44 ஆகிய பதிப்புகள் ஆதரவில் உள்ளன. Fedora 44, 28 ஏப்ரல் 2026 அன்று வெளியானது; இதன் ஆயுட்காலம் ஜூன் 2027-ல் முடிவடையும் எனத் திட்டமிடப்பட்டுள்ளது. Fedora 42 ஏப்ரல் 2025-ல் வெளியாகி, Fedora 44 வெளியான நான்கு வாரங்களுக்குப் பிறகு, மே 2026-ல் அதன் ஆயுட்காலத்தை முடித்துக்கொண்டது. எனவே, Fedora 42 image மூலம் உருவாக்கப்பட்ட ஒரு server, எந்தத் தவறும் செய்யாமலேயே, பதிமூன்று மாதங்களுக்குப் பிறகு ஆதரவு இல்லாத நிலையை அடைந்தது.

Fedora மற்றும் LTS ஒப்பீடு, மாதங்களில்

LTS என்பது long term support என்பதைக் குறிக்கும்: இது பல மாதங்களுக்குப் பதிலாக பல ஆண்டுகளுக்கு vendor-ஆல் patch செய்யப்படும் ஒரு release ஆகும். EOL என்பது end of life என்பதைக் குறிக்கும், அதாவது patch-கள் நிறுத்தப்படும் தேதி. இன்று நீங்கள் நிறுவும் release-க்காக ஒவ்வொரு திட்டமும் வெளியிடும் விவரங்கள் கீழே கொடுக்கப்பட்டுள்ளன.

[
  {
    "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 ஒவ்வொரு release-க்கும் 13 மாதங்கள் ஆதரவை வழங்குகிறது. ஒரு Ubuntu LTS 60 மாதங்களையும், AlmaLinux போன்ற enterprise rebuild 120 மாதங்களையும் வழங்குகிறது. இரண்டாவது நெடுவரிசையை உங்கள் பணிச்சுமையாகக் கருதவும். பத்து ஆண்டுகளில், Fedora-வில் ஏறக்குறைய 10 முறை முழு operating system-ஐயும் upgrade செய்ய வேண்டியிருக்கும், அதே சமயம் Ubuntu LTS-ல் 2 முறை மட்டுமே தேவைப்படும். Debian-ன் 36 மாதங்கள் என்பது அதன் வழக்கமான பாதுகாப்பு ஆதரவாகும், மேலும் ஒரு தனி LTS குழு பெரும்பாலான release-களை சுமார் ஐந்து ஆண்டுகள் வரை நீட்டிக்கிறது.

இவை ஆகஸ்ட் 2026-ல் சரிபார்க்கப்பட்ட அதிகாரப்பூர்வ ஆதரவு காலங்கள், இவை uptime அளவீடுகள் அல்ல. இந்த கால இடைவெளிகள் ஏன் மாறுபடுகின்றன என்பதற்கான காரணம் Ubuntu LTS மற்றும் interim releases-க்கு இடையிலான வேறுபாடு என்பதில் உள்ளது. இதில் முக்கியமானது, ஒவ்வொன்றும் உங்களுக்கு உருவாக்கும் பணிச்சுமையே ஆகும்.

Fedora பதிப்பு மேம்படுத்தல் (upgrade) உண்மையில் எதை உள்ளடக்கியது

Fedora 41 முதல் DNF 5 இயல்புநிலை package manager-ஆக உள்ளது, மேலும் dnf அதை இயக்குகிறது. system-upgrade கட்டளை dnf5-ன் ஒரு பகுதியாகும், எனவே முதலில் நிறுவ வேண்டிய plugin எதுவும் இல்லை. தற்போதைய release-லிருந்து தொடங்கி, முழுமையாக patch செய்யவும்:

sudo dnf upgrade --refresh
sudo reboot

Reboot செய்வது முக்கியம், ஏனெனில் மேம்படுத்தல் தற்போது நிறுவப்பட்டு இயங்கும் மென்பொருட்களின் அடிப்படையில் அமைகிறது. எனவே, முழுமையடையாத kernel அல்லது glibc update அடுத்த கட்டத்தை சிக்கலாக்கும். இப்போது புதிய release-ஐ stage செய்யவும். 44 என்பதற்குப் பதிலாக நீங்கள் மாற விரும்பும் release எண்ணைப் பயன்படுத்தவும்:

sudo dnf system-upgrade download --releasever=44

இது முழு பரிவர்த்தனையையும் (transaction) சரிபார்த்து அனைத்து package-களையும் பதிவிறக்கம் செய்கிறது, மேலும் இயங்கும் system-ல் எதையும் மாற்றாது. ஒரு சிறிய server-ல் சில ஆயிரம் package-களும், ஒன்று முதல் மூன்று gigabytes அளவிலான தரவுகளும் பதிவிறக்கப்படலாம். dnf-ஆல் பரிவர்த்தனையை முடிக்க முடியாவிட்டால், அது அங்கேயே நின்று தடுத்த package-ன் பெயரைத் தெரிவிக்கும். இது நல்ல விஷயம், ஏனெனில் machine இயங்கிக்கொண்டிருக்கும்போதே இந்தத் தோல்வி நிகழ்வதால், உங்களிடம் shell access இருக்கும்.

பிறகு அதை இயக்கவும்:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status ஒரு பரிவர்த்தனை stage செய்யப்பட்டு காத்திருப்பதை உறுதிப்படுத்துகிறது. dnf system-upgrade reboot machine-ஐ offline பரிவர்த்தனைக்கு மறுதொடக்கம் செய்கிறது: இது ஒரு minimal boot, இதில் RPM பரிவர்த்தனை தனியாக இயங்கும். இயங்கும் services-க்கு அடியில் glibc மற்றும் systemd-ஐ மாற்றினால் system பாதியிலேயே நின்றுவிடும் என்பதால், இந்த முறை பின்பற்றப்படுகிறது. பரிவர்த்தனை முடியும் வரை உங்கள் server-ஐ அணுக முடியாது, சிறிய VPS-களில் இதற்குச் சில நிமிடங்கள் ஆகும், பிறகு அது புதிய release-ல் மீண்டும் தொடங்கும். இரண்டு முறை reboot ஆகும் என்பதையும், அந்த நேரத்தில் 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 subcommand அந்த offline boot-ன் பரிவர்த்தனை பதிவை (log) அச்சிடும்; shell இல்லாத நேரத்தில் என்ன நடந்தது என்பதற்கான ஒரே ஆதாரம் இதுதான். distro-sync புதிய release-ன் பதிப்புகளுக்கு மாறாமல் எஞ்சியிருக்கும் எதையும் மாற்றும். repoquery --extras தற்போது எந்த repository-லும் இல்லாத நிறுவப்பட்ட package-களைப் பட்டியலிடும்; புதிய release-க்கு வெளியிடப்படாத repo-களில் இருந்து எஞ்சியிருப்பவை இங்கேதான் தெரியும்.

பதிவிறக்கத்திற்கு முன் disk-ஐ snapshot எடுக்கவும். பரிவர்த்தனை நடக்கும்போது உங்களால் திரையைப் பார்க்க முடியாது, எனவே offline boot-ன் போது அது தோல்வியுற்றால், SSH வேலை செய்யாது. அப்போது உங்கள் provider வழங்கும் console, VNC அல்லது serial மூலம் மட்டுமே உள்ளே நுழைய முடியும். தொடங்குவதற்கு முன்பே உங்களிடம் console அல்லது snapshot இருப்பதை உறுதிப்படுத்தவும்.

மக்கள் தவிர்க்கும் மற்றொரு முக்கியமான சரிபார்ப்பு:

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

ஒரு package புதிய default config file-ஐ வழங்கும்போது, நீங்கள் பழைய கோப்பை மாற்றியிருந்தால், RPM உங்கள் கோப்பை மேலெழுதாது (overwrite). அது package-ல் உள்ள பதிப்பை .rpmnew என்ற பெயரில் அருகில் சேமிக்கும். எனவே, உங்கள் sshd அல்லது nginx பழைய release-ல் இருந்தது போலவே செயல்படும், அதே சமயம் புதிய default அமைப்புகள் கோப்பில் வாசிக்கப்படாமல் இருக்கும். ஒவ்வொரு மேம்படுத்தலுக்குப் பிறகும் அந்தக் கோப்புகளைப் படிக்கவும். rpmconf-ஐ நிறுவி, sudo rpmconf -a-ஐ இயக்குவதன் மூலம் அவற்றை ஒவ்வொன்றாகச் சரிபார்த்து, மாற்றங்களைக் காணலாம்.

மூன்றாம் தரப்பு களஞ்சியங்களே (repositories) மேம்படுத்தலைத் தடுக்கின்றன

Fedora-வின் சொந்த தொகுப்புகள் அனைத்தும் வெளியீட்டு நாளன்று ஒன்றாகவே மேம்படுத்தப்படும். Fedora-விற்கு வெளியிலிருந்து வரும் எந்தவொரு தொகுப்பும் அந்தந்த நிறுவனத்தின் கால அட்டவணைப்படியே அமையும். பெரும்பாலான விற்பனையாளர் களஞ்சியங்கள் அவற்றின் URL-ல் $releasever-ஐக் கொண்டிருக்கும். எனவே, நீங்கள் மேம்படுத்திய அடுத்த நொடியே, இன்னும் உருவாக்கப்படாத ஒரு பாதையை (path) dnf தேடத் தொடங்கும்.

உங்களிடம் உள்ளவற்றை பட்டியலிடுங்கள்:

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

Fedora-வினுடையது அல்லாத ஒவ்வொரு களஞ்சியத்தையும், நீங்கள் எதையும் உறுதிப்படுத்தும் முன் இலக்கு வெளியீட்டிற்கு (target release) எதிராகச் சோதிக்கவும்:

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

விற்பனையாளர் அந்த வெளியீட்டிற்கான தொகுப்புகளை வெளியிட்டிருந்தால், dnf மெட்டாடேட்டாவைப் பதிவிறக்கி அமைதியாக வெளியேறும். இல்லையெனில், https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml போன்ற பாதைக்கு 404 பிழை கிடைக்கும்; அதே தோல்வி பின்னர் system-upgrade download-ஐயும் நிறுத்திவிடும். Fedora வெளியீட்டிற்குப் பிந்தைய முதல் சில வாரங்களில், மேம்படுத்தல் தொடங்காமல் இருப்பதற்கு இதுவே மிக முக்கியமான பொதுவான காரணமாகும்.

இதற்கு இரண்டு தீர்வுகள் உள்ளன. விற்பனையாளர் வெளியிடும் வரை சில வாரங்கள் காத்திருப்பது, இதுவே பொதுவாகச் சரியான முடிவாகும். அல்லது அந்த களஞ்சியம் இல்லாமலேயே மேம்படுத்துவது:

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

ஒரு களஞ்சியத்தை முடக்குவது (disable) அதன் தொகுப்புகளை நீக்காது. அவை நிறுவப்பட்ட நிலையிலேயே இருக்கும், ஆனால் நிர்வகிக்கப்படாது. அவை பரிவர்த்தனையைத் தடுத்தால், dnf அதைத் தெரிவிக்கும். --allowerasing-ஐச் சேர்ப்பதன் மூலம், முரண்பாடுகளைத் தீர்க்க நிறுவப்பட்ட தொகுப்புகளை dnf-ஐ நீக்க அனுமதிக்கலாம். எனவே, நீங்கள் ஏற்றுக்கொள்வதற்கு முன் நீக்கப்பட வேண்டிய தொகுப்புகளின் பட்டியலை கவனமாகப் படிக்கவும். அந்தப் பட்டியலில்தான், பயனர்கள் தாங்கள் வைத்திருக்க வேண்டிய database server-ஐத் தவறுதலாக நீக்கிவிடுகிறார்கள்.

Fedora server-ன் காலக்கெடுவை தவறவிட்டால் என்ன நடக்கும்

அந்த நாளில் எந்த மாற்றமும் நடக்காது. நீங்கள் அடுத்த முறை package manager-ஐ பயன்படுத்தும்போதுதான் சிக்கல் வெளிப்படும். End of life அடைந்த release-கள் mirror network-லிருந்து archive-க்கு மாற்றப்பட்டுவிடும். எனவே, உங்கள் release-க்கான metalink URL-ல் 404 error ஏற்படுவதால் dnf upgrade metadata-வை பெறும்போது தோல்வியடையும்:

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

அந்த machine தொடர்ந்து traffic-ஐ கையாளும், இதுவே இந்த நிலையை அமைதியானதாகவும் ஆபத்தானதாகவும் மாற்றுகிறது. இதற்கு எந்த security update-களும் கிடைக்காது. எதையும் புதிதாக install செய்ய முடியாது என்பதால், OpenSSH அல்லது nginx போன்றவற்றுக்கு advisory வரும்போது, அதை patch செய்ய எந்த ஆதரவும் இருக்காது.

இதிலிருந்து மீள்வது சாத்தியம், ஆனால் மெதுவான செயல்முறை. நீங்கள் repositories-ஐ https://dl.fedoraproject.org/pub/archive/fedora/linux/-ல் உள்ள Fedora archive-க்கு மாற்றி, அங்கிருந்து upgrade செய்யலாம். Fedora ஒரு நேரத்தில் ஒன்று அல்லது இரண்டு release-கள் மட்டுமே தாவிச் செல்ல அனுமதிக்கும். எனவே, நான்கு release-கள் பின்தங்கியுள்ள ஒரு server-க்கு, ஒவ்வொன்றாக பலமுறை upgrade செய்ய வேண்டியிருக்கும். ஒவ்வொரு முறையும் தோல்வி அடைய வாய்ப்புள்ளது, மேலும் ஒவ்வொரு முறையும் offline boot-ல் எந்த பாதுகாப்பும் இன்றி இயங்கும். ஒரு VPS-ல், தற்போதைய image-ஐ வைத்து மீண்டும் கட்டமைத்து, தரவுகளை இடமாற்றம் செய்வது பொதுவாக குறுகிய மற்றும் பாதுகாப்பான வழியாகும். இது புதிய VPS-ன் முதல் பத்து நிமிடங்கள் பகுதியில் விவரிக்கப்பட்டுள்ள அதே வேலையைச் செய்வதாகும்.

தானியங்கி மேம்படுத்தல்கள் ஒரு release-ஐ patch செய்கின்றன. அவை ஒருபோதும் upgrade செய்வதில்லை.

Fedora அதன் மேம்படுத்தல்களை ஒரு timer மூலம் நிறுவ முடியும்:

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-க்கு மாற்றாது, ஏனெனில் version upgrade என்பது ஒரு தனிப்பட்ட, திட்டமிடப்பட்ட செயல்பாடாகும்; இது offline transaction மூலம் கணினியை reboot செய்யும். இது LTS-க்கும் இதற்கும் உள்ள நடைமுறை வேறுபாடாகும். Ubuntu-வில், unattended security upgrades ஒரு கணினியை ஐந்து ஆண்டு காலத்திற்கு எந்த version மாற்றமும் இன்றி இயங்க வைக்கிறது, மேலும் version மாற்றம் என்பது 24.04 முதல் 26.04 வரையிலான upgrade போன்ற சில ஆண்டுகளுக்கு ஒருமுறை செய்யப்படும் திட்டமிடப்பட்ட பணியாகும்.

Fedora-வை server-ஆகப் பயன்படுத்துவது எப்போது சரியானது

புதிய தொழில்நுட்பங்கள் தேவைப்படும்போது Fedora ஒரு சிறந்த தேர்வாகும்.

• LTS பதிப்புகளில் இல்லாத புதிய kernel அல்லது userspace உங்களுக்குத் தேவைப்படும்போது: புதிய hardware, அல்லது enterprise release-க்கு இன்னும் ஓராண்டு காலம் தேவைப்படும் container மற்றும் systemd stack ஆகியவற்றுக்கு இது பொருந்தும். Fedora ஒரு release-ன் காலத்திலும் புதிய upstream kernels-க்கு மாறுவதால், இது நிறுவும் நேரத்தில் மட்டும் கிடைக்கும் பயன் அல்ல.
• RHEL (Red Hat Enterprise Linux)-க்கு வரவிருக்கும் மாற்றங்களை நீங்கள் சரிபார்க்க விரும்பினால்: Fedora, CentOS Stream-க்கு உள்ளீடாக அமைகிறது, அது RHEL-க்கு உள்ளீடாக அமைகிறது. எனவே, இன்று Fedora-வில் இயங்கும் மென்பொருள், இன்னும் சில ஆண்டுகளில் வரவிருக்கும் enterprise platform-ல் சோதிக்கப்படுகிறது.
• இயந்திரம் குறுகிய கால பயன்பாட்டிற்காக வடிவமைக்கப்பட்டிருந்தால்: இரண்டு மாதங்களில் அழிக்கப்படும் ஒரு build runner அல்லது test box-க்கு அதன் ஆயுட்காலம் முடிவடையும் கவலை இல்லை. இதே தர்க்கம் coding agents-க்கு நீங்கள் வழங்கும் disposable VMs-க்கும் பொருந்தும், அங்கு Fedora release-களை விட அடிக்கடி அந்த இயந்திரம் மீண்டும் உருவாக்கப்படுகிறது.
• மேம்படுத்தல்களைக் கவனித்துக்கொள்ள ஒருவர் இருந்தால்: ஒரு குறிப்பிட்ட பொறுப்பாளர் மற்றும் கால அட்டவணை உள்ள server-க்கு Fedora பொருத்தமானது. அனைவரும் மறந்துபோன ஒரு இயந்திரத்திற்கு இது ஏற்றதல்ல.

நடுவழி: நிலையான தளத்தில் தற்போதைய தொகுப்புகள்

Fedora-வை server-ல் பயன்படுத்த விரும்புபவர்களில் பெரும்பாலானோர், முழுமையான இயங்குதளத்திற்குப் பதிலாக, இரண்டு அல்லது மூன்று தற்போதைய தொகுப்புகளை மட்டுமே எதிர்பார்க்கிறார்கள். இவை இரண்டையும் தனித்தனியாகக் கையாள முடியும். ஒரு LTS அல்லது enterprise rebuild-ஐ அடிப்படையாகக் கொண்டு, உங்களுக்குத் தேவையான புதிய மென்பொருளை மட்டும் அதில் பதிவிறக்கலாம். ஒரு container image, நீங்கள் அடிக்கடி upgrade செய்ய வேண்டிய அவசியமில்லாத host-ல் புதிய பதிப்பை வழங்குகிறது (VPS-ல் Docker-ஐ இயக்குதல்). PostgreSQL அல்லது nginx போன்ற உங்களுக்குத் தேவையான குறிப்பிட்ட தொகுப்பிற்கு மட்டும் vendor repository-ஐப் பயன்படுத்தினால், அந்த ஒரு மென்பொருள் மட்டும் மேம்படுத்தப்படும், அடிப்படை அமைப்பு மாறாது.

இந்த அணுகுமுறையில் இருபுறமும் சாதக பாதகங்கள் உள்ளன. ஒரு container, host-ன் பழைய kernel-ல் புதிய userspace-ஐ வழங்குகிறது; எனவே, உங்களுக்கு kernel-ன் புதிய பதிப்பு தேவைப்படும்போது இது உதவாது. ஒரு vendor repository, vendor குறைவாகவே சோதித்த அடிப்படை அமைப்பில் ஒரு புதிய தொகுப்பை வழங்குகிறது. இவை இரண்டுமே அடிப்படை அமைப்பின் பாதுகாப்பு மேம்படுத்தல்களை (security updates) LTS காலவரிசையிலேயே வைத்திருக்கின்றன. Fedora-வில் ஒவ்வொரு ஆண்டும் பராமரிப்புப் பணிக்காக (maintenance window) நீங்கள் செலவிடும் நேரம் இந்த காலவரிசையால்தான் ஏற்படுகிறது.

நீங்கள் server-க்கு Fedora-வைத் தேர்வு செய்தால், அதன் சுழற்சியை ஒரு காலண்டரில் குறித்துக்கொள்ளுங்கள். ஒரு புதிய release வெளிவந்ததும், vendor repositories-ல் மாற்றங்கள் பிரதிபலிக்க சில வாரங்கள் காத்திருங்கள். பின் snapshot எடுத்து, upgrade செய்து, சேவைகள் சரியாக இயங்குகின்றனவா என்று சரிபார்க்கவும். இந்த நடைமுறைக்கு ஆண்டுக்கு ஒரு மணிநேரம் மட்டுமே செலவாகும், இது சிறப்பாகச் செயல்படும். ஏதேனும் ஒன்று பழுதடைந்த பிறகு upgrade-ஐ நினைவுகூரும்போதுதான் சிக்கல்கள் ஏற்படுகின்றன.

FAQ

Fedora release எவ்வளவு காலம் ஆதரிக்கப்படுகிறது?

சுமார் 13 மாதங்கள். Fedora தோராயமாக ஒவ்வொரு ஆறு மாதங்களுக்கும் ஒரு புதிய release-ஐ வெளியிடுகிறது. ஒவ்வொரு release-ம், அதற்கு அடுத்த இரண்டு பதிப்புகள் வெளியான பிறகு சுமார் நான்கு வாரங்கள் வரை ஆதரிக்கப்படும். Fedora 44 ஆனது 28 April 2026 அன்று வெளியானது; இதன் ஆயுட்காலம் June 2027-ல் முடிவடையும் எனத் திட்டமிடப்பட்டுள்ளது. அந்தத் தேதி கடந்த பிறகு, அந்த release-க்கு security updates கிடைக்காது மற்றும் அதன் packages அனைத்தும் Fedora-வின் archive-க்கு மாற்றப்படும்.

நான் ஒரு Fedora release-ஐத் தவிர்த்துவிட்டு, ஒரே நேரத்தில் இரண்டு பதிப்புகளை upgrade செய்ய முடியுமா?

ஆம், சில கட்டுப்பாடுகளுடன் முடியும். dnf system-upgrade download --releasever= ஆனது ஒன்று அல்லது இரண்டு release-கள் முன்னால் உள்ள இலக்கை ஏற்கும். வருடத்திற்கு ஒருமுறை upgrade செய்யும் முறைக்கு, இரண்டு பதிப்புகளைத் தாண்டிச் செல்வது சரியான வழியாகும். இதற்கு மேல் செல்வது ஆதரிக்கப்படும் வழிமுறை அல்ல. ஒவ்வொரு கூடுதல் release-ம், package பெயர் மாற்றம் அல்லது config format மாற்றம் காரணமாக transaction தோல்வியடைவதற்கான வாய்ப்பை அதிகரிக்கிறது. ஒரு machine ஏற்கனவே பல release-கள் பின்தங்கியும், அதன் ஆயுட்காலம் முடிந்தும் இருந்தால், தொடர்ச்சியான upgrade-களை விட தற்போதைய image-ல் மீண்டும் நிறுவுவது (rebuild) வேகமானது.

எனது Fedora server-ன் ஆயுட்காலம் முடிந்துவிட்டால் என்ன நடக்கும்?

அது தொடர்ந்து இயங்கும், ஆனால் patch செய்யப்படாது. ஆயுட்காலம் முடிந்த release-கள் dl.fedoraproject.org-ல் உள்ள archive-க்கு மாற்றப்படுவதால், அடுத்த dnf upgrade கட்டளை உங்கள் release-க்கான metalink URL-ல் 404 பிழையைக் காட்டும். நீங்கள் repository கோப்புகளை அந்த archive-க்கு மாற்றி, படிப்படியாக upgrade செய்யலாம் அல்லது ஆதரிக்கப்படும் ஒரு release-ல் server-ஐ மீண்டும் உருவாக்கலாம். இந்த இரண்டில் ஒன்றைச் செய்யும் வரை, எந்தவொரு security update-ம் அந்த machine-க்குக் கிடைக்காது மற்றும் எந்த package-ம் install ஆகாது.

Production server-க்கு Fedora ஒரு மோசமான தேர்வா?

இது ஒரு பொதுவான பயன்பாட்டிற்கு மோசமான தேர்வு, ஆனால் தகுந்த காரணங்கள் இருந்தால் இது ஒரு சரியான தேர்வாகும். நீங்கள் மாற்ற விரும்பாத ஒரு machine-ல், ஒவ்வொரு வருடமும் முழு operating system-ஐயும் upgrade செய்ய வேண்டியிருக்கும். LTS பதிப்புகளில் இருப்பதை விட புதிய kernel அல்லது userspace தேவைப்படும்போதோ, அல்லது server குறுகிய கால பயன்பாட்டிற்காக வடிவமைக்கப்பட்டிருக்கும்போதோ Fedora-வைத் தேர்ந்தெடுக்கவும். பதிப்பை மாற்றாமல் பல வருடங்களுக்கு ஒரு server-ஐ patch செய்ய விரும்பினால், LTS அல்லது enterprise rebuild-ஐத் தேர்ந்தெடுக்கவும்.