תחזוקת שרת 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

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

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

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

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

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

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

מאגרים של צד שלישי הם הגורם לכשל בשדרוג

החבילות הרשמיות של 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 יוריד את המטא-דאטה ויסיים את פעולתו בשקט. אם לא, תקבלו שגיאת 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, אין לכם דרך נתמכת לבצע תיקון (patch).

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

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

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: חומרה עדכנית, או מחסנית container ו-systemd שעדיין רחוקה שנה מהפצה ארגונית. Fedora גם עוברת ל-kernels חדשים מה-upstream במהלך מחזור החיים של גרסה, כך שזה לא יתרון חד-פעמי רק בזמן ההתקנה.
• אתם מוודאים מה עומד להגיע ל-RHEL (Red Hat Enterprise Linux). Fedora מזינה את CentOS Stream, שמזינה את RHEL, לכן תוכנה שנבנית ורצה על Fedora היום נבדקת מול הפלטפורמה הארגונית של השנתיים הקרובות.
• המכונה מיועדת לחיים קצרים. מריץ build או שרת בדיקות שמושמד בעוד חודשיים לעולם לא יגיע לתאריך סוף החיים שלו. אותו היגיון תקף לגבי מכונות וירטואליות זמניות שאתם מוסרים לסוכני פיתוח, שבהן המכונה נבנית מחדש בתדירות גבוהה בהרבה מקצב השחרור של 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= מקבל יעד של גרסה אחת או שתיים קדימה, ודילוג על שתי גרסאות הוא בדיוק האופן שבו עובד קצב שדרוג שנתי. מעבר לכך אינו נתיב נתמך, וכל גרסה נוספת מעלה את הסיכוי ששינוי בשם חבילה או בפורמט תצורה יעצור את התהליך. אם מכונה נמצאת בפיגור של כמה גרסאות וכבר עברה את סוף חייה, התקנה מחדש על גבי אימג' עדכני היא בדרך כלל מהירה יותר משרשרת שדרוגים.

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

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

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

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