Chapter 12: עדכונים, שדרוגים והגירות (Updates & Migration) - Asset A (Instructor Reference)¶
1. טרמינולוגיה ואסטרטגיה: עדכון (Update) מול שדרוג (Upgrade)¶
1. High-Level Theory & History¶
ההבחנה בין "עדכון" ל"שדרוג" במערכות ההפעלה של Apple עברה אבולוציה משמעותית לאורך השנים. היסטורית, עדכון (Update) התייחס לשינויי גרסה מינוריים או טלאי אבטחה בתוך אותה משפחת מערכות הפעלה (למשל, מעבר מ-macOS 13.1 ל-13.2), והתבצע באמצעות הורדת קבצי דלתא דרך מנגנון ה-Software Update. לעומת זאת, שדרוג (Upgrade) התייחס למעבר לדור חדש לחלוטין של המערכת (למשל, מ-macOS 13 Ventura ל-macOS 14 Sonoma), שחייב הורדה של אפליקציית התקנה מלאה (Install macOS.app) מתוך ה-Mac App Store. כיום, החוויה אוחדה ויזואלית עבור משתמש הקצה: גם עדכונים וגם שדרוגים מופיעים ומנוהלים מתוך System Settings -> General -> Software Update, מה שמספק תהליך חלק, רציף ואחיד יותר. עם זאת, מאחורי הקלעים הטיפול בהם שונה לחלוטין.
2. Deep Technical Architecture¶
הארכיטקטורה המודרנית של התקנת עדכונים ושדרוגים נשענת על מנגנון ה-SSV (Signed System Volume). כאשר מזוהה עדכון זמין, תהליך softwareupdated מוריד את חבילת העדכון או את קובץ ההתקנה המלא אל תיקיית staging מיוחדת (לרוב תחת /System/Volumes/Update/). משלב זה נכנס לפעולה שירות ה-UpdateBrainService, שאחראי על ביצוע השינויים מחוץ לסביבת ה-OS הפעילה. התהליך בונה Snapshot חדשה של מערכת ההפעלה, מטמיע לתוכה את הקבצים המעודכנים, ובסוף הפעולה חותם אותה קריפטוגרפית מול השרתים של Apple. תהליך זה מאפשר למערכת להמשיך לעבוד כרגיל תוך כדי הכנת העדכון ברקע, כשההשבתה היחידה היא זמן ה-Reboot, בו המערכת פשוט משנה את מצביע הבוט (Boot Pointer) לאתחל מה-Snapshot החדש והחתום. בשדרוגים (Upgrades), התהליך מורכב יותר ודורש החלפה מסיבית יותר של רכיבי מערכת הליבה, אך מנגנון ה-SSV מבטיח שכל תהליך שכזה יהיה אטומי (קורה בשלמותו או נכשל וחוזר למצב הקודם) וללא השחתת מערכת.
3. Terminal Commands, Plists & Logs¶
-
פקודות טרמינל (CLI): כלי ה-CLI המרכזי הוא
softwareupdate. רשימת העדכונים הזמינים:softwareupdate -lהתקנת כל העדכונים המומלצים:softwareupdate -i -aהורדה מפורשת של קובץ שדרוג מלא (למטרת יצירת דיסק התקנה):softwareupdate --fetch-full-installer --full-installer-version 14.0 -
Plists: העדפות מנגנון העדכונים שמורות בנתיב:
/Library/Preferences/com.apple.SoftwareUpdate.plist. כאן ניתן למצוא ערכים כמוAutomaticCheckEnabledו-AutomaticDownload. -
Logs: ניתן לקרוא את הלוגים של תהליך העדכון ההיסטורי בקובץ
/var/log/install.log, או לחקור בצורה חיה את תהליך ה-daemon באמצעות פקודת ULS:log show --predicate 'subsystem == "com.apple.SoftwareUpdate"' --info --debug
4. Edge Cases & Troubleshooting¶
בעיות בעדכונים נובעות לרוב מחוסר שטח דיסק זמין ב-Data Volume, שמונע מה-SSV לפרוס את ה-Snapshot החדש. במקרה כזה, הפעולה תיעצר והמערכת תתריע. תרחיש נוסף הוא תקלות רשת (כגון חסימות Proxy או חומת אש) שמונעות גישה לשרתי החתימה של Apple (gs.apple.com), מה שיגרום לעדכון להיכשל בטענה שלא ניתן לאמת (Personalize) את התקנת המערכת. במצבי קיצון שבהם המערכת "תקועה" ואינה מסוגלת להשלים עדכון, המעקף המומלץ הוא כניסה ל-macOS Recovery וביצוע Reinstall macOS - פעולה זו תוריד תמונת מערכת עדכנית ונקייה, תחתום אותה כראוי ותשאיר את נתוני המשתמש (Data Volume) ללא פגע.
2. מנגנון RSR: Rapid Security Responses לעדכוני אבטחה מיידיים¶
1. High-Level Theory & History¶
החל מ-macOS Ventura, Apple הציגה מנגנון מהפכני בשם Background Security Improvements, המוכר לרוב כ-Rapid Security Responses (RSR). המטרה הייתה לנתק את התלות בין עדכוני אבטחה דחופים (Zero-day vulnerabilities, פגיעויות ב-WebKit או בספארי) לבין מחזור העדכונים המלא והכבד של מערכת ההפעלה. במקום לדרוש מהמשתמש להוריד חבילה גדולה ולהמתין לזמן השבתה ממושך, מנגנון RSR מאפשר לדחוף טלאים מיקרוסקופיים שמתקינים את עצמם במהירות. עדכוני RSR יצוינו לרוב באמצעות הוספת אות בסוגריים לגרסת המערכת, למשל macOS 13.3.1 (a).
2. Deep Technical Architecture¶
העוצמה של מנגנון RSR מבוססת על שימוש בטכנולוגיית ה-Cryptex (Cryptographically Executable). ה-Cryptex היא למעשה תמונת דיסק קטנה, מאובטחת וחתומה שמוטענת (Mounted) מעל ל-System Volume הנעול. בגלל שה-SSV עצמו לא ניתן לשינוי, RSR "מלביש" על גביו את הקבצים המעודכנים (כמו ספריות WebKit מתוקנות) בשכבת Overlay. אם העדכון נוגע לאפליקציה כמו Safari בלבד, הפעלת העדכון דורשת בסך הכל יציאה מהאפליקציה (Quit) והפעלתה מחדש - ללא כל צורך ב-Reboot. במקרים בהם התיקון נוגע לספריות מערכת עמוקות יותר, נדרש אתחול (Reboot), אך מדובר באתחול מהיר משמעותית מעדכון מסורתי מאחר והמערכת לא נדרשת לבנות ולחתום SSV חדש, אלא פשוט לטעון את ה-Cryptex המעודכן בשלב מוקדם בשרשרת האתחול.
3. Terminal Commands, Plists & Logs¶
-
ממשק משתמש וטרמינל: ב-System Settings, תחת Privacy & Security -> Background Security Improvements, ניתן להגדיר התקנה אוטומטית של טלאי האבטחה הללו. נכון לעכשיו, שורת הפקודה הסטנדרטית של
softwareupdateמטפלת ב-RSR תחת מטריצת העדכונים הרגילה כדלתא מהירה, אך אינה חושפת מתגים (Flags) בלעדיים להורדת RSR בלבד בנפרד מעדכון זמין. -
Plists: הגדרות אלו נשמרות בהעדפות מערכת תחת ה-domain של תצורות האבטחה (לרוב מנוהל תחת פרופילי הרשאות של MDM הקשורים ל-Software Update).
-
הסרה וביטול: N/A ברמת CLI פשוטה, הדרך הנתמכת כיום לבטל RSR היא דרך הממשק הגרפי: לחיצה על כפתור ה-Info (i) ליד גרסת המערכת ובחירה ב-Remove and Restart.
4. Edge Cases & Troubleshooting¶
תרחיש הקצה המרכזי למנגנון ה-RSR הוא חוסר תאימות של טלאי האבטחה החדש עם מערכות תוכנה קיימות (למשל תוספי אבטחה ארגוניים צד-שלישי הקורסים כתוצאה משינוי בספריות הליבה). היתרון העצום של ארכיטקטורת ה-Cryptex הוא שניתן להסיר (Rollback) את ה-RSR באופן מיידי, ללא צורך לפרמט או לשחזר את ה-SSV המקורי מגיבוי. המשתמש (או תומך ה-IT) פשוט בוחר להסיר את עדכון האבטחה ב-System Settings, ולאחר אתחול קצר המערכת מפסיקה לטעון את ה-Cryptex וחוזרת לגרסת מערכת ההפעלה המקורית ללא שינוי.
3. Migration Assistant: איך להעביר פרופילים בלי לגרור בעיות (Best Practices)¶
1. High-Level Theory & History¶
ה-Migration Assistant הוא כלי הליבה של macOS להעברת מידע ממק ישן למק חדש, משחזור מ-Time Machine, או אפילו הגירה מ-Windows PC. מבחינה תפיסתית, המטרה של הכלי היא לאפשר למשתמש להתחיל לעבוד על המחשב החדש כשהכל נראה בדיוק כמו המחשב הקודם. עם זאת, בסביבה ארגונית, שימוש עיוור בכלי זה עלול לגרור את כל "חטאי העבר" – קבצי קונפיגורציה ישנים, הגדרות רשת שגויות, פרופילי MDM מתנגשים, והרחבות ליבה שאינן נתמכות. לכן, ההמלצה בארגונים היא לבחור סלקטיבית מה מהגרים (לרוב רק קבצי משתמש) או להימנע לחלוטין ולעבוד בתצורה מנוהלת ענן (OneDrive, iCloud).
2. Deep Technical Architecture¶
ברמת המערכת, Migration Assistant מחשב את שטחי האחסון הזמינים וממפה את עץ התיקיות (Data Volume). חשוב להדגיש: Migration Assistant מעולם לא מעתיק את מערכת ההפעלה (ה-SSV) עצמה; מערכת ההפעלה ביעד תמיד תישאר זו שהגיעה עם המחשב החדש (בתנאי שהיא בגרסה זהה או חדשה יותר מהמקור). במהלך ההעברה, הכלי מבצע מיפוי של ה-UIDs (User Identifiers). אם קיים משתמש עם שם זהה במק החדש (למשל 501), המערכת תשאל האם לדרוס את המשתמש או לשנות את שם החשבון המיובא. אם בוחרים להחליף, נתוני החשבון הישן יעברו לתיקיית Deleted Users. טכניקות ההעברה כוללות העברה דרך רשת אלחוטית ב-Ad-hoc, כבל רשת, או כבל Thunderbolt. במחשבי Mac מבוססי אינטל, ניתן היה להשתמש ב-Target Disk Mode המייצר שכבת בלוקים, אולם במחשבי Apple Silicon הוחלף המנגנון ב-Mac Sharing Mode המבוסס על פרוטוקול SMB ומחייב הזדהות (Authentication) קריפטוגרפית מצד שרת השיתוף ב-Recovery.
3. Terminal Commands, Plists & Logs¶
-
פקודות טרמינל (CLI): מניעת כניסת המחשב למצב שינה במהלך הגירה ארוכה (טרום כניסה לאפליקציה):
sudo systemsetup -setcomputersleep Never. -
Plists: אין רלוונטיות לעריכת Plists עבור הפעלה ראשונית, אך כלי ניהול (MDM) משתמשים בפרופילים בשלב ה-Setup Assistant כדי להסתיר או למנוע שימוש ב-Migration Assistant מטעמי אבטחה.
-
Logs: מעקב אחר תהליך ההגירה ושגיאות העתקה יכול להתבצע דרך
log show --predicate 'process == "Migration Assistant"'או בחקירת/var/log/system.log.
4. Edge Cases & Troubleshooting¶
תקלות נפוצות נובעות מתוכנות צד שלישי (Antivirus, Firewall או VPN) המותקנות במק המקור, החוסמות את תהליך ההידברות (Handshake) מול המק החדש ומונעות את הצגת קוד האימות בן ה-6 ספרות. הפתרון המהיר הוא להשבית זמנית תוכנות אלו. במקרים של הגירה ממעבדי אינטל ל-Apple Silicon, העברת תיקיית "Applications" עלולה לגרור גרסאות ישנות הדורשות Rosetta 2 ולקרוס או להאט את המחשב, כמו גם העברה של Kexts שאינם נתמכים בארכיטקטורת ARM64. בארגונים, ההמלצה היא תמיד לבצע הגירה חלקית (Data and Users בלבד) ולהתקין אפליקציות מחדש מנקודה נקייה.
4. תיבול ארגוני: איך כופים עדכונים עם Software Update Policies ומאפשרים למשתמש לדחות (Deferrals)¶
1. High-Level Theory & History¶
בעבר, מנהלי IT נהגו לנהל עדכונים באמצעות שרתי SUS (Software Update Server) מקומיים או כלים כמו Reposado כדי לסנן ולחסום הורדות. עם המעבר ל-Apple Silicon והארכיטקטורה המודרנית, חסימת גישה לשרתי Apple מונעת כליל את האפשרות לאמת את מערכת ההפעלה (Personalization). כתוצאה מכך, הגישה המודרנית מסתמכת על MDM כדי לאכוף מדיניות - התהליך מתבצע על ידי שימוש ב-Software Update Policies, השהיית עדכונים (Deferrals) ושליחת פקודות ספציפיות תוך הסתמכות על רשתות הפצה גלובאליות של אפל או שירות Content Caching מקומי לחיסכון ברוחב פס.
2. Deep Technical Architecture¶
המנגנון הארגוני נשען במידה רבה על ה-Declarative Device Management (DDM) וההכרזה מסוג com.apple.configuration.softwareupdate.enforcement.specific.
כאשר נשלחת למחשב מנוהל (MDM) מדיניות לעדכון, המערכת מאפשרת למנהלי ה-IT להגדיר גרסת יעד (TargetOSVersion או TargetBuildVersion) ותאריך ושעת יעד קשיחים (Target Date). ברגע שההגדרות מתקבלות ב-Mac, ה-OS מזהה את חלון הזמן ומציג התראות מקומיות מדורגות למשתמש כדי לעודד התקנה נוחה. לאחר פקיעת הדדליין, התקנת העדכון או השדרוג תבוצע בכפייה (Forced), מה שיגרום לסגירת אפליקציות וביצוע אתחול.
בנוסף למערכת האכיפה, פרופיל הניהול תומך בהשהיה (Deferrals). מנהל הרשת יכול להשהות חשיפה לעדכוני Minor או שדרוגי Major לתקופה של עד 90 יום ממועד שחרורם הציבורי של אפל. עד לפקיעת חלון ה-Deferral, העדכון החדש פשוט לא יופיע ב-System Settings של המשתמש. מנגנון הרקע (Background Security Improvements) שונה ואינו כפוף ישירות ל-Deferral בזמן, למרות שאם גרסת ה-Minor הרלוונטית מושהית, גם ה-RSR נחסם בפועל.
3. Terminal Commands, Plists & Logs¶
-
פקודות טרמינל (CLI): מנהל IT שמבצע טראבלשוטינג ללקוח תקוע יכול לנקות זמנית את זכרון ההשהיות:
softwareupdate --clear-deferrals(במידה ויש הרשאות מקומיות והפרופיל מאפשר זאת). כמו כן, כדי לראות איזה פקודות MDM הוזנו, ניתן להריץ:profiles show -type configuration. -
Plists: פרופילי האכיפה נשמרים כחלק ממבנה ה-Managed Preferences תחת ה-Domain של
com.apple.softwareupdate. -
Logs: לוגים ארגוניים לזיהוי בעיות DDM ועדכונים יימצאו על ידי ULS ב-Subsystem הרלוונטי או בחיפוש
managedclient.
4. Edge Cases & Troubleshooting¶
בעיות קלאסיות בארגון נוצרות כאשר פרופיל MDM דורש התקנה (Enforcement) אך המחשב הנייד אינו מחובר לחשמל (AC Power) או חסר בשטח אחסון מספק (Storage Space). במצבים אלו, למרות הכפייה, המערכת תסרב לפרוס את העדכון כהגנה מפני קריסה. בעיה נוספת נוצרת כאשר קיימות מספר הכרזות תלויות (לדוגמה, התקנת 14.1 עד תאריך X והתקנת 14.2 עד תאריך Y) - מערכת ההפעלה משקללת את היעדים ובוחרת בגרסה המוקדמת מבחינת תאריך היעד, וברגע שתעודכן מחדשת הערכה לגרסה הבאה. כמו כן, אם הרשת הארגונית חוסמת את התקשורת ל-swscan.apple.com או gs.apple.com, תהליכי הבדיקה והחתימה של מערכת ה-MDM ייכשלו ב"לופ".