Cockpit מול Webmin: מה כדאי להתקין על שרת Ubuntu?

Cockpit מול Webmin: התשובה הקצרה

Cockpit ו־Webmin הם שניהם ממשקי ניהול מבוססי דפדפן לשרתי Linux, והם נותנים מענה לצרכים שונים. Cockpit מופץ במאגרים הרשמיים של ההפצה שלכם וקורא את נתוני המכונה דרך systemd, journald, polkit ו־udisks; לכן, הוא מציג שרת שאתם ממשיכים לנהל באמצעות SSH. Webmin הוא כלי ותיק ורחב הרבה יותר: הוא כותב קובצי תצורה עבור Apache, BIND, Postfix, MariaDB ועשרות שירותים אחרים ש־Cockpit אינו נוגע בהם, והוא מריץ שרת אינטרנט משלו כ-root כדי לבצע זאת.

התקינו את Cockpit כאשר אתם זקוקים לתצוגה חיה של שרת בודד, לקורא לוגים ולמסוף חירום. התקינו את Webmin כאשר אתם זקוקים לעורך מבוסס טפסים עבור שירות שאינכם מעוניינים להגדיר ידנית. אל תחשפו אף אחד מהם לפורט ציבורי עם התחברות באמצעות סיסמה. אם אתם מנהלים כבר יותר משניים או שלושה שרתים, התשובה הכנה היא לרוב אף אחד מהם; הגישה של SSH בשילוב עם Ansible ניתנת להרחבה בצורה טובה יותר מכל ממשק ניהול.

מה כל לוח בקרה יכול לשנות בפועל

ההתקנה הבסיסית של Cockpit קטנה, ורוב האזורים הם חבילות נפרדות שניתן להשמיט:

• שירותי systemd וטיימרים: הפעלה, עצירה, הגדרה לעלייה אוטומטית וקריאת קובץ ה-unit.
• ה-journal, עם סינון לפי יחידה ועדיפות, שהוא journalctl עם בורר תאריכים.
• חשבונות מקומיים, חברות בקבוצות ומפתחות SSH מורשים.
• אחסון עם cockpit-storaged: מחיצות, קבוצות כרכים של LVM, מערכות קבצים ונקודות עיגון (mount points).
• מכולות עם cockpit-podman, המנהל את Podman בלבד.
• עדכוני חבילות עם cockpit-packagekit.
• גרפים של CPU, זיכרון, דיסק ורשת עם cockpit-pcp.
• מסוף root בתוך לשונית הדפדפן.

שני אזורים נראים שבורים ב-VPS מבוסס Ubuntu, אך אינם כאלה. דף הרשת של Cockpit הוא ממשק קדמי עבור NetworkManager, בעוד שתמונות השרת של Ubuntu משתמשות ב-netplan עם systemd-networkd, לכן הדף חסר או ריק. אל תתקינו את NetworkManager על שרת מרוחק כדי להחזיר אותו, כיוון שהוא משתלט על הממשק וטעות שם תעלה לכם גם בניתוק ה-SSH. בקרות ה-firewall של Cockpit הן ממשק קדמי עבור firewalld, בעוד ש-Ubuntu משתמשת ב-ufw, לכן לא תקבלו בקרות firewall כלל. המשיכו להריץ sudo ufw status בתוך מסוף.

Webmin מכסה שטח נרחב הרבה יותר, כיוון שהוא אוסף של מודולים לכל שירות ולא תוכנה אחת:

• תצורה של Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL ו-Samba באמצעות טפסים.
• משתמשים, קבוצות ומכסות דיסק.
• משימות cron ושעון המערכת.
• עדכוני חבילות, בתוספת מנהל קבצים עם אפשרות העלאה והורדה.
• ממשקים קדמיים ל-firewall, כולל אחד עבור iptables ואחד עבור firewalld.
• גיבויים של קובצי תצורה, ומודולי אשכול (cluster) שמפיצים שינוי אחד לשרתי Webmin אחרים.

Webmin עורך את הקבצים האמיתיים תחת /etc. אין מסד נתונים נסתר מאחורי הטפסים, לכן אם /etc נמצא בניהול גרסאות, sudo git -C /etc diff לאחר שמירת טופס מציג בדיוק את מה שהמודול כתב. זו הדרך המהירה ביותר ללמוד מה כל דף ב-Webmin עושה בפועל. מדריך ההתקנה והכניסה הראשונה ל-Webmin עובר על עץ המודולים בפירוט. Virtualmin ו-Usermin הם מוצרים נפרדים הבנויים על אותו מנוע, עבור אחסון שיתופי ועבור משתמשי קצה, והם יורשים את כל מה שנאמר כאן לגבי חשיפה.

כיצד מתבצע אימות בכל אחד מהם

ל-Cockpit אין מסד נתוני משתמשים משלו. דף ההתחברות שלו מריץ את מחסנית ה-PAM (pluggable authentication modules) ב-/etc/pam.d/cockpit, לכן החשבונות הם חשבונות ה-Unix שלכם והסיסמאות הן סיסמאות ה-Unix שלכם. הגישה ל-root נחסמת כברירת מחדל מכיוון ש-/etc/cockpit/disallowed-users כולל אותו ברשימה. פעולות הדורשות הרשאות מבוצעות דרך polkit, והממשק יבקש מכם את הסיסמה שוב לפני ביצוע כל שינוי; זו הסיבה לכך שבראש הדף עשויה להופיע הכותרת "Limited access" עד לביצוע הסלמת הרשאות.

לתכנון זה יש השלכה אחת שנתקלים בה בשרתים מוקשחים. אם פעלתם לפי התחברות SSH מבוססת מפתח בלבד עם השבתת אימות סיסמה, ייתכן שלחשבון אין סיסמה שמישה כלל, ולכן ההתחברות ל-Cockpit תידחה בעוד ש-ssh ימשיך לעבוד. בדקו זאת בשרת:

sudo passwd -S deploy

פלט המתחיל ב-deploy L מציין שהסיסמה נעולה, לכן ל-PAM אין מה לקבל ואף סיסמה שתקלידו לא תעבוד. P מציין שמוגדרת סיסמה שמישה. דף ההתחברות של Cockpit אינו מקבל מפתחות SSH. מפתחות משמשים רק כאשר Cockpit מתחבר מהמכונה שאליה נכנסתם למארח אחר.

Webmin מנהל משתמשים משלו ב-/etc/webmin/miniserv.users, בנפרד מ-/etc/passwd, וניתן גם להגדיר אותו לבצע אימות מול חשבונות Unix. משתמש Webmin שקיבל גישה לכל המודולים הוא root במכונה זו, ללא קשר למה שמוגדר כ-login shell שלו. Webmin כולל תמיכה מובנית ב-TOTP (סיסמה חד-פעמית מבוססת זמן) וחסימת מארחים לאחר ניסיונות התחברות כושלים חוזרים, שניהם מופעלים בתוך Webmin Configuration. Cockpit מקבל גורם אימות שני רק אם תוסיפו אחד ל-PAM, למשל באמצעות libpam-google-authenticator.

כיצד מתבצע עדכון לכל אחד מהם

Cockpit מופץ כחלק מהחבילות של ההפצה שלכם. ב-Ubuntu 24.04 הוא מגיע ממאגרי ברירת המחדל, אך פרויקט המקור ממליץ להשתמש ב-backports לקבלת גרסה עדכנית יותר:

. /etc/os-release
sudo apt update
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl status cockpit.socket
apt policy cockpit

apt policy מציג את הגרסה המותקנת ואת המאגר שממנו הגיעה. אם ב-backports אין גרסה חדשה יותר, apt יחזור להשתמש בגרסה מהמאגר הראשי, וזה תקין. cockpit.socket אמור להציג active (listening). תיקוני אבטחה יגיעו לאחר מכן באמצעות אותה פקודת unattended-upgrades שבה אתם מעדכנים את ה-kernel, ממקור שאתם כבר נותנים בו אמון.

Webmin אינו נמצא במאגרים של Ubuntu. תהליך ההתקנה הרשמי מוסיף תחילה את המאגר של Webmin ואת מפתח החתימה שלו:

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh
sudo apt-get install webmin --install-recommends

קראו את הסקריפט לפני הרצתו, שכן הוא פועל בהרשאות root. מרגע זה ואילך, כל פקודת apt upgrade בשרת תמשוך עדכונים גם מהמאגר של Webmin; בכך הוספתם מפיץ שני עם הרשאות root מלאות על המכונה. זהו המחיר האמיתי של Webmin, וראוי להמחיש זאת בדוגמה פשוטה: CVE-2019-15107 היה דלת אחורית (backdoor) במספר חבילות מסדרת 1.9x שאפשרה הרצת פקודות ללא אימות. הפרצה הגיעה למשתמשים כיוון ששרת הבנייה של הפרויקט נפרץ, ולא מאגר קוד המקור עצמו. אריזה על ידי מפיצי ההפצה אינה הופכת אירוע כזה לבלתי אפשרי, אך היא מוסיפה שלב של בנייה ובקרה שאינכם נדרשים לתחזק בעצמכם.

מדוע אין להשאיר אף אחד מהם על פורט ציבורי

Cockpit מאזין ב-TCP 9090 ו-Webmin ב-TCP 10000, שניהם מעל TLS (אבטחת שכבת תעבורה) עם תעודה בחתימה עצמית, לכן הדבר הראשון שרואים הוא אזהרת דפדפן. יצירה ואמון בתעודה בחתימה עצמית מסביר מה אזהרה זו אומרת ומה לא. שני הפורטים נסרקים ללא הרף, ושני הממשקים מובילים ל-root, כך שסיסמה שנוחשה או שנעשה בה שימוש חוזר משמעותה פריצה מלאה לשרת.

הדפוס הבטוח הוא לקשור את הממשק ל-localhost ולגשת אליו דרך מנהרת SSH. עבור Cockpit, יש לבצע override ליחידת ה-socket:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

ה-ListenStream= הריק בשורה נפרדת הוא הכרחי. systemd משרשר הגדרות רשימה, לכן בלעדיו היחידה תשמור על ה-0.0.0.0:9090 המקורי ותוסיף את הכתובת החדשה, והממשק שלכם עדיין יהיה ציבורי. החילו את ה-override ובדקו מה מאזין:

sudo systemctl daemon-reload
sudo systemctl restart cockpit.socket
sudo ss -lntp | grep 9090

הפלט חייב להציג 127.0.0.1:9090. כתובת של *:9090 או 0.0.0.0:9090 משמעותה שה-override לא נכנס לתוקף. כעת פתחו את המנהרה מהמחשב שלכם וגלו ל-https://localhost:9090:

ssh -N -L 9090:127.0.0.1:9090 deploy@203.0.113.10

שמרו על פורט מקומי זהה לפורט המרוחק. Cockpit משווה את ה-header מסוג Origin של הדפדפן לכתובת שהוא מניח שהוא משרת, לכן מנהרה מפורט מקומי 9999 תטען את דף ההתחברות אך תיכשל בשלב הכניסה, ו-journalctl -u cockpit יתעד את ה-origin שנדחה. אם אתם זקוקים לפורט מקומי שונה, ציינו אותו ב-/etc/cockpit/cockpit.conf:

[WebService]
Origins = https://localhost:9999 https://127.0.0.1:9999

בצעו restart עם sudo systemctl restart cockpit.socket כדי להחיל את השינוי. עבור Webmin ההגדרה המקבילה נמצאת ב-/etc/webmin/miniserv.conf:

bind=127.0.0.1

sudo systemctl restart webmin
sudo ss -lntp | grep 10000
ssh -N -L 10000:127.0.0.1:10000 deploy@203.0.113.10

Webmin גם בודק את ה-header מסוג Referer בבקשות POST ומסרב לבקשות שנראות כאילו הגיעו ממארח אחר, וזה מה שגורם לכשל בניסיון ראשון מול reverse proxy. השורה referers= באותו קובץ היא המקום שבו מאפשרים את שם המארח של ה-proxy, ו-webprefix= הוא המקום שבו מציינים ל-Webmin שהוא חי תחת נתיב מסוים.

reverse proxy מאומת הוא האפשרות השנייה: nginx בחזית, עם שכבת הזדהות אחודה של Authentik שמבצעת את הכניסה. זה עובד, וזו האפשרות השנייה בטיבה. הממשק עדיין רץ כ-root מאחורי ה-proxy, וכעת אתם מתחזקים שתי דלתות כניסה במקום אחת. מנהרה אינה מוסיפה שירות מאזין לאינטרנט כלל, והיא עושה שימוש חוזר ב-SSH key שאתם כבר מאבטחים.

באיזה לוח ניהול לבחור עבור שרת שמריץ שירותי Production

הבחירה היא Cockpit, משתי סיבות קריטיות כאשר אנשים אחרים תלויים במכונה. הוא מופעל באמצעות socket, לכן cockpit-ws רץ רק בזמן שסשן פתוח, ואין daemon קבוע של root שממתין בפורט. בנוסף, הוא אינו משתלט על דבר: הסרת החבילה משאירה כל שירות פועל בדיוק כפי שהיה, כיוון ש-Cockpit אינו שומר הגדרות משלו. ה-miniserv.pl של Webmin נשאר בזיכרון בין אם מישהו מחובר ובין אם לא. בדקו את צריכת המשאבים שלכם בעזרת systemctl status webmin, שמציג את הזיכרון התפוס על ידי התהליך הרץ.

אם אתם זקוקים למודולי ה-DNS או ה-mail של Webmin, הקצו להם שרת נפרד. שרת Webmin שמבצע תפקיד אחד בלבד, ומוגבל ל-127.0.0.1, הוא סיכון מבודד. שרת Webmin שחולק מארח עם יישום שפונה ללקוחות הוא סיכון שאין לקחת. בצעו את עבודת התשתית לפני התקנת כל לוח ניהול: עשר הדקות הראשונות ב-VPS חדש מכסה את הגדרת משתמש ה-non-root וה-firewall, ששני הלוחות מניחים שכבר קיימים.

כאשר התשובה היא אף אחת מהאפשרויות

לוח בקרה הוא כלי ידני המוגבל לשרת בודד, והוא אינו משאיר תיעוד של השינויים שבוצעו או הסיבות להם. זה עשוי להספיק עבור שרת אחד. בחמישה שרתים אתם חוזרים על אותן פעולות, ובעשרים שרתים אתם כבר מנחשים איזה שרת לא עודכן. Cockpit מאפשר להוסיף מארחים נוספים לסשן אחד באמצעות SSH, אך גרסאות עדכניות משביתות אפשרות זו כברירת מחדל ומחייבות הגדרת AllowMultiHost=yes בתוך /etc/cockpit/cockpit.conf, וגם אז, עדיין תצטרכו לבצע את אותה לחיצה חמש פעמים.

החלופה היא שימוש ב-SSH רגיל עם התצורה שלכם שמורה במאגר git. המדריך ניהול מספר שרתי Linux ממקום אחד סוקר את המבנה של הגדרה כזו, והמדריך ה-Ansible playbook הראשון שלכם מדגים כיצד להחיל את אותו חוק firewall על כל מארח מקובץ אחד שניתן לבחון כ-diff. עבודה עם מכולות מתבצעת באותו אופן: הרצת docker compose up -d דרך SSH מקובץ ב-git, כפי שמוסבר ב-מדריך היסודות של Docker Compose, עדיפה על פני לחיצות ידניות בכל לוח בקרה, מה גם ש-Cockpit אינו מנהל את Docker מלכתחילה.

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

מצבי כשל והודעות שתיתקל בהן

Cockpit דוחה סיסמה ש-SSH מקבל. החשבון מוגדר לשימוש במפתחות בלבד. sudo passwd -S alice מדפיס L בשדה השני, לכן ל-PAM אין סיסמה לבדיקה. הגדר סיסמה באמצעות sudo passwd alice, או השתמש בחשבון זה עבור SSH בלבד והתחבר ל-Cockpit כמשתמש אחר.

Cockpit מסרב לאפשר כניסת root גם עם סיסמה נכונה. /etc/cockpit/disallowed-users מציג את root. התחבר כמשתמש רגיל בעל הרשאות sudo. זהו אופן הפעולה המתוכנן, כיוון ש-polkit מתעד כך איזה משתמש ביצע את העלאת ההרשאות.

Cockpit לא מציג דפי Networking או Firewall. דפים אלו דורשים את NetworkManager ואת firewalld. שרת VPS מבוסס Ubuntu מריץ netplan עם systemd-networkd ו-ufw, לכן הדפים אינם מופיעים. אין כאן תקלה, והפתרון הוא להמשיך להשתמש ב-ufw דרך SSH.

דף הכניסה של Cockpit נטען דרך ה-tunnel, אך הכניסה נכשלת. הפורט המקומי שלך שונה מהפורט המרוחק, לכן בדיקת Origin נכשלת ו-journalctl -u cockpit מציג זאת. התאם את הפורטים, או הגדר את Origins בתוך /etc/cockpit/cockpit.conf.

שליחת טפסים ב-Webmin נכשלת לאחר העברתו מאחורי proxy. בדיקת Referer דוחה אותם. הוסף את שם המארח של ה-proxy ל-referers= בתוך /etc/webmin/miniserv.conf, והגדר את webprefix= כאשר הפאנל מוגש תחת נתיב (path) מסוים.

אינך בטוח אם פאנל מסוים חשוף. sudo ss -lntp | grep -E '9090|10000' מספק תשובה לכך מתוך השרת עצמו, ו-Webmin כותב כל ניסיון התחברות ל-/var/webmin/miniserv.log, קובץ שכדאי לעיין בו פעם אחת לאחר כל שינוי באופן ההאזנה של השירות.

FAQ

האם עדיף להשתמש ב-Cockpit או ב-Webmin עבור שרת Ubuntu VPS בודד?

עבור רוב המשתמשים, Cockpit עדיף מכיוון שהוא מגיע ממאגרי התוכנה הרשמיים של Ubuntu, מתעדכן יחד עם שאר המערכת, ורץ רק כאשר יש סשן דפדפן פעיל. בחרו ב-Webmin כאשר אתם זקוקים לעורך מבוסס טפסים עבור שירות ש-Cockpit אינו תומך בו, כגון BIND או Postfix, וקחו בחשבון ששרת האינטרנט שלו רץ כ-root בכל עת ועדכוניו מגיעים ממאגר התוכנה של Webmin עצמו.

האם ניתן להריץ את Cockpit ו-Webmin על אותו שרת?

כן. הם משתמשים בפורטים שונים, 9090 ו-10000, ולכן אינם מתנגשים, שכן כל אחד מהם עורך את המערכת ישירות במקום "להשתלט" עליה. עם זאת, זו פשרה לא מומלצת. כל לוח בקרה מהווה נקודת כניסה נפרדת עם הרשאות root על אותה מכונה, כך שאתם מכפילים את שטח החשיפה רק כדי לחסוך כמה לחיצות. אם התקנתם את שניהם, הגדירו את שניהם להאזין ל-127.0.0.1 וגשו אליהם דרך מנהרת SSH.

האם בטוח לפתוח את פורט 9090 או 10000 לאינטרנט?

לא עם התחברות באמצעות סיסמה. שני הלוחות מובילים להרשאות root, ושני הפורטים מזוהים על ידי סריקות שגרתיות תוך שעות מרגע פתיחתם. הגדירו את לוח הבקרה להאזין ל-127.0.0.1, לאחר מכן הריצו את ssh -N -L 9090:127.0.0.1:9090 user@host וגשו ל-https://localhost:9090. אשרו את החיבור באמצעות sudo ss -lntp | grep 9090, אשר חייב להציג 127.0.0.1:9090 ולא 0.0.0.0:9090. שימוש ב-reverse proxy עם אימות הוא אפשרות שנייה קבילה.

מדוע ההתחברות ל-Cockpit נכשלת למרות ש-SSH עם מפתח עובד?

Cockpit מבצע אימות דרך PAM באמצעות סיסמת Unix, ודף ההתחברות שלו אינו מקבל מפתחות SSH. בשרת מאובטח, לעיתים קרובות לחשבון אין סיסמה שמישה. הריצו את sudo passwd -S youruser: סימן L בשדה השני מציין שהסיסמה נעולה, לכן ל-PAM אין מה לקבל וכל ניסיון נדחה. הגדירו סיסמה באמצעות sudo passwd youruser, או השתמשו בחשבון אחר עבור לוח הבקרה.

האם Cockpit מנהל מכולות Docker?

לא. דף המכולות ב-Cockpit מגיע מ-cockpit-podman ומנהל את Podman. המודול הישן של Docker הוסר לפני שנים ולא יחזור. אם השירותים שלכם רצים תחת Docker, נהלו אותם באמצעות קובץ compose בניהול גרסאות דרך SSH, ותנו ל-Cockpit לנהל את המערכת סביבם, כגון ה-journal והדיסקים.