תחזוקת שרת Fedora: כמה זמן נמשך מחזור החיים?

למשך כמה זמן מקבלת גרסה של Fedora עדכוני אבטחה?

שרת Fedora דורש שדרוג גרסה בערך פעם בשנה, כל עוד המכונה קיימת. Fedora מפרסמת גרסה חדשה בערך בכל שישה חודשים. כל גרסה נתמכת עד כארבעה שבועות לאחר השקת הגרסה שמופיעה שני דורות אחריה, מה שמסתכם בכ-13 חודשי עדכונים. לאחר תאריך זה, הגרסה אינה מקבלת עוד תיקוני אבטחה כלל. המכונה ממשיכה לפעול, אך עם סט חבילות שאף אחד כבר לא מתחזק.

התאריכים הופכים זאת למוחשי. נכון לאוגוסט 2026, הגרסאות הנתמכות הן Fedora 43 ו-Fedora 44. גרסת Fedora 44 שוחררה ב-28 באפריל 2026, וסוף חייה מתוכנן ליוני 2027. גרסת Fedora 42 שוחררה באפריל 2025 והגיעה לסוף חייה במאי 2026, ארבעה שבועות לאחר הגעת Fedora 44. שרת שהוקם מ-image של 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. הנתון של Debian, העומד על 36 חודשים, הוא התמיכה הביטחונית הרגילה שלה, כאשר צוות LTS נפרד מאריך את רוב הגרסאות לכחמש שנים.

אלו הם חלונות התמיכה הרשמיים, כפי שנבדקו באוגוסט 2026, ולא מדדי זמן פעילות (uptime). הסיבות להבדלים בקצב העדכונים מפורטות ב-ההבדל בין Ubuntu LTS לגרסאות ביניים בשרת. מה שחשוב כאן הוא כמות העבודה שכל אחת מהן מייצרת עבורכם.

מה כולל בפועל שדרוג גרסה ב-Fedora

החל מ-Fedora 41, מנהל החבילות המוגדר כברירת מחדל הוא DNF 5, ו-dnf מריץ אותו. הפקודה system-upgrade היא חלק מ-dnf5 עצמו, לכן אין צורך להתקין תוסף מראש. אם אתם מגיעים מסביבת Debian או Ubuntu, לרוב הפעולות היומיומיות שלכם יש מקבילה ישירה מ-apt ל-dnf, אך שדרוג הגרסה להלן הוא אחת הפעולות הבודדות שאין להן מקבילה אמיתית. התחילו מהגרסה הנוכחית, כשהיא מעודכנת במלואה:

sudo dnf upgrade --refresh
sudo reboot

ה-reboot חשוב מכיוון שהשדרוג מתבצע מול מה שמותקן ורץ כרגע; עדכון kernel או glibc שלא הוחל במלואו מקשה על ניתוח תקינות השלב הבא. כעת, הכינו את הגרסה החדשה. החליפו את 44 בגרסה שאליה אתם עוברים:

sudo dnf system-upgrade download --releasever=44

פעולה זו פותרת את כל הטרנזקציה ומורידה את כל החבילות, מבלי לשנות דבר במערכת הפעילה. צפו לאלפי חבילות ולנפח של גיגה-בייט אחד עד שלושה בשרת קטן. אם dnf לא מצליח לפתור את הטרנזקציה, הוא עוצר כאן ומציין את החבילה שחסמה אותו. זהו תרחיש חיובי, כיוון שהכשל קורה בזמן שהמכונה עדיין פעילה ויש לכם גישה ל-shell.

לאחר מכן, הריצו את הפקודה:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status מאשר שטרנזקציה מוכנה וממתינה. dnf system-upgrade reboot מבצע אתחול של המכונה לתוך טרנזקציה לא מקוונת (offline): אתחול מינימלי שבו טרנזקציית ה-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 מדפיסה את לוג הטרנזקציה מאותו אתחול לא מקוון, וזהו התיעוד היחיד למה שקרה בזמן שלא הייתה לכם גישה ל-shell. distro-sync מעדכנת כל מה שנותר לגרסאות של המהדורה החדשה. repoquery --extras מציגה חבילות מותקנות שכבר אינן נמצאות באף מאגר פעיל; שם תמצאו שאריות ממאגר שלא פורסם עבור הגרסה החדשה.

בצעו snapshot לדיסק לפני שלב ההורדה. הטרנזקציה רצה בזמן שאינכם יכולים לראות את המסך, לכן אם היא נכשלת במהלך האתחול הלא מקוון, ה-SSH לא יחזור והדרך היחידה שלכם להיכנס היא דרך קונסולה שהספק מספק, כגון VNC או serial. ודאו שיש לכם קונסולה או snapshot לפני שאתם מתחילים, לא אחרי.

בדיקה נוספת שאנשים נוטים לדלג עליה:

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

כאשר חבילה מפיצה קובץ תצורה חדש כברירת מחדל ואתם ערכתם את הקובץ הישן, RPM לא ידרוס את הקובץ שלכם. הוא שומר את הגרסה מהחבילה לצד הקובץ שלכם כ-.rpmnew. לכן, ה-sshd או ה-nginx שלכם ימשיכו להתנהג בדיוק כפי שהתנהגו בגרסה הישנה, בעוד ברירות המחדל החדשות נשארות ללא קריאה על הדיסק. קראו את הקבצים הללו לאחר כל שדרוג. התקנת rpmconf והרצת sudo rpmconf -a תעבור עליהם אחד אחד ותציג לכם את ההבדלים.

מאגרי צד-שלישי הם הגורם לתקלות בשדרוג

החבילות הרשמיות של Fedora מתעדכנות כולן יחד ביום השחרור. כל רכיב שמגיע מחוץ ל-Fedora מתעדכן לפי לוח זמנים של גורם אחר. רוב מאגרי הספקים כוללים את $releasever בכתובת ה-URL שלהם, ולכן ברגע שתבצעו שדרוג, dnf יתחיל לבקש נתיב שייתכן שעדיין אינו קיים.

הציגו את המאגרים המותקנים אצלכם:

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 עבור נתיב כמו 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) מוסרות מרשת ה-mirrors אל הארכיון, ולכן dnf upgrade נכשל בעת משיכת המטא-דאטה, עם שגיאת 404 בכתובת ה-metalink של הגרסה שלכם:

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

המכונה ממשיכה לשרת תעבורה, וזה מה שהופך את המצב לשקט ומסוכן. היא אינה מקבלת עדכוני אבטחה. כמו כן, לא ניתן להתקין דבר, כך שביום שבו מתפרסמת התרעת אבטחה עבור OpenSSH או nginx, אין לכם דרך נתמכת לבצע תיקון.

יציאה מהמצב הזה אפשרית אך איטית. ניתן להפנות מחדש את המאגרים (repositories) לארכיון של Fedora בכתובת https://dl.fedoraproject.org/pub/archive/fedora/linux/ ולבצע שדרוג משם. Fedora מצפה לדילוג של גרסה אחת או שתיים בכל פעם, כך ששרת שמפגר בארבע גרסאות דורש כמה שלבי שדרוג רצופים, כשבכל אחד מהם קיים סיכוי לכשל, וכל אחד מהם מתבצע ללא תמיכה ובמצב לא מקוון. ב-VPS, בנייה מחדש על גבי image עדכני והעברת הנתונים היא בדרך כלל המשימה הקצרה והבטוחה יותר, והיא דורשת את אותה עבודה כמו עשר הדקות הראשונות ב-VPS חדש.

עדכונים אוטומטיים מתקינים תיקוני אבטחה וגרסה (patch) עבור מהדורה קיימת. הם לעולם אינם מבצעים שדרוג גרסה (upgrade).

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.

תהליך זה שומר על המערכת מעודכנת בתוך אותה מהדורה. הוא לעולם לא יעביר את Fedora 43 ל-Fedora 44, כיוון ששדרוג גרסה הוא פעולה נפרדת ומכוונת הדורשת אתחול לתוך טרנזקציה לא מקוונת (offline). זהו ההבדל המעשי בהשוואה להפצות LTS. ב-Ubuntu, עדכוני אבטחה לא מנוטרים מאפשרים למכונה להישאר מעודכנת לאורך כל חלון הזמן של חמש שנים ללא שינוי גרסה כלל, כאשר שדרוג הגרסה עצמו הוא משימה מתוכננת כמו השדרוג מ-24.04 ל-26.04 המתרחש אחת לכמה שנים.

מתי Fedora היא הבחירה הנכונה לשרת

Fedora היא בחירה טובה כאשר העדכניות היא העיקר.

• אתם זקוקים לליבה (kernel) או ל-userspace חדשים יותר מכל גרסת LTS: חומרה חדישה, או מחסנית (stack) של container ו-systemd שעדיין רחוקה שנה מגרסה ארגונית. Fedora עוברת לליבות upstream חדשות גם במהלך מחזור החיים של גרסה, כך שזהו אינו יתרון חד-פעמי בעת ההתקנה בלבד.
• אתם מוודאים מה עומד להיכנס ל-RHEL (Red Hat Enterprise Linux). Fedora מזינה את CentOS Stream, שמזינה את RHEL, לכן תוכנה שנבנית ורצה על Fedora היום נבדקת מול הפלטפורמה הארגונית של עוד שנתיים-שלוש.
• המכונה מיועדת לחיים קצרים מטבעה. מריץ בנייה (build runner) או שרת בדיקות שמושמד בעוד חודשיים לעולם לא יגיע לתאריך סוף החיים שלו. אותו היגיון תקף לגבי מכונות וירטואליות זמניות שאתם מוסרים לסוכני תכנות, שבהן המכונה נבנית מחדש בתדירות גבוהה בהרבה מקצב השחרור של Fedora.
• מישהו אחראי על השדרוג. Fedora מתאימה לשרת שיש לו בעלים מוגדרים ורישום ביומן. היא אינה מתאימה לשרת שכולם שכחו מקיומו.

דרך האמצע: חבילות עדכניות על בסיס יציב

רוב האנשים שרוצים Fedora על שרת זקוקים לשתיים או שלוש חבילות עדכניות, ולא למערכת הפעלה עדכנית. ניתן להפריד ביניהן. הריצו הפצת LTS או גרסה מבוססת Enterprise כבסיס, ואז משכו את התוכנה החדשה רק היכן שאתם באמת זקוקים לה. תמונת מכולה (container image) מספקת לכם את הגרסה החדשה של היישום על מארח שלעולם לא תצטרכו לשדרג עבורו (הרצת Docker על גבי VPS). מאגר ספק (vendor repository) עבור החבילה הבודדת שחשובה לכם, כמו PostgreSQL או nginx, מקדם את אותו רכיב בלבד ומותיר את הבסיס ללא שינוי.

הפשרה הוגנת בשני הכיוונים. מכולה מעניקה לכם מרחב משתמש (userspace) חדש על גבי הליבה הישנה של המארח, לכן היא לא תעזור כאשר הליבה היא הרכיב שאתם צריכים לעדכן. מאגר ספק מספק לכם חבילה אחת חדשה על בסיס שהספק בדק פחות. שתי הדרכים מותירות את עדכוני האבטחה של מערכת הבסיס על לוח הזמנים של ה-LTS, ולוח זמנים זה הוא החלק שדורש מכם חלון תחזוקה פעם בשנה ב-Fedora.

אם בחרתם בכל זאת ב-Fedora עבור שרת, קבעו את המחזור ביומן. כאשר גרסה חדשה משתחררת, המתינו מספר שבועות עד שמאגרי הספקים יתעדכנו, בצעו snapshot, שדרגו, ולאחר מכן ודאו שהשירותים חזרו לפעול. קצב זה דורש כשעה בשנה והוא עובד. הגרסה שנכשלת היא זו שבה נזכרים בשדרוג רק לאחר שמשהו כבר התקלקל.

FAQ

לכמה זמן נתמכת גרסה של Fedora?

כ-13 חודשים. Fedora מפרסמת גרסה חדשה בערך כל שישה חודשים ותומכת בכל גרסה עד כארבעה שבועות לאחר השקת הגרסה השנייה שאחריה. Fedora 44 שוחררה ב-28 באפריל 2026, וסוף חייה מתוכנן ליוני 2027. לאחר תאריך זה, הגרסה מפסיקה לקבל עדכוני אבטחה והחבילות שלה מוסרות מהמראות (mirrors) אל הארכיון של Fedora.

האם ניתן לדלג על גרסה של Fedora ולשדרג שתי גרסאות בבת אחת?

כן, במידה מסוימת. dnf system-upgrade download --releasever= מקבל יעד של גרסה אחת או שתיים קדימה, ודילוג על שתי גרסאות הוא בדיוק האופן שבו עובד קצב שדרוג של פעם בשנה. מעבר לכך זהו אינו נתיב נתמך, וכל גרסה נוספת מעלה את הסיכוי ששינוי בשם של חבילה או בפורמט של קובץ תצורה יעצור את התהליך. אם המכונה כבר נמצאת כמה גרסאות מאחור ועברה את תאריך סוף החיים שלה, בדרך כלל מהיר יותר להתקין מחדש על גבי image עדכני מאשר לבצע שרשרת של שדרוגים.

מה קורה אם שרת ה-Fedora שלי הגיע לסוף חייו?

הוא ימשיך לפעול אך יפסיק לקבל עדכונים. הפקודה dnf upgrade הבאה תיכשל עם שגיאת 404 בכתובת ה-metalink של הגרסה שלך, כיוון שגרסאות שהגיעו לסוף חייהן מועברות לארכיון ב-dl.fedoraproject.org. ניתן להפנות מחדש את קובצי ה-repository לאותו ארכיון ולבצע שדרוגים בשלבים, או להתקין את השרת מחדש על גרסה נתמכת. עד שלא תבצע אחת משתי פעולות אלו, לא יגיעו למכונה עדכוני אבטחה ולא ניתן יהיה להתקין חבילות חדשות.

האם Fedora היא בחירה גרועה עבור שרת בייצור (production)?

זוהי ברירת מחדל גרועה, אך בחירה סבירה אם יש לכך סיבה מוצדקת. המחיר הוא שדרוג מלא של מערכת ההפעלה בכל שנה, לנצח, במכונה שאולי היית מעדיף לא לגעת בה. בחר ב-Fedora כאשר אתה זקוק ל-kernel או ל-userspace חדשים יותר מאלו שמציעות גרסאות LTS, או כאשר השרת מיועד לחיים קצרים מטבעו. בחר ב-LTS או בגרסה ארגונית (enterprise rebuild) כאשר ברצונך לתחזק שרת במשך שנים ללא שינוי גרסה.