درس ۶ از ۱۲

Package Management و Update

در مرحله «لینوکس برای کارشناس شبکه» حالا به Package Management و Update رسیده‌ایم؛ این موضوع را با مثال‌های واقعی باز می‌کنیم تا بدانی در Server Linux کجا با آن روبه‌رو می‌شوی و اگر درست کار نکرد، چه نشانه‌هایی برای ادامه عیب‌یابی ارزش دارند در این درس Linux را از دید یک پشتیبان شبکه بررسی می‌کنیم؛ لازم نیست همه جزئیات سیستم‌عامل را حفظ کنی، اما باید ساختار فایل‌ها، User و Permission، Serviceها، Network و Log را بشناسی؛ هدف این است که قبل از تغییر بدانی کدام Service و فایل درگیر است، از Log شواهد بگیری و تغییر را با حداقل دسترسی و امکان بازگشت انجام بدهی

این درس برای مطالعه کامل نوشته شده است

با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست

Package Manager نصب نرم‌افزار را مدیریت می‌کند

مدیر بسته وابستگی‌ها، Repository و نصب یا حذف نرم‌افزار را مدیریت می‌کند؛ قبل از حذف ببین چه Packageهای دیگری به آن وابسته‌اند به‌روزرسانی سیستم‌عامل فقط اضافه کردن قابلیت جدید نیست و بخشی از نگهداری امنیتی و پایداری سیستم محسوب می‌شود؛ Microsoft برای Windows سازوکارهای جداگانه‌ای برای Quality Update، Feature Update و Driver Update دارد و در محیط سازمانی زمان‌بندی و سیاست دریافت آن‌ها قابل مدیریت است؛ پیش از تغییر گسترده بهتر است سازگاری، فضای آزاد، وضعیت Backup و مشکلات شناخته‌شده نسخه بررسی شود و بعد از نصب نیز وضعیت سرویس‌ها و برنامه‌های اصلی کنترل شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخ‌های اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیع‌های مدرن‌اند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده می‌شود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان می‌کند و سطح ریسک را بالا می‌برد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترل‌شده روش قابل نگهداری‌تری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود

apt و dnf نمونه ابزارهای رایج‌اند

apt در خانواده Debian/Ubuntu و dnf در بسیاری از توزیع‌های خانواده Red Hat ابزار مدیریت Package هستند؛ دستور دقیق به Distribution بستگی دارد به‌روزرسانی سیستم‌عامل فقط اضافه کردن قابلیت جدید نیست و بخشی از نگهداری امنیتی و پایداری سیستم محسوب می‌شود؛ Microsoft برای Windows سازوکارهای جداگانه‌ای برای Quality Update، Feature Update و Driver Update دارد و در محیط سازمانی زمان‌بندی و سیاست دریافت آن‌ها قابل مدیریت است؛ پیش از تغییر گسترده بهتر است سازگاری، فضای آزاد، وضعیت Backup و مشکلات شناخته‌شده نسخه بررسی شود و بعد از نصب نیز وضعیت سرویس‌ها و برنامه‌های اصلی کنترل شود در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخ‌های اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیع‌های مدرن‌اند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده می‌شود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان می‌کند و سطح ریسک را بالا می‌برد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترل‌شده روش قابل نگهداری‌تری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود

Repository منبع Package است

Package Manager نرم‌افزار و وابستگی را از Repositoryهای تعریف‌شده می‌گیرد. Repository ناشناس یا ناسازگار می‌تواند Package مخرب یا نسخه ناسازگار وارد سیستم کند به‌روزرسانی سیستم‌عامل فقط اضافه کردن قابلیت جدید نیست و بخشی از نگهداری امنیتی و پایداری سیستم محسوب می‌شود؛ Microsoft برای Windows سازوکارهای جداگانه‌ای برای Quality Update، Feature Update و Driver Update دارد و در محیط سازمانی زمان‌بندی و سیاست دریافت آن‌ها قابل مدیریت است؛ پیش از تغییر گسترده بهتر است سازگاری، فضای آزاد، وضعیت Backup و مشکلات شناخته‌شده نسخه بررسی شود و بعد از نصب نیز وضعیت سرویس‌ها و برنامه‌های اصلی کنترل شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخ‌های اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیع‌های مدرن‌اند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده می‌شود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان می‌کند و سطح ریسک را بالا می‌برد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترل‌شده روش قابل نگهداری‌تری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود

Update Production نیاز برنامه تغییر دارد

برنامه تغییر، گام‌های دقیق اجرا، پیش‌نیاز، مسئول، معیار موفقیت و بازگشت امن را مشخص می‌کند؛ نفر دیگری باید بتواند از روی Plan بفهمد چه می‌کنی Plan مبهم مثل «تنظیم Router اصلاح شود» قابل کنترل نیست به‌روزرسانی سیستم‌عامل فقط اضافه کردن قابلیت جدید نیست و بخشی از نگهداری امنیتی و پایداری سیستم محسوب می‌شود؛ Microsoft برای Windows سازوکارهای جداگانه‌ای برای Quality Update، Feature Update و Driver Update دارد و در محیط سازمانی زمان‌بندی و سیاست دریافت آن‌ها قابل مدیریت است؛ پیش از تغییر گسترده بهتر است سازگاری، فضای آزاد، وضعیت Backup و مشکلات شناخته‌شده نسخه بررسی شود و بعد از نصب نیز وضعیت سرویس‌ها و برنامه‌های اصلی کنترل شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان می‌کند و سطح ریسک را بالا می‌برد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترل‌شده روش قابل نگهداری‌تری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود

حذف Package ممکن است وابستگی داشته باشد

وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه می‌تواند چند سرویس ظاهراً نامرتبط را هم‌زمان خراب کند به‌روزرسانی سیستم‌عامل فقط اضافه کردن قابلیت جدید نیست و بخشی از نگهداری امنیتی و پایداری سیستم محسوب می‌شود؛ Microsoft برای Windows سازوکارهای جداگانه‌ای برای Quality Update، Feature Update و Driver Update دارد و در محیط سازمانی زمان‌بندی و سیاست دریافت آن‌ها قابل مدیریت است؛ پیش از تغییر گسترده بهتر است سازگاری، فضای آزاد، وضعیت Backup و مشکلات شناخته‌شده نسخه بررسی شود و بعد از نصب نیز وضعیت سرویس‌ها و برنامه‌های اصلی کنترل شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخ‌های اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیع‌های مدرن‌اند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده می‌شود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان می‌کند و سطح ریسک را بالا می‌برد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترل‌شده روش قابل نگهداری‌تری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود

مثال محیط واقعی

فرض کن در Server Linux مشکلی گزارش شده و احتمال می‌دهی به Package Management و Update مربوط باشد. قبل از تغییر، وضعیت فعلی را با systemctl، journalctl، ip، ss، df، free و ps بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است

اشتباهات رایج

این اشتباه‌ها را تکرار نکن

  • تغییر دادن تنظیمات مرتبط با Package Management و Update قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
  • نتیجه‌گیری درباره Package Management و Update فقط از روی یک نشانه و بدون انجام تست نهایی
تمرین عملی

حالا خودت انجام بده

  1. در یک نمونه آزمایشی مرتبط با Package Management و Update، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
  2. با systemctl، journalctl، ip، ss، df، free و ps وضعیت مرتبط با Package Management و Update را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
  3. یک خطای فرضی مرتبط با Package Management و Update بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند

نکته‌هایی که باید با خودت ببری

  • Package Manager نصب نرم‌افزار را مدیریت می‌کند
  • apt و dnf نمونه ابزارهای رایج‌اند
  • Repository منبع Package است
  • Update Production نیاز برنامه تغییر دارد
  • حذف Package ممکن است وابستگی داشته باشد
  • با root دائمی کار نکن و قبل از ویرایش فایل تنظیمات نسخه برگشت داشته باش
خودسنجی

قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده

این نکته را با یک مثال توضیح بده: Package Manager نصب نرم‌افزار را مدیریت می‌کند. بعد بگو در عمل چطور آن را بررسی می‌کنی.

مدیر بسته وابستگی‌ها، Repository و نصب یا حذف نرم‌افزار را مدیریت می‌کند؛ قبل از حذف ببین چه Packageهای دیگری به آن وابسته‌اند

این نکته را با یک مثال توضیح بده: apt و dnf نمونه ابزارهای رایج‌اند. بعد بگو در عمل چطور آن را بررسی می‌کنی.

apt در خانواده Debian/Ubuntu و dnf در بسیاری از توزیع‌های خانواده Red Hat ابزار مدیریت Package هستند؛ دستور دقیق به Distribution بستگی دارد

این نکته را با یک مثال توضیح بده: Repository منبع Package است. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Package Manager نرم‌افزار و وابستگی را از Repositoryهای تعریف‌شده می‌گیرد. Repository ناشناس یا ناسازگار می‌تواند Package مخرب یا نسخه ناسازگار وارد سیستم کند

مطالعه درس همیشه عمومی است

برای ذخیره پیشرفت، دوره را رسمی شروع کن

با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود

ثبت‌نام و شروع رسمی