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

התשובה הקצרה

המעבר מ-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. הסיבה לכך שצד אחד של הפיצול הזה נושא ארבעה שמות עבור מערכת שהיא ברובה זהה היא סיפור שכדאי להכיר לפני שבוחרים ביניהם, והמאמר כיצד הפכה Red Hat Linux ל-Fedora, RHEL, CentOS, Rocky ו-AlmaLinux מסביר את המקור של כל אחת מהן.

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

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

זהו החלק שגורם למנהלי מערכות Ubuntu לחפש פקודה שאינה קיימת. אין add-apt-repository ב-dnf, ואין דבר כזה Personal Package Archives (או PPAs). שירות PPA מופעל על ידי Launchpad, ו-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. ה-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 מכסה את קובץ התצורה הזה ואת שאלת האתחול הנלווית אליו.

ב-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. מסנן זה תלוי בכך שהמאגרים שלכם מפרסמים 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 לכלי מבוסס תת-פקודות, לכן הדגל הישן --add-repo אינו מתקבל ותקבלו שגיאת שימוש במקום מאגר. פקודה נוספת שתיתקלו בה היא הפעלת מאגר: dnf config-manager --set-enabled crb ב־dnf 4 הופכת ל־dnf config-manager setopt crb.enabled=1 ב־dnf 5.

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

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