با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست
با SSH وصل شو و IP و Route را پیدا کن
SSH کانال رمزنگاری‌شده برای Shell و مدیریت Remote فراهم می‌کند؛ Key-based Authentication و محدودسازی دسترسی Admin امنیت را بهتر می‌کند باز گذاشتن Password Login عمومی روی اینترنت ریسک حمله را بالا می‌برد نشانی IP هویت منطقی Interface در لایه شبکه است و باید همراه Prefix یا Subnet Mask تفسیر شود؛ Prefix مشخص می‌کند کدام بخش نشانی برای شبکه و کدام بخش برای Host استفاده می‌شود و همین موضوع تعیین می‌کند مقصد محلی است یا باید به Router فرستاده شود؛ در عیب‌یابی، فقط دیدن یک IP کافی نیست و باید Prefix، Gateway، DNS، روش دریافت تنظیمات، Route Table و احتمال وجود نشانی تکراری نیز بررسی شوند Router زمانی وارد مسیر می‌شود که مقصد خارج از شبکه محلی باشد و جدول Routing تعیین می‌کند Packet از کدام Next Hop یا Interface عبور کند؛ Default Route فقط مسیر پیش‌فرض برای مقصدهایی است که Route مشخص‌تری ندارند؛ در بررسی مشکل باید Routeهای موجود، Prefix هر Route، Gateway یا Next Hop، وضعیت Interface و مسیر برگشت را هم دید، چون رسیدن Packet به مقصد بدون مسیر برگشت معتبر ارتباط پایدار ایجاد نمی‌کند
سرویس و Log را بررسی کن
گزارش رویداد ثبت زمانی اتفاق‌ها و خطاهای سیستم است و برای ساختن Timeline کمک می‌کند؛ زمان گزارش کاربر را با Log همان بازه مقایسه کن هر خطای ثبت‌شده علت اصلی نیست و باید با نشانه مرتبط شود در Linux مدیریت سرویس‌ها، فایل‌ها، Userها و شبکه بر پایه ابزارها و فایل‌های پیکربندی مشخص انجام می‌شود؛ systemd وضعیت Serviceها و وابستگی آن‌ها را مدیریت می‌کند و journal می‌تواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیت‌های دسترسی تشکیل می‌شوند و استفاده از sudo باید کنترل‌شده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیام‌های رویداد ارائه می‌دهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده می‌شود؛ همگام بودن زمان سیستم‌ها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود؛ در همین درس، موضوع «سرویس و Log را بررسی کن» را باید در ارتباط با «آزمایشگاه Linux برای کارشناس شبکه» بررسی کنی و نتیجه را با شواهد همان سیستم توضیح بدهی
فضای Disk را تحلیل کن
برای Disk Full از df برای Filesystem و du برای مسیرهای پرمصرف استفاده کن؛ قبل از حذف فایل، مالک یا مسئول داده و نقش آن فایل در Log یا نرم‌افزار را مشخص کن در Linux مدیریت سرویس‌ها، فایل‌ها، Userها و شبکه بر پایه ابزارها و فایل‌های پیکربندی مشخص انجام می‌شود؛ systemd وضعیت Serviceها و وابستگی آن‌ها را مدیریت می‌کند و journal می‌تواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیت‌های دسترسی تشکیل می‌شوند و استفاده از sudo باید کنترل‌شده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Permission و مالکیت در Linux باید با نیاز واقعی Service هماهنگ باشد؛ اجرای همه چیز با root مشکل را پنهان می‌کند و سطح ریسک را بالا می‌برد؛ User و Group مناسب، حداقل Permission لازم و sudo کنترل‌شده روش قابل نگهداری‌تری است؛ بعد از تغییر، هم دسترسی مورد نیاز و هم عدم دسترسی ناخواسته بررسی شود
Permission فایل آزمایشی را اصلاح کن
در آزمایش Linux ابتدا با ls -l مالک و مجوز را ببین، سپس کمترین تغییر لازم را با chmod یا chown انجام بده و با همان کاربر هدف نتیجه را دوباره آزمایش کن در File Server ویندوز، دسترسی کاربر می‌تواند هم‌زمان تحت تأثیر Share Permission و NTFS Permission باشد و برای تشخیص نتیجه باید هر دو لایه بررسی شوند؛ مدیریت دسترسی از طریق Security Group معمولاً قابل نگهداری‌تر از دادن Permission مستقیم به تعداد زیادی User است؛ Inheritance نیز تعیین می‌کند مجوزها چگونه به زیرپوشه‌ها برسند و تغییر بدون بررسی می‌تواند دسترسی‌های ناخواسته ایجاد کند؛ دسترسی مؤثر باید با یک حساب آزمایشی از دید کاربر هم تأیید شود در Linux مدیریت سرویس‌ها، فایل‌ها، Userها و شبکه بر پایه ابزارها و فایل‌های پیکربندی مشخص انجام می‌شود؛ systemd وضعیت Serviceها و وابستگی آن‌ها را مدیریت می‌کند و journal می‌تواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیت‌های دسترسی تشکیل می‌شوند و استفاده از sudo باید کنترل‌شده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود
تمام تغییرها را مستند کن
در تمرین Linux Command اجراشده، فایل تغییرکرده، مقدار قبل و بعد و نتیجه را ثبت کن؛ این عادت هنگام کار روی Server واقعی امکان بازگشت امن و Handoff را بهتر می‌کند در Linux مدیریت سرویس‌ها، فایل‌ها، Userها و شبکه بر پایه ابزارها و فایل‌های پیکربندی مشخص انجام می‌شود؛ systemd وضعیت Serviceها و وابستگی آن‌ها را مدیریت می‌کند و journal می‌تواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیت‌های دسترسی تشکیل می‌شوند و استفاده از sudo باید کنترل‌شده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در Linux بهتر است هر تغییر را با شناخت Service و فایل پیکربندی مربوط انجام دهی؛ وضعیت Process، Socket، Permission و Log معمولاً سرنخ‌های اصلی هستند؛ systemd و journal ابزارهای مرکزی در بسیاری از توزیع‌های مدرن‌اند و NetworkManager نیز در RHEL برای مدیریت شبکه استفاده می‌شود؛ قبل از ویرایش، نسخه فایل و راه بازگشت نگه داشته شود
فرض کن در Server Linux مشکلی گزارش شده و احتمال می‌دهی به آزمایشگاه Linux برای کارشناس شبکه مربوط باشد. قبل از تغییر، وضعیت فعلی را با systemctl، journalctl، ip، ss، df، free و ps بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباه‌ها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با آزمایشگاه Linux برای کارشناس شبکه قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجه‌گیری درباره آزمایشگاه Linux برای کارشناس شبکه فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با آزمایشگاه Linux برای کارشناس شبکه، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
- با systemctl، journalctl، ip، ss، df، free و ps وضعیت مرتبط با آزمایشگاه Linux برای کارشناس شبکه را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
- یک خطای فرضی مرتبط با آزمایشگاه Linux برای کارشناس شبکه بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند
نکته‌هایی که باید با خودت ببری
- با SSH وصل شو و IP و Route را پیدا کن
- سرویس و Log را بررسی کن
- فضای Disk را تحلیل کن
- Permission فایل آزمایشی را اصلاح کن
- تمام تغییرها را مستند کن
- با root دائمی کار نکن و قبل از ویرایش فایل تنظیمات نسخه برگشت داشته باش
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید با SSH وصل شو و IP و Route را پیدا کنی و از کجا می‌فهمی نتیجه درست است؟
SSH کانال رمزنگاری‌شده برای Shell و مدیریت Remote فراهم می‌کند؛ Key-based Authentication و محدودسازی دسترسی Admin امنیت را بهتر می‌کند
چرا باید سرویس و Log را بررسی کنی و از کجا می‌فهمی نتیجه درست است؟
گزارش رویداد ثبت زمانی اتفاق‌ها و خطاهای سیستم است و برای ساختن Timeline کمک می‌کند؛ زمان گزارش کاربر را با Log همان بازه مقایسه کن
چرا باید فضای Disk را تحلیل کنی و از کجا می‌فهمی نتیجه درست است؟
برای Disk Full از df برای Filesystem و du برای مسیرهای پرمصرف استفاده کن؛ قبل از حذف فایل، مالک یا مسئول داده و نقش آن فایل در Log یا نرم‌افزار را مشخص کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود
