Ubuntu LTS לעומת גרסאות ביניים: מה עדיף לשרת?

Ubuntu LTS לעומת גרסאות ביניים: התשובה הקצרה

הבחירה בין Ubuntu LTS לבין גרסת ביניים (interim release) בשרת מסתכמת במספר אחד: משך הזמן שבו הגרסה מקבלת עדכוני אבטחה. גרסת LTS מקבלת חמש שנים של תחזוקת אבטחה סטנדרטית. גרסת ביניים מקבלת תשעה חודשים, ולאחר מכן העדכונים נפסקים, כך שחובה לשדרג או לבנות את השרת מחדש. הריצו LTS על כל שירות שאנשים אחרים תלויים בו. הריצו גרסת ביניים רק במקומות שבהם בנייה מחדש היא פעולה שניתן לבצע ללא צורך באישור מאף אחד.

LTS משמעותו תמיכה לטווח ארוך (Long Term Support). חברת Canonical מפרסמת גרסת LTS אחת בכל שנתיים, באפריל של שנים זוגיות, וגרסת ביניים אחת בכל שישה חודשים בפרקי הזמן שביניהן. הגרסה 26.04 LTS שוחררה ב-23 באפריל 2026, ותחזוקת האבטחה הסטנדרטית שלה נמשכת עד שנת 2031. הגרסה 26.10 צפויה לצאת ב-15 באוקטובר 2026, והיא גרסת ביניים, לכן התמיכה בה מסתיימת ביולי 2027.

משך התמיכה בכל גרסת Ubuntu

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

אלו הם נתוני המדיניות הרשמיים של Canonical נכון לאוגוסט 2026, ולא מדידות משרת בדיקה. גרסת LTS כוללת 60 חודשים של תחזוקת אבטחה סטנדרטית, מה שמתרגם ל-1 שדרוגי גרסה מתוכננים בפרק זמן של חמש שנים. גרסת ביניים (interim release) כוללת 9 חודשים. הישארות במסלול גרסאות הביניים לאורך אותן חמש שנים מחייבת 10 שדרוגי גרסה, כיוון שלא ניתן לדלג על גרסה ובחמש שנים יוצאות עשר גרסאות כאלו.

מנוי Ubuntu Pro מעלה את נתון ה-LTS ל-120 חודשים, שהם עשר שנים, ומרחיב את הכיסוי מרכיב ה-main לכל הארכיון. נכון לאוגוסט 2026, Pro ניתן בחינם לשימוש אישי עבור עד חמישה מחשבים, מה שמכסה את רוב ציי ה-VPS הקטנים. אין מקבילה לכך בגרסאות ביניים. תשעה חודשים הם כל מה שמוצע, ושום מנוי לא מאריך זאת.

מה המשמעות של תשעה חודשים בשרת אמיתי

ניקח את 26.10 כדוגמה לעבודה. הגרסה משתחררת ב-15 באוקטובר 2026 ותחזוקת האבטחה שלה מסתיימת ביולי 2027, באותו דפוס של תשעה חודשים שסיים את 25.10 ביולי 2026. בקריאה יומנית, זה נראה כמו חלון תחזוקה אחד בכל שלושה רבעונים. הקריאה היומנית הזו שגויה, והיא שגויה בכיוון היקר.

שדרוג גרסה מחליף את מערכת ההפעלה במקומה. do-release-upgrade משכתב את מקורות ה-apt, משבית מאגרים של צד שלישי, משנה את הגרסה של כמעט כל חבילה מותקנת, עוצר כדי לשאול על קובצי תצורה שערכתם, ומבצע reboot בסיום. זו הסיבה שמדובר בחלון מתוכנן ולא במשימת רקע.

מריצים זאת דרך ssh והכלי מגן עליכם מניתוק החיבור שלכם. הוא מתחיל סשן screen משלו ופותח sshd שני, תוך שהוא מודיע לכם על כך מראש:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

אפשרו לו. אם ה-firewall שלכם או ה-firewall הרשתי הנפרד של ספק התשתית חוסם את 1022, מנגנון הגיבוי הזה לא קיים, וחיבור שמתנתק משאיר אתכם עם סט חבילות ששודרג חלקית. הרצה בתוך tmux או screen בעצמכם מעניקה לכם את אותה הגנה בכל שרת.

ההנחיות לגבי קובצי תצורה הן מה שהופך שדרוג של חמש-עשרה דקות לשעה:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

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

כעת הכפילו זאת במספר השרתים. VPS אחד במסלול הביניים הוא עשרה חלונות שדרוג בחמש שנים. חמישה שרתי VPS הם חמישים, אלא אם כל שרת הוא חד-פעמי ונבנה מחדש מתוך image. חמישה שרתים במסלול LTS הם חמישה שדרוגים באותה תקופה, ואתם בוחרים את החודש שבו כל אחד מהם יתרחש.

מדוע לא ניתן לדלג על גרסת Ubuntu

נתיבי השדרוג קבועים. גרסת ביניים משתדרגת לגרסה הבאה אחריה, תהיה אשר תהיה. גרסת LTS משתדרגת ישירות לגרסת ה-LTS הבאה, או לגרסת הביניים הבאה אם תבקשו זאת. שום דבר לא משתדרג בשני שלבים בבת אחת. מעבר מ-26.10 ל-28.04 LTS מחייב מעבר דרך 27.04 ו-27.10, או התקנה מחדש של המכונה.

כדאי להכיר את המנגנון, כיוון שהוא מבהיר שהכלל אינו גמיש. do-release-upgrade מושך קובץ meta-release מ-changelogs.ubuntu.com, ולאחר מכן מוריד כלי שדרוג שנבנה עבור מעבר ספציפי אחד. Canonical בונה ובודקת מעבר אחד בכל פעם, לכן קפיצה שמדלגת על גרסה אינה נתמכת על ידי כלי או בדיקות. כלי השדרוג אינו מסרב מתוך זהירות; פשוט אין לו מה להציע.

הגרסה שתוצע לכם נקבעת על ידי שורת הגדרה אחת:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts מציע רק את גרסת ה-LTS הבאה. Prompt=normal מציע את הגרסה הבאה, בין אם היא LTS ובין אם לא. Prompt=never אינו מציע דבר, וזו הדרך למנוע מעמית לעבודה להתחיל שדרוג שלא תכננתם. בגרסה שאינה LTS, lts מתנהג בדיוק כמו normal, כיוון שהגרסה הבאה אחרי 26.10 היא 27.04 בשתי ההגדרות. הבדיקה מדפיסה Checking for a new Ubuntu release ולאחריה שורת New release ... available. או No new release found..

כלל תזמון נוסף מפתיע משתמשים רבים. שדרוג מ-LTS ל-LTS אינו מוצע ביום שבו גרסת ה-LTS החדשה משתחררת. הוא נפתח עם גרסת ה-point release הראשונה, ו-26.04.1 מתוכננת ל-27 באוגוסט 2026. גרסת point release אינה גרסה חדשה של Ubuntu אלא אותה גרסה עם ארבעה חודשים של תיקונים מצטברים המשולבים במדיה להתקנה חדשה, וההמתנה קיימת כדי שנתיב השדרוג יקבל את ארבעת חודשי הבדיקות הללו לפני שהוא מוצע למישהו. מכונת 24.04 עם Prompt=lts שהשיבה No new release found. לאורך קיץ 2026 לא הייתה תקולה. היא פשוט פעלה לפי המדיניות. כשהנתיב נפתח, השדרוג מ-24.04 ל-26.04 LTS הוא התהליך שיש לתכנן ולתרגל.

מתי גרסת ביניים היא הבחירה הנכונה

ארבעה מקרים שבהם היא באמת עדיפה:

• אתם זקוקים לגרסת kernel או userspace שאינה קיימת במאגר ה-LTS, על השרת הזה, עכשיו.
• המכונה היא שרת build, מריץ CI או סביבת בדיקות שאתם בונים מחדש מתוך image, כך ששדרוג הוא למעשה יצירת מופע חדש במקום חלון תחזוקה.
• תכונה של חומרה או hypervisor הושקה לאחר הקפאת ה-LTS, ולא קיים עבורה backport.
• אתם בודקים מה יכיל ה-LTS הבא. גרסת 28.04 מורכבת מ-26.10, 27.04 ו-27.10, וגילוי שינוי שובר (breaking change) ב-VPS משני עולה פחות מאשר גילויו בשרת הקריטי.

רוב האנשים שבוחרים בגרסת ביניים מחפשים חבילה אחת חדשה יותר, לא הפצה חדשה יותר. קיימות שתי חלופות זולות יותר. ה-hardware enablement stack מביא kernels מגרסאות מאוחרות יותר לתוך ה-LTS: ב-24.04 מדובר ב-sudo apt install linux-generic-hwe-24.04, והוא מתעדכן בכל point release, החל מהשני. עבור יישום בודד, container image או מאגר רשמי של הספק מעדכנים רכיב אחד במקום את מערכת ההפעלה כולה.

מתי גרסת ביניים היא בחירה שגויה

• כל שירות שיש לו משתמשים משלמים או כוננות (on-call). אתם מקבלים על עצמכם שדרוג חובה פעמיים בשנה בתמורה לגרסאות חבילות שאולי לעולם לא תשתמשו בהן.
• כל שרת שבו unattended-upgrades מבצע עבורכם את עדכוני האבטחה. האוטומציה הזו טובה רק ככל שהמאגר (repository) שממנו היא מושכת את העדכונים טוב.
• צי שרתים שאתם משדרגים ידנית, כיוון שהעלות האמיתית היא חלון תחזוקה אחד כפול מספר השרתים.
• כל דבר שאתם מתקינים ולא מסתכלים עליו במשך שנה. גרסת ביניים ששכחתם ממנה היא שרת חשוף לאינטרנט ללא עדכונים כעבור תשעה חודשים.

הכשל האחרון הוא שקט, וזה מה שהופך אותו למסוכן. כאשר גרסה מגיעה לסוף חייה (EOL), החבילות שלה עוברות ל-old-releases.ubuntu.com, ולכן sudo apt update מתחיל להיכשל מול archive.ubuntu.com עם שגיאות 404. רשימות החבילות בדיסק הופכות למיושנות. unattended-upgrades ממשיך לרוץ לפי הטיימר שלו וממשיך לכתוב שורות כאלה לתוך /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

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

סוג השינויים שמגיעים תחילה למסלול ה-interim

במרץ 2026 הציע מהנדס של Canonical, בפורום הדיונים של Ubuntu, להסיר את ה-bootloader החתום מסוג GRUB שמגיע כחלק מ-secure boot בגרסה 26.10. ההצעה מסירה את מנהלי ההתקן (drivers) עבור מערכות הקבצים btrfs, hfsplus, xfs ו-zfs, את מנתחי התמונה (parsers) מסוג JPEG ו-PNG, את טבלאות המחיצות של Apple, את /boot על גבי LVM, את ה-software RAID למעט RAID 1, ואת ה-/boot המוצפן ב-LUKS. הסיבה המוצהרת היא שמנתחים בתוך ה-bootloader הם מקור חוזר לפרצות אבטחה, וכי הלוגיקה של האחסון וההצפנה צריכה להימצא ב-initramfs, מערכת הקבצים הקטנה ב-RAM שה-kernel טוען לפני ה-root האמיתי. נכון לאוגוסט 2026, זו הצעה שנמצאת בדיון ולא שינוי שכבר שוחרר.

עבור רוב שרתי ה-VPS, הדבר לא ישנה דבר, כיוון שהם עולים ללא secure boot מתוך /boot פשוט מסוג ext4 על גבי טבלת מחיצות GPT. בדקו את השרת שלכם במקום להניח הנחות. אם ה-root שלכם הוא ZFS, או שה-/boot נמצא על btrfs או בתוך LUKS, זה בדיוק סוג השינוי שתפגשו ראשונים במסלול ה-interim. העצה שניתנה באותו שרשור למשתמשים המושפעים היא להישאר בגרסת LTS. עצה זו מסכמת את הטיעון כולו במשפט אחד. גרסאות interim הן המקום שבו בוחנים שינויים. גרסת LTS היא המקום שבו הם מגיעים לאחר ששנתיים של גרסאות interim חשפו מה הם עלולים לשבור.

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

בחירת ערוץ ההפצה בעת הקמת השרת

בחרו את ערוץ ההפצה (track) בזמן ההתקנה, שכן שינוי שלו לאחר מכן מחייב התקנה מחדש או שרשרת של שדרוגים. בשרת חדש, ארבע פקודות יבהירו לכם היכן אתם עומדים:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a אמור להציג את שם הגרסה שהתכוונתם להתקין, ובגרסת LTS שורת התיאור מסתיימת ב-LTS. השורה Prompt צריכה להתאים לערוץ שבחרתם, ולא לגרסה המקרית שהגיעה עם ה-image של ספק השרתים. do-release-upgrade -c בגרסת LTS עדכנית אמור להחזיר No new release found.. אם המערכת מציעה לכם גרסת ביניים (interim release), סימן ש-Prompt מוגדר כ-normal, ומישהו צריך להחליט אם זה נעשה במכוון. pro security-status מדווח כמה מהחבילות המותקנות מכוסות על ידי איזה ערוץ עדכונים, ומציין בבירור מתי המכונה אינה מחוברת למנוי.

לאחר מכן, רשמו את תאריך סוף התמיכה (end of life) במקום שבו תראו אותו שוב, לצד שאר הערות הבנייה של אותו שרת. מידע זה שייך לשאר הפעולות ב-עשר הדקות הראשונות ב-VPS חדש, כיוון שתאריך תמיכה שקיים רק בזיכרון של מישהו הוא התאריך שיחלוף מבלי שאיש ישים לב. אם אתם מנסים להימנע לחלוטין מהשינויים התכופים של כל שישה חודשים, כדאי להקדיש שעה לקריאה על מודל השחרורים של FreeBSD בהשוואה ל-Linux לפני שתחליטו על פריסת צי שרתים באחת מהן.

FAQ

האם כדאי להריץ גרסת ביניים (interim release) של Ubuntu על שרת ייצור?

ברוב המוחלט של המקרים, לא. גרסת ביניים מפסיקה לקבל עדכוני אבטחה תשעה חודשים לאחר השקתה, כך שסביבת ייצור במסלול זה מחייבת חלון שדרוג פעמיים בשנה, לנצח. החריגים היחידים הם מכונות שאתם ממילא בונים מחדש מתוך image, כמו CI runners או מארחי build, שבהם שדרוג הוא למעשה יצירת instance חדש ולא חלון תחזוקה. אם משתמשים אמיתיים תלויים בשרת, התקינו גרסת LTS והשקיעו את הזמן שנחסך במשימות אחרות.

לכמה זמן נתמכת גרסת ביניים של Ubuntu?

תשעה חודשים. גרסה 26.10 מושקת ב־15 באוקטובר 2026 ותחזוקת האבטחה שלה מסתיימת ביולי 2027, באותו דפוס שבו הסתיימה 25.10 ביולי 2026. כל גרסת ביניים פועלת כך: השקה באפריל או באוקטובר, וסיום תשעה חודשים לאחר מכן. גרסת LTS מקבלת חמש שנים של תחזוקת אבטחה סטנדרטית, שניתן להרחיב לעשר שנים באמצעות Ubuntu Pro, אשר נכון לאוגוסט 2026 זמין בחינם לשימוש אישי עבור עד חמש מכונות.

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

לא. do-release-upgrade מתבצע צעד אחר צעד: גרסת ביניים עוברת לגרסה הבאה אחריה, וגרסת LTS יכולה לעבור ישירות ל־LTS הבאה. מעבר מ־26.10 ל־28.04 LTS מחייב הרצת שדרוג דרך 27.04 ו־27.10 תחילה, או התקנה מחדש של המכונה. Canonical בונה ובודקת מעבר אחד בכל פעם, וכלי השדרוג מוריד כלי עבודה ספציפי לאותו דילוג, לכן אין כלי זמין לדילוג של שני שלבים והדבר אינו מוצע למשתמש.

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

החבילות שלה עוברות ל-old-releases.ubuntu.com, לכן sudo apt update מתחיל להיכשל מול archive.ubuntu.com עם שגיאות 404, ולא מתפרסמים יותר עדכוני אבטחה חדשים עבור אותה גרסה. שום דבר במכונה לא מתריע על כך. השרת ממשיך לרוץ ולהעביר תעבורה, בעוד כל פגיעות חדשה שמתפרסמת נותרת פתוחה במערכת. התאוששות מחייבת שדרוג גרסה תחת לחץ זמן, או בנייה מחדש, לכן עקבו אחר התאריכים במקום לחכות להופעת תסמינים.

האם ה-kernel של גרסת LTS ישן מדי עבור חומרה חדשה?

בדרך כלל לא, כיוון שגרסת LTS לא שומרת על ה-kernel המקורי שלה במשך חמש שנים. מחסנית התאמת החומרה, HWE, מביאה kernels מגרסאות מאוחרות יותר אל תוך ה-LTS בנקודות השקה (point releases), והתקנת שרת יכולה להצטרף לכך באמצעות חבילה כמו linux-generic-hwe-24.04. בדקו מה אתם מריצים בעזרת uname -r לפני שאתם מניחים שה-kernel הוא החסם. אם הרכיב החסר הוא גרסת userspace ולא ה-kernel, שימוש ב-container או במאגר (repository) של הספק הוא שינוי קטן בהרבה מאשר העברת כל המכונה למסלול גרסאות הביניים.