מדריך מעבר מ-apt ל-dnf: פקודות מקבילות ב-Rocky ו-Fedora

התשובה הקצרה

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

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

אילו הפצות משתמשות ב-dnf ואילו ב-apt

dnf הוא מנהל החבילות ב-Fedora, ב-Red Hat Enterprise Linux (RHEL) ובגרסאות ה-rebuild של RHEL: Rocky Linux, AlmaLinux ו-CentOS Stream. apt הוא מנהל החבילות ב-Debian ובכל מה שנגזר מ-Debian, שבשרת VPS משמעותו כמעט תמיד Ubuntu. אין תשובה שלישית. אם רשימת התמונות של ספק השרתים שלכם מציעה את Rocky Linux או AlmaLinux, אתם מקבלים dnf. אם היא מציעה את Ubuntu, אתם מקבלים apt.

פורמט החבילות תואם לכלי העבודה. dnf מתקין קובצי .rpm ומסד הנתונים שלו הוא rpm. apt מתקין קובצי .deb ומסד הנתונים שלו הוא dpkg. זו הסיבה לכך שדפי התקנה של ספקים רבים כוללים לשונית נפרדת לכל משפחה, וזו הסיבה לכך שקובץ .deb שהורד מדף ה-release של פרויקט כלשהו אינו שמיש ב-Rocky Linux.

לא משנה באיזו משפחה בחרתם, ההתחברות הראשונה דורשת את אותה עבודה. עשר הדקות הראשונות ב-VPS חדש רלוונטיות לשתי המשפחות. רק פקודת ההתקנה משתנה.

כל פקודת apt והמקבילה שלה ב-dnf

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

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show היא dnf info. זהו הפועל היחיד ששמו שונה בקבוצה זו, אך התנהגות אחת שונה ועלולה להפתיע משתמשים. dnf remove מסירה גם תלויות ששום חבילה אחרת אינה זקוקה להן, בעוד ש-apt remove משאירה אותן מותקנות עבור apt autoremove עתידי. לכן, הסרה של כלי עזר קטן ב-Rocky Linux עלולה להוביל להסרה של תריסר ספריות יחד איתו. קראו את הרשימה לפני האישור.

רענון מטא-דאטה, בדיקת עדכונים ממתינים ושדרוג.

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

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

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

פרט אחד חשוב אם אתם כותבים סקריפטים: dnf check-update מסתיימת עם קוד יציאה 100 כאשר יש עדכונים ממתינים, ו-0 כאשר אין. apt list --upgradable מסתיימת עם 0 בכל מקרה, לכן סקריפטים חייבים לנתח את הפלט שלה.

הצגת רשימת החבילות המותקנות וזיהוי החבילה שאליה שייך קובץ מסוים.

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

השורה האחרונה בכל בלוק עונה על שאלה שונה מאלו שמעליה. dpkg -S ו-rpm -qf מחפשות רק בחבילות שכבר מותקנות, ולכן הן עונות על השאלה "מה הניח את הקובץ הזה כאן". apt-file search ו-dnf provides מחפשות במאגרים, ולכן הן עונות על השאלה "מה עלי להתקין כדי לקבל את הקובץ הזה". apt-file היא חבילה נפרדת ב-Ubuntu ודורשת sudo apt-file update לפני ההרצה הראשונה. dnf provides אינה דורשת דבר נוסף, אם כי ההרצה הראשונה עלולה להיות איטית כיוון ש-dnf מורידה את רשימות הקבצים של המאגרים כדי לענות.

כדי להציג את הקבצים בתוך חבילה שטרם התקנתם, השתמשו ב-dnf repoquery -l nginx. בצד של apt זוהי apt-file list nginx.

הסרה אוטומטית, ניקוי המטמון ונעילת גרסה.

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock אינה מותקנת כברירת מחדל ב-Rocky Linux או ב-AlmaLinux, לכן השורה הראשונה מביניהן תיכשל עם No such command: versionlock במערכת חדשה. התקינו אותה תחילה עם sudo dnf install python3-dnf-plugin-versionlock. apt אינה זקוקה לדבר נוסף עבור apt-mark hold, כיוון שנעילה היא מצב של dpkg ולא תוסף.

היכן המיפוי נכשל: הוספת מאגר (repository)

זהו החלק שגורם למנהלי מערכות Ubuntu לחפש פקודה שאינה קיימת. לא קיימת פקודה בשם add-apt-repository ב-dnf, ואין מושג של Personal Package Archives (PPAs). שירות PPA מופעל על ידי Launchpad, שהיא תשתית של Ubuntu. בעולם ה-RPM אין שירות מארח מקביל.

במקום זאת, ל-dnf יש קובץ טקסט פשוט לכל מאגר בתוך /etc/yum.repos.d/, המסתיים בסיומת .repo.

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever ו-$basearch הם משתנים של dnf. המערכת מציבה את מספר הגרסה המרכזי ואת ארכיטקטורת המעבד בזמן הריצה, כך שאותו קובץ עובד גם בגרסה 9 וגם בגרסה 10, וגם ב-x86_64 וגם ב-aarch64.

רוב הספקים מפרסמים את הקובץ הזה ומנחים להוריד אותו. ההוראות של Docker עבור RHEL והפצות מבוססות RHEL מסתכמות בשתי פקודות:

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

השורה הראשונה נחוצה כיוון ש-config-manager הוא תוסף (plugin), ולא חלק מ-dnf עצמו. אם תדלגו עליה, השורה השנייה תיכשל עם השגיאה No such command: config-manager. שום דבר לא מונע מכם להוריד את אותו קובץ .repo באמצעות curl ישירות לתוך /etc/yum.repos.d/ באופן ידני; התוצאה תהיה זהה. המדריך התקנת Docker על שרת VPS מפרט את התהליך המקביל ב-Debian, שם השלב המקביל כותב רשימת מקורות ומפתח חתימה לשתי ספריות שונות.

ההבדל במבנה קובע היכן עליכם לחפש כאשר מאגר אינו מתפקד כראוי. apt שומרת הגדרות ב-/etc/apt/sources.list וב-/etc/apt/sources.list.d/, כאשר מפתחות חתימה מוחזקים בנפרד תחת /etc/apt/keyrings/. dnf שומרת הכל ב-/etc/yum.repos.d/, והמפתח הוא כתובת URL בתוך קובץ ה-.repo, כך שיש קובץ אחד לקרוא וקובץ אחד למחוק. גרסאות חדשות של apt עברו למבנה דומה עם פורמט deb822, המשתמש בקובץ .sources אחד לכל מאגר. אם נתקלתם ב-שגיאת המקורות הכפולים בפורמט deb822 ב-Ubuntu, כבר פגשתם את הצד של apt בבעיה זו.

EPEL הוא המאגר שרוב המדריכים מניחים שקיים

Extra Packages for Enterprise Linux (EPEL) הוא פרויקט של Fedora המייצר חבילות Fedora עבור RHEL והפצות המבוססות עליו. זהו הדבר הקרוב ביותר שיש בעולם הזה ל-PPA אוניברסלי, ומספר רב מאוד של מדריכים מניחים שהוא כבר מופעל. אם dnf install משיב No match for argument עבור חבילה שניתן לראות באתר של הפרויקט עצמו, EPEL הוא הדבר הראשון שיש לבדוק.

ב-Rocky Linux וב-AlmaLinux:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB הוא CodeReady Builder, מאגר של ספריות שמגיע עם ההפצה אך אינו מופעל כברירת מחדל. רוב חבילות EPEL תלויות במשהו שנמצא בו, לכן הפעלת EPEL ללא CRB לא תיכשל באותו רגע. היא תיכשל מאוחר יותר, בזמן ההתקנה, עם תלויות שלא נפתרו בחבילה שמעולם לא שמעתם עליה. הפעילו את CRB תחילה וסוג זה של שגיאות ייעלם.

ב-RHEL עצמה, CRB מגיע דרך המנוי שלכם ולא דרך config-manager, לכן עקבו אחר הוראות ה-EPEL של Red Hat עבור שלב זה. Fedora אינה זקוקה לכל זה, כיוון שהמאגר הראשי שלה כבר מכיל את מה ש-EPEL מבצעת לו backport. המדיניות של EPEL היא לעולם לא להחליף חבילה ש-RHEL מספקת, לכן הוספת המאגר אינה משנה דבר שכבר מותקן בשרת שלכם.

dnf history undo, היכולת שחסרה ב-apt

dnf מתעד כל טרנזקציה, והוא מסוגל לבנות את הפעולה ההפוכה לה.

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

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

ליכולת זו יש מגבלות ממשיות, וכדאי להכיר אותן לפני שמסתמכים עליה. undo יכול להתקין מחדש גרסת חבילה רק אם היא עדיין קיימת במאגר (repository) פעיל; ברגע שהגרסה הישנה הוסרה מה-mirror, פעולת ה-undo תיכשל עם שגיאת not-found. ה-rollback עוצר ברמת מסד הנתונים של החבילות. קובץ תצורה ששוכתב במהלך השדרוג יישאר במצבו החדש, וסכימת מסד נתונים ששירות ביצע לה מיגרציה בעלייה הראשונה תישאר במצבה המעודכן. dnf מחזיר את הקבצים למקומם, אך הוא אינו משחזר את הנתונים שלכם.

ל-apt אין יכולת מקבילה. /var/log/apt/history.log מתעד בדיוק מה קרה, כולל שורת הפקודה, אך קריאת לוג אינה שקולה לביטול פעולה. השחזור בצד של apt הוא ידני: יש להריץ את apt list -a nginx כדי לראות אילו גרסאות עדיין קיימות בארכיון, לאחר מכן להשתמש ב-sudo apt install nginx=<exact version string> כדי לקבע (pin) גרסה מסוימת, ולהוסיף את sudo apt-mark hold nginx כדי שהשדרוג הבא לא יבטל את התיקון שלכם.

לקבוצות חבילות אין שווה ערך ב-apt

הפקודה dnf מאפשרת להתקין קבוצה מוגדרת של חבילות בפקודה אחת.

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

מדריכים ישנים משתמשים ב-dnf groupinstall "Development Tools". כינוי זה עובד ב-dnf 4 אך הוסר ב-dnf 5, לכן הכתיב הדו-מילתי dnf group install הוא היחיד שעובד בכל הגרסאות. השתמשו בו והפסיקו לחשוב על כך.

ל-apt אין קבוצות. הרעיון הקרוב ביותר ב-Debian הוא metapackage, חבילה ריקה שכל תוכנה הוא רשימת תלויות, כגון build-essential. ההבדל המעשי בא לידי ביטוי בעת הסרה: הסרת metapackage משאירה את התלויות מותקנות עד להרצת apt autoremove, בעוד ש-dnf group remove מסירה את חבילות הקבוצה באותה פעולה.

unattended-upgrades ו-dnf-automatic

שתי המשפחות מציעות דרך להתקנת עדכונים ללא צורך במשתמש מחובר. הכלים אינם חולקים דבר מלבד המטרה.

ב-Ubuntu וב-Debian החבילה היא unattended-upgrades, המוגדרת ב-/etc/apt/apt.conf.d/50unattended-upgrades, שם מפרטים את המקורות מהם מותר למשוך עדכונים. הגדרת unattended upgrades ב-Ubuntu מכסה את קובץ התצורה הזה ואת שאלת האתחול (reboot) הנלווית אליו.

ב-Rocky Linux, ב-AlmaLinux וב-Fedora החבילה היא dnf-automatic, והתנהגות המערכת נקבעת לפי ה-systemd timer שתפעילו.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

dnf-automatic-install.timer מוריד ומחיל עדכונים. dnf-automatic-download.timer מוריד אותם ועוצר, ומותיר את ההתקנה לשיקולכם. dnf-automatic-notifyonly.timer רק מדווח. כל אחת מיחידות אלו דורסת את הגדרת ה-apply_updates ב-/etc/dnf/automatic.conf, לכן ל-timer שתבחרו יש חשיבות רבה יותר ממה שכתוב בקובץ התצורה.

כדי להגביל את הפעולה לתיקוני אבטחה בלבד, הגדירו את upgrade_type = security ב-/etc/dnf/automatic.conf. מסנן זה תלוי בכך שהמאגרים (repositories) שלכם מפרסמים security errata, לכן בדקו זאת תחילה באמצעות dnf updateinfo list security. תוצאה ריקה במכונה שבה ממתינים עדכונים משמעותה שהמטא-דאטה אינו קיים, ו-security לא יתקין דבר במקרה כזה.

ב-Fedora, הגרסה dnf 5 שינתה את שם היחידה. היא נקראת dnf5-automatic.timer, והיא קוראת את אותו /etc/dnf/automatic.conf.

האם yum הוא עדיין פקודה ממשית?

כן, אך כשלעצמה היא אינה מבצעת דבר. ב-Rocky Linux, ב-AlmaLinux וב-CentOS Stream, הפקודה /usr/bin/yum היא קישור סימבולי המצביע על dnf. בדקו את המערכת שלכם:

ls -l /usr/bin/yum
dnf --version

תחביר yum ישן ממשיך להופיע במדריכים מכיוון שרוב הפקודות עדיין מועברות ישירות. הפקודות yum install, yum remove ו-yum update כולן עובדות. כדאי לזנוח הרגל אחד: yum-config-manager עדיין קיים כקובץ בינארי עצמאי במערכות dnf 4, אך dnf config-manager הוא הכתיב שבו משתמשת התיעוד העדכני, והוא הכתיב שימשיך לעבוד כאשר השרת ישודרג ל-dnf 5.

dnf 4 ו־dnf 5: בדקו לפני העתקת פקודה

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

ההדגמה הברורה ביותר מגיעה מ־Docker, שמפרסמת פקודת repository שונה עבור כל גרסה. ב־RHEL ובהפצות המבוססות עליה, עם dnf 4:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

ב־Fedora, עם dnf 5:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

אותו ספק, אותה משימה, מילים שונות. dnf 5 הפך את config-manager לכלי מבוסס תת-פקודות, לכן ה־flag הישן --add-repo אינו מתקבל ותקבלו שגיאת שימוש במקום הגדרת repository. פקודה נוספת שתפגשו היא הפעלת repository: הפקודה dnf config-manager --set-enabled crb ב־dnf 4 הופכת ל־dnf config-manager setopt crb.enabled=1 ב־dnf 5.

הבחירה שבאמת משנה

בחירת הפצת שרת על בסיס מנהל החבילות בלבד היא גישה שגויה. dnf ו-apt מבצעים את אותה עבודה, ואת אוצר המילים שלהם ניתן ללמוד בתוך אחר צהריים אחד. מה שישפיע על השנה שלכם הוא מודל ה-release שעומד מאחורי המאגרים. Fedora מתקדמת במהירות, וכל גרסה מפסיקה לקבל עדכונים בערך שלושה עשר חודשים לאחר הופעתה; זה מתאים לתחנת עבודה, אך מעיק עבור שרת שאינכם רוצים לבנות מחדש. Rocky Linux ו-AlmaLinux עוקבות אחר RHEL, כך שאתם מקבלים חלון תמיכה של עשר שנים וגרסאות חבילות שנשארות יציבות במכוון. Ubuntu מציעה את שני המודלים, ו-ההבדל בין Ubuntu LTS לבין גרסאות ביניים בשרת הוא אותה החלטה שמתקבלת בתוך עולם ה-apt.

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

FAQ

מהו המקביל ב-dnf לפקודה apt update?

אין פקודה שחובה להריץ. dnf בודק את גיל המטא-דאטה השמור במטמון לפני כל פעולה, ומוריד עותק חדש אם פג תוקפו. לכן, dnf install על שרת שלא נגעתם בו חודש עדיין יציג חבילות עדכניות. הפקודה sudo dnf makecache קיימת ומאלצת הורדה כזו, אך השימוש האמיתי שלה הוא העברת העיכוב לזמן שתבחרו, במקום שיקרה בזמן ההתקנה הבאה. הפקודה שעונה על השאלה "מה מחכה לי" היא dnf check-update, שממופה ל-apt list --upgradable ומסתיימת עם סטטוס 100 כאשר קיימים עדכונים.

האם קיים מקביל ל-PPA ב-Rocky Linux או ב-Fedora?

לא. ארכיוני חבילות אישיים (PPA) הם שירות של Launchpad, ו-Launchpad הוא תשתית של Ubuntu, לכן ל-add-apt-repository אין מקביל. המקביל ב-RPM הוא קובץ .repo בתוך /etc/yum.repos.d/ המכיל שם, baseurl ו-gpgkey. ספקים מפרסמים את הקובץ הזה עבורכם, ו-sudo dnf config-manager --add-repo <url> ב-dnf 4, או sudo dnf config-manager addrepo --from-repofile <url> ב-dnf 5, מורידים אותו למקומו. עבור תוכנות נוספות כלליות, התשובה היא בדרך כלל EPEL, שאותו מפעילים עם sudo dnf config-manager --set-enabled crb ולאחריו sudo dnf install epel-release.

האם ניתן לבטל שדרוג dnf שגרם לתקלה בשרת?

כן, בתוך מגבלות מסוימות. הריצו את sudo dnf history כדי למצוא את מספר הטרנזקציה, את sudo dnf history info <id> כדי לראות בדיוק מה השתנה, ולאחר מכן את sudo dnf history undo <id>. הביטול ייכשל אם גרסת החבילה הישנה אינה קיימת יותר באף מאגר פעיל, כיוון של-dnf אין מאיפה להתקין אותה מחדש. הפעולה הופכת רק שינויים בחבילות. קובץ תצורה שנכתב מחדש על ידי השדרוג, או מסד נתונים שעבר מיגרציה על ידי שירות בהפעלה הראשונה, יישארו כפי שהם. ל-apt אין פקודה מקבילה כלל, אלא רק תיעוד ב-/var/log/apt/history.log.

האם yum עדיין עובד ב-Rocky Linux וב-AlmaLinux?

הוא עובד מכיוון ש-/usr/bin/yum הוא קישור סימבולי ל-dnf. אשרו זאת במערכת שלכם עם ls -l /usr/bin/yum. הקלדת yum install httpd מריצה את dnf, כך שמדריכים ישנים ברובם עדיין מתפקדים. כתבו סקריפטים ותיעוד חדשים עם dnf, מכיוון שהשם yum נועד לתאימות בלבד, והעדיפו את dnf config-manager על פני הבינארי הישן yum-config-manager.

מדוע dnf remove רוצה למחוק כל כך הרבה חבילות?

מכיוון ש-dnf מסיר תלויות ששום דבר אחר לא זקוק להן כחלק מאותה טרנזקציה, בעוד ש-apt remove משאיר אותן מותקנות עד שתריצו apt autoremove בנפרד. לכן, הסרה שנראית קטנה ב-Ubuntu יכולה להדפיס רשימה ארוכה ב-Rocky Linux. הרשימה בדרך כלל נכונה, אך קראו אותה לפני האישור. אם מופיעה בה חבילה שברצונכם לשמור, התקינו אותה במפורש תחילה כדי ש-dnf ירשום אותה כחבילה מבוקשת בזכות עצמה.