چک‌لیست نگهداری سرور لینوکس: بررسی‌های هفتگی و ماهانه

نگهداری از سرور لینوکس در عمل به چه معناست

نگهداری از سرور لینوکس مجموعه‌ای از بررسی‌های کوتاه است که طبق یک برنامه زمانی مشخص انجام می‌شود، نه پروژه‌ای که پایانی داشته باشد. به‌صورت هفتگی تأیید می‌کنید که به‌روزرسانی‌ها نصب شده‌اند، دیسک فضای کافی دارد، هیچ سرویسی متوقف نشده و عملیات پشتیبان‌گیری با موفقیت به پایان رسیده است. به‌صورت ماهانه، یک بازیابی (restore) را تست می‌کنید، انقضای گواهی‌ها را بررسی می‌کنید، حساب‌های کاربری و کلیدها را بازرسی کرده و کرنل‌ها و لاگ‌های قدیمی را پاک‌سازی می‌کنید. با هر انتشار نسخه جدید توزیع، برای ارتقای نسخه برنامه‌ریزی کرده و ری‌بوت (reboot) سرور را که مدام به تعویق می‌اندازید، انجام می‌دهید.

ساختن سرور یک کار متفاوت است و ده دقیقه اول در یک VPS جدید به آن بخش می‌پردازد. این صفحه مربوط به سال پس از آن است. هر مورد در زیر، خرابی یا مشکلی را که از آن جلوگیری می‌کند نام می‌برد، زیرا چک‌لیستی که پیامدهای آن مشخص نباشد، چک‌لیستی است که افراد به‌آرامی انجام آن را متوقف می‌کنند.

دستورات در اینجا جنبه آموزشی دارند و باید پیش از اجرا خوانده شوند. خروجی آن‌ها را با سرور خود مقایسه کنید، چرا که مقدار مناسب برای فضای آزاد یا تعداد پردازش‌ها به کاری که سرور انجام می‌دهد بستگی دارد. در مواردی که بررسی بین توزیع‌ها متفاوت است، متن به آن اشاره کرده است. مثال‌ها از Debian و Ubuntu با apt استفاده می‌کنند. در خانواده RHEL، ابزارها dnf هستند و چندین مسیر متفاوت وجود دارد.

چگونه یک زمان‌بندی نگهداری برای سرور لینوکس انتخاب کنید که به آن پایبند بمانید

بررسی‌های هفتگی مواردی را پوشش می‌دهند که بدون دخالت شما تغییر می‌کنند: بسته‌ها، میزان استفاده از دیسک، وضعیت سرویس‌ها و کارهای زمان‌بندی‌شده. این موارد به‌طور خودکار تغییر می‌کنند، بنابراین یک هفته طولانی‌ترین زمانی است که می‌توانید آن‌ها را بدون بررسی رها کنید.

بررسی‌های ماهانه فرسایش تدریجی را پوشش می‌دهند: گواهی‌هایی که به تاریخ انقضا نزدیک می‌شوند، حساب‌های کاربری که حذف نشده‌اند، کرنل‌هایی که در /boot انباشته می‌شوند و فایل‌های لاگی که فراتر از قانون چرخش (rotation) که دیگر مطابقت ندارد، رشد کرده‌اند. هیچ‌کدام از این‌ها فردا خراب نمی‌شوند، اما همگی در نهایت باعث خرابی خواهند شد.

بررسی‌های مربوط به انتشار (Release) بر اساس تقویم هستند. انتشار یک توزیع، تنها مورد نگهداری با مهلت زمانی خارجی است؛ زیرا پشتیبانی از نسخه فعلی شما، فارغ از اینکه آماده باشید یا نه، به پایان می‌رسد.

زمان اجرای این کارها را در یک بازه ثابت قرار دهید؛ مثلاً صبح دوشنبه برای بررسی‌های هفتگی و روز اول ماه برای بررسی‌های ماهانه. چک‌لیستی که «هر وقت فرصت شد» اجرا شود، چک‌لیست نیست. اگر تعداد ماشین‌ها از چند عدد بیشتر شد، این کارها را به جای انجام دستی از یک نقطه مرکزی مدیریت کنید که موضوع مدیریت چندین سرور لینوکس از یک نقطه مرکزی است.

هفتگی: آیا به‌روزرسانی‌ها واقعاً نصب شدند؟

فعال‌سازی unattended-upgrades به معنای اطمینان از اجرای آن نیست. ممکن است سرویس masked شده باشد، پیکربندی به منبعی محدود باشد که از آن استفاده نمی‌کنید، یا یک بستهٔ held (نگه‌داشته‌شده) تمام اجراهای بعدی را مختل کند. نصب آن در به‌روزرسانی‌های امنیتی خودکار در Ubuntu پوشش داده شده است. وظیفهٔ هفتگی، اثبات این است که آنچه نصب کرده‌اید، کار خود را انجام داده است.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable معیار صادقانه‌ای است، زیرا وضعیت فعلی را گزارش می‌دهد و نه قصد و نیت سیستم را. وجود به‌روزرسانی‌های امنیتی در آن لیست به این معنی است که اتوماسیون وظیفهٔ خود را انجام نمی‌دهد؛ بنابراین پیش از آنکه فرض کنید سیستم وصله شده است، لاگ را بخوانید. بسته‌ای که با apt-mark hold پین شده باشد، برای همیشه نادیده گرفته می‌شود و هیچ گزارشی نمی‌دهد؛ به همین دلیل است که apt-mark showhold باید در همان مرحله گنجانده شود.

شکستی که این کار از آن جلوگیری می‌کند: اجرای یک بستهٔ دارای آسیب‌پذیری شناخته‌شده برای ماه‌ها، در حالی که تصور می‌کنید به‌روزرسانی‌ها خودکار بوده‌اند.

بررسی هفتگی: فضای دیسک و inode

پر شدن فایل‌سیستم root باعث بروز مشکلاتی می‌شود که در ظاهر هیچ ارتباطی با فضای دیسک ندارند. دیتابیس از نوشتن داده‌ها امتناع می‌کند، ثبت لاگ‌ها متوقف می‌شود، ارتقای یک پکیج به‌صورت ناقص باقی می‌ماند و در برخی تنظیمات، حتی نمی‌توانید نشست (session) جدیدی باز کنید، زیرا سیستم قادر به نوشتن فایل‌های مربوط به آن نیست.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i بخشی است که اکثر افراد از آن غافل می‌شوند. Inodeها ساختارهای با تعداد ثابت هستند که متادیتای فایل‌ها را در خود نگه می‌دارند و ممکن است فایل‌سیستم در حالی که df -h هنوز گیگابایت‌ها فضای خالی گزارش می‌دهد، با کمبود آن‌ها مواجه شود. در این حالت، عملیات نوشتن با خطای No space left on device مواجه می‌شود، در حالی که خروجی سیستم فضای خالی را نشان می‌دهد؛ این موضوع در اولین برخورد، ساعت‌ها وقت شما را برای عیب‌یابی تلف می‌کند. دلیل معمول این اتفاق، وجود میلیون‌ها فایل کوچک است که ناشی از یک صف ایمیل گیرکرده یا دایرکتوری session است که هیچ‌کس آن را پاکسازی نکرده است.

du -xh روی یک فایل‌سیستم باقی می‌ماند، که این دقیقاً همان چیزی است که در سروری با bind mountها یا حافظه‌های جانبی متصل به آن نیاز دارید. در یک میزبان Docker، پاسخ معمولاً در لایه‌های image و volumeهای بلااستفاده نهفته است که طبق توضیحات پاکسازی فضای دیسک Docker در یک VPS پاکسازی می‌شوند.

فضای خالی به شما درباره ظرفیت ذخیره‌سازی اطلاع می‌دهد. حافظه زیرساختی بر اساس زمان‌بندی خاص خود دچار خرابی می‌شود که یک بررسی مجزا است و در پایش سلامت دیسک در یک VPS به آن پرداخته شده است.

هفتگی: چه چیزی بدون اطلاع شما متوقف شده است؟

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

واحدی که کرش کرده و به حد مجاز restart خود رسیده است، در وضعیت failed باقی می‌ماند و هیچ واکنشی نشان نمی‌دهد. هیچ ایمیلی در مورد آن دریافت نخواهید کرد. دستور list-timers نیمه مفیدتر ماجراست: این دستور نشان می‌دهد هر تایمر آخرین بار چه زمانی اجرا شده و نوبت بعدی اجرای آن کی است؛ بنابراین اگر مقدار LAST قدیمی‌تر از بازه زمانی تعریف‌شده برای آن تایمر باشد، به این معنی است که آن کار اصلاً اجرا نشده است.

پیش از restart کردن واحد، لاگ‌های آن را با استفاده از journalctl -u <unit> -n 100 --no-pager بررسی کنید. restart کردن فقط نشانه را از بین می‌برد و پس از آن دیگر دلیلی برای بررسی نخواهید داشت تا زمانی که همان اتفاق در ساعتی نامناسب‌تر تکرار شود.

این کار از خرابی‌های زیر جلوگیری می‌کند: یک agent مانیتورینگ، یک queue worker یا یک سرویس پشتیبان‌گیری که از زمان جهش مصرف حافظه در سه هفته پیش، از کار افتاده است.

هفتگی: آیا عملیات پشتیبان‌گیری واقعاً به پایان رسیده است؟

یک پشتیبان‌گیری زمان‌بندی‌شده با یک پشتیبان‌گیری کامل‌شده تفاوت دارد و تنها یکی از آن‌ها قابل بازیابی است. تکمیل عملیات را بررسی کنید.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

دو مورد را تأیید کنید. آخرین اجرای دستور با کد خروجی 0 پایان یافته باشد و جدیدترین آرشیو هم به‌تازگی ایجاد شده باشد و هم حجم آن تقریباً مطابق انتظار شما باشد. فایلی که ناگهان به یک‌دهم حجم معمول خود رسیده، یک dump ناموفق است که همچنان یک فایل ایجاد کرده است؛ این خطرناک‌ترین شکل شکست در پشتیبان‌گیری است، زیرا در مراحل بعدی همه چیز عادی به نظر می‌رسد.

اگر اسکریپت شما خروجی یک dump را به یک فشرده‌ساز (compressor) هدایت (pipe) می‌کند، در ابتدای اسکریپت set -o pipefail را اضافه کنید. بدون این دستور، کد خروجی کل pipeline مربوط به فشرده‌ساز خواهد بود و از آنجا که فشرده‌ساز موفق شده است (پیام خطا را فشرده کرده)، عملیات با موفقیت گزارش می‌شود. در نتیجه، سیستم هر شب گزارش موفقیت می‌دهد در حالی که در حال نوشتن یک آرشیو کوچک و بی‌محتوا است.

ماهانه: بازیابی نسخه پشتیبان در مکانی دیگر

این موردی است که اکثر افراد از آن صرف‌نظر می‌کنند، اما همین مورد تعیین می‌کند که آیا بقیه لیست اهمیت داشته است یا خیر.

نسخه پشتیبان را روی یک ماشین متفاوت یا یک کانتینر تازه بازیابی کنید؛ هرگز آن را روی داده‌های زنده بازنویسی نکنید. سپس آنچه را بازیابی کرده‌اید باز کنید و واقعی بودن آن را تأیید کنید. تعداد ردیف‌های یک جدول را بشمارید. یک سند را باز کنید. به برنامه بازیابی‌شده وارد شوید. یک عملیات استخراج که به پایان رسیده است، فقط ثابت می‌کند که آرشیو قابل خواندن است و نه چیزی بیشتر.

ابزارهای مخزن، قابلیت تأیید مخصوص به خود را دارند: restic check --read-data-subset=5% و borg check --verify-data داده‌های ذخیره‌شده را به جای ایندکس می‌خوانند. آن‌ها را اجرا کنید و به عنوان یک تست اولیه (smoke test) به آن‌ها نگاه کنید، نه به عنوان جایگزینی برای بازیابی. تأیید (Verification) بررسی می‌کند که بایت‌ها سالم مانده‌اند. بازیابی بررسی می‌کند که بایت‌ها همان‌هایی هستند که برنامه شما به آن‌ها نیاز دارد.

دو نکته وجود دارد که افراد با تجربه تلخ می‌آموزند. عبارت عبور رمزگشایی (decryption passphrase) را روی ماشینی تست کنید که از قبل کلید را در یک agent نگه نمی‌دارد، زیرا نسخه پشتیبانی که نتوانید رمزگشایی کنید، نسخه پشتیبان نیست. همچنین زمان بازیابی را اندازه‌گیری کنید، زیرا آن مدت زمان، زمان واقعی بازیابی شماست و معمول‌ترین لحظه برای کشف آن، هنگام بروز قطعی است.

ماهانه: کدام گواهی‌ها به‌زودی منقضی می‌شوند؟

اتوماسیون تمدید ممکن است بدون هیچ هشداری با شکست مواجه شود. تایمر certbot می‌تواند فایل موجود روی دیسک را تمدید کند، اما وب‌سرور همچنان گواهی قدیمی را از حافظه ارائه دهد؛ زیرا hook مربوط به deploy که وظیفه reload کردن سرویس را دارد، اجرا نشده است. بنابراین، از خارج از سرور، از خودِ سرویسِ در حال اجرا بپرسید که چه گواهی‌ای را ارائه می‌دهد.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

فلگ -servername تنظیمات SNI (مخفف Server Name Indication) را اعمال می‌کند که برای هر آدرسی که بیش از یک سایت را میزبانی می‌کند الزامی است؛ در غیر این صورت، به‌جای گواهی اختصاصی خود، گواهی پیش‌فرض به شما ارائه می‌شود. اگر certbot از طریق snap نصب شده باشد، نام تایمر متفاوت خواهد بود؛ بنابراین به‌جای تکیه بر نام واحدی که تصور می‌کردید، بر اساس کلمه کلیدی جستجو کنید.

گواهی‌هایی که هیچ‌گونه اتوماسیونی ندارند را فراموش نکنید: میل‌سرور، VPN، یا مرجع صدور گواهی داخلی (Internal CA). این‌ها همان گواهی‌هایی هستند که در تعطیلات آخر هفته منقضی می‌شوند و مرورگرها و کلاینت‌ها به‌جای نمایش هشدار، مستقیماً از پذیرش آن‌ها خودداری می‌کنند.

بررسی ماهانه: کاربران، دسترسی sudo و کلیدهای SSH

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T پیکربندی نهایی را پس از ادغام تمام Include نمایش می‌دهد؛ این همان چیزی است که daemon در عمل از آن استفاده می‌کند. ایمیج‌های جدید Ubuntu فایل‌های drop-in را در /etc/ssh/sshd_config.d/ قرار می‌دهند که می‌توانند فایل اصلی را override کنند؛ بنابراین خواندن sshd_config به تنهایی ممکن است اطلاعات نادرستی به شما بدهد. در خانواده RHEL، گروه مدیریتی wheel است و نه sudo، پس خط getent را متناسب با آن تنظیم کنید.

سپس فایل‌های authorized_keys را بررسی کنید. دسترسی بر اساس کلید اعطا می‌شود، نه حساب کاربری؛ بنابراین کلیدی که از یک پیمانکارِ سابق باقی مانده است، یک راه ورود فعال محسوب می‌شود که هیچ لیست کاربری آن را به عنوان خطر شناسایی نمی‌کند. کلیدها دارای یک فیلد comment هستند. از این فیلد استفاده کنید و هر کلیدی که نمی‌توانید آن را به یک شخص خاص نسبت دهید، حذف کنید.

برای مشاهده تاریخچه ورود، journalctl -t sshd --since "30 days ago" | grep -i accepted بر اساس شناسه syslog جستجو می‌کند، نه نام unit. این موضوع اهمیت دارد زیرا Ubuntu 24.04 سرویس SSH را از طریق یک socket فعال می‌کند؛ در نتیجه هر اتصال تحت یک unit تولیدشده برای همان اتصال ثبت می‌شود و یک دستور ساده journalctl -u ssh ممکن است آن‌ها را نادیده بگیرد.

ماهانه: هسته‌های قدیمی و پر شدن پارتیشن /boot

/boot در تصاویر پیش‌فرض VPS، معمولاً یک پارتیشن مجزا با ظرفیت چند صد مگابایت است. هر به‌روزرسانی هسته (kernel)، یک image و یک initramfs جدید به آن اضافه می‌کند. وقتی این فضا پر شود، ارتقای بعدی در میانه راه با شکست مواجه شده و بسته‌ها را در وضعیت پیکربندی‌نشده رها می‌کند؛ وضعیتی نامطلوب که مواجهه ناگهانی با آن در روز جمعه، دردسرساز است.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r را ابتدا اجرا کنید؛ این دستور نام هسته‌ای که در حال حاضر از آن استفاده می‌کنید را نمایش می‌دهد و شما باید از حذف آن خودداری کنید. apt autoremove در توزیع‌های Debian و Ubuntu حالت معمول را مدیریت می‌کند، زیرا هسته‌ها به عنوان «نصب‌شده به‌صورت خودکار» علامت‌گذاری می‌شوند و هسته فعلی محافظت‌شده باقی می‌ماند. موارد خاص، مانند هسته‌ای که به‌صورت دستی نصب شده یا زمانی که /boot آن‌قدر پر شده که مانع عملکرد خودِ apt می‌شود، در پاک‌سازی هسته‌های قدیمی در Ubuntu توضیح داده شده‌اند.

ماهانه: رشد لاگ‌ها و journal سیستم‌عامل systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug یک اجرای آزمایشی (dry run) است و هیچ تغییری ایجاد نمی‌کند، بنابراین روی سرور فعال ایمن است. اجرای آن توصیه می‌شود زیرا قوانین چرخش لاگ (rotation) بر اساس مسیرها مطابقت داده می‌شوند: اگر برنامه‌ای در طول ارتقا مسیر لاگ خود را تغییر دهد، دیگر تحت پوشش قانون قبلی نخواهد بود و آن فایل بدون محدودیت رشد می‌کند تا زمانی که فضای دیسک پر شود.

حجم journal توسط systemd محدود شده است، اما این محدودیت بر اساس درصدی از فضای فایل‌سیستم است، نه عددی که شما تعیین کرده باشید. اگر سقف مشخصی مد نظر دارید، SystemMaxUse= را در /etc/systemd/journald.conf تنظیم کرده و systemd-journald را restart کنید. دستور sudo journalctl --vacuum-time=14d بلافاصله فضا را آزاد می‌کند، اما این یک اقدام یک‌باره است و نه یک سیاست دائمی؛ بنابراین آن را همراه با تغییر پیکربندی انجام دهید.

در هر نسخه: ری‌بوتی که مدام به تعویق می‌اندازید

بسته کرنل به‌روزرسانی‌شده روی دیسک، به معنای کرنل در حال اجرا نیست. تا زمانی که سیستم ری‌بوت نشود، ماشین همچنان از نسخه قدیمی استفاده می‌کند و live patching، در صورت در دسترس بودن، تنها بخش کوچکی از اصلاحات را پوشش می‌دهد.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

آن فایل flag یک قرارداد در Debian و Ubuntu است که توسط اسکریپت‌های بسته ایجاد می‌شود. سیستم‌های خانواده RHEL چنین فایلی ایجاد نمی‌کنند و پاسخ به پرسش مشابه در آن‌ها توسط needs-restarting -r داده می‌شود که از dnf-utils می‌آید. ابزار needrestart که به‌صورت پیش‌فرض در ایمیج‌های اخیر Ubuntu server نصب می‌شود، به سطح پایین‌تر از کرنل پاسخ می‌دهد: این ابزار پردازش‌هایی را فهرست می‌کند که هنوز از کتابخانه‌ای استفاده می‌کنند که روی دیسک جایگزین شده است؛ به همین دلیل است که یک OpenSSL وصله‌شده تا زمانی که سرویس‌های استفاده‌کننده از آن ری‌استارت نشوند، اعمال نمی‌شود.

به‌جای اجتناب از ری‌بوت، آن را زمان‌بندی کنید. در /etc/apt/apt.conf.d/50unattended-upgrades، Unattended-Upgrade::Automatic-Reboot "true"; و Unattended-Upgrade::Automatic-Reboot-Time "03:00"; تصمیم‌گیری را به زمانی که خودتان انتخاب کرده‌اید بسپارید. یک ری‌بوت برنامه‌ریزی‌شده همچنین تنها راه تست این است که آیا سرور دوباره بالا می‌آید یا خیر، زیرا یک ورودی خراب در fstab یا سرویسی که هرگز فعال نکرده‌اید، تنها در زمان بوت خود را نشان می‌دهد و نه جای دیگر.

در هر نسخه: برنامه‌ریزی برای ارتقای توزیع

نسخه‌های LTS اوبونتو دارای 5 سال پشتیبانی استاندارد هستند و نسخه‌های موقت 9 ماه پشتیبانی دارند، بنابراین انتخاب شما حجم کاری ارتقا را برای سال‌ها تعیین می‌کند. این بده‌بستان در نسخه‌های LTS در برابر نسخه‌های موقت روی سرور بررسی شده است.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade آن فایل را می‌خواند و Prompt=lts آن را به جابه‌جایی‌های LTS به LTS محدود می‌کند. مسیر LTS به LTS معمولاً در اولین نسخهٔ فرعی (point release) از نسخهٔ جدید باز می‌شود، نه در روز انتشار؛ بنابراین به‌جای برنامه‌ریزی بر اساس تاریخی که تصور می‌کردید، بررسی کنید که سیستم شما چه نسخه‌ای را پیشنهاد می‌دهد. جزئیات فنی این جهش در ارتقای Ubuntu 24.04 به 26.04 آمده است.

سه ماه حاشیهٔ اطمینان در نظر بگیرید. یک اسنپ‌شات تهیه کنید که بازیابی آن را تست کرده‌اید، مخازن apt شخص ثالث خود را لیست کنید (ارتقا آن‌ها را غیرفعال می‌کند و هر کدام برای نسخهٔ جدید به مقصد تازه‌ای نیاز دارند) و پیش از شروع، استراتژی بازگشت به وضعیت قبل (rollback) را تعیین کنید. تا اوت 2026، نسخهٔ Ubuntu 24.04 LTS تا آوریل 2029 پشتیبانی استاندارد دارد، بنابراین این یک برنامه‌ریزی است، نه یک وضعیت اضطراری.

چه مواردی را خودکار کنیم و چه مواردی را دستی نگه داریم

تصمیماتی را که قبلاً اتخاذ کرده‌اید خودکار کنید: به‌روزرسانی‌های امنیتی، چرخش لاگ‌ها (log rotation)، تمدید گواهی‌ها و وظایف پشتیبان‌گیری. سیستم هشداردهی را نیز خودکار کنید، زیرا بررسی‌ای که به یادآوری شما وابسته باشد، بررسی‌ای است که ساعت 2 بامداد انجام نخواهد شد. یک مانیتور خارجی، مانند مانیتورینگ وضعیت self-hosted با Uptime Kuma، تنها موردی را که هیچ اسکریپت داخلی نمی‌تواند گزارش دهد، یعنی غیرقابل‌دسترس بودن سرور، شناسایی می‌کند.

دو مورد را به‌صورت دستی نگه دارید: تست بازیابی (restore test) و حسابرسی حساب‌های کاربری. هر دو مورد نیاز دارند که یک شخص تصمیم بگیرد آیا نتیجه درست است یا خیر. اگر ترجیح می‌دهید وضعیت ماشین را در مرورگر بخوانید تا در ترمینال، مقایسه Cockpit و Webmin برای مدیریت سرور دو کنسول وب رایج را با هم مقایسه می‌کند.

سپس خودِ اتوماسیون نیز به بررسی نیاز دارد؛ به همین دلیل است که اولین مورد هفتگی در این فهرست، تأیید صحت به‌روزرسان (updater) است. اتوماسیونی که در سکوت شکست می‌خورد، از نداشتن اتوماسیون بدتر است، زیرا همزمان هم خرابی را پنهان می‌کند و هم عادتِ بررسی کردن را از بین می‌برد.

چک‌لیست کامل در یک نگاه

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

هر چند وقت یک‌بار باید نگهداری سرور لینوکس را انجام دهم؟

برای هر چیزی که به‌طور خودکار تغییر می‌کند، به‌صورت هفتگی اقدام کنید: وضعیت به‌روزرسانی‌ها، فضای خالی دیسک و inode، سرویس‌های ناموفق (failed units) و اینکه آیا عملیات پشتیبان‌گیری با موفقیت به پایان رسیده است یا خیر. برای مواردی که روند فرسایشی کندی دارند، به‌صورت ماهانه بررسی کنید: تست بازیابی (restore)، انقضای گواهی‌ها، ممیزی حساب‌های کاربری و کلیدهای SSH، هسته‌های (kernel) قدیمی و رشد حجم لاگ‌ها. برای ارتقای نسخه و راه‌اندازی مجدد (reboot) روی هسته جدید، یک‌بار در هر چرخه انتشار توزیع (distribution release) کافی است. بررسی هفتگی در یک سرور سالم تنها چند دقیقه زمان می‌برد؛ هدف از انجام هفتگی این است که پیش از بروز مشکل، وضعیت را بسنجید.

چرا با وجود موفقیت‌آمیز بودن گزارش پشتیبان‌گیری، باید تست بازیابی انجام دهم؟

زیرا گزارش عملیات تنها وضعیت خروج (exit status) خودِ آن دستور را اعلام می‌کند و این وضعیت می‌تواند در حالی که آرشیو پشتیبان غیرقابل استفاده است، موفقیت‌آمیز (true) باشد. اگر خروجی یک dump به یک فشرده‌ساز بدون set -o pipefail ارسال شود، وضعیت خروجی همان فشرده‌ساز برگردانده می‌شود؛ بنابراین یک dump ناموفق که تنها یک پیام خطا تولید کرده است، همچنان با کد صفر خارج شده و یک فایل کوچک ایجاد می‌کند. داده‌ها را در ماشین دیگری بازیابی کنید، آن‌ها را باز کنید و بخشی از محتوا را بررسی کنید. تست بازیابی همچنین زمان‌گیر است و مدت‌زمان آن، زمان واقعی بازیابی (recovery time) شما را مشخص می‌کند.

آیا باید بعد از هر به‌روزرسانی هسته (kernel)، سرور را reboot کنم؟

شما باید پیش از آنکه هسته جدید به هسته در حال اجرا تبدیل شود، سرور را reboot کنید. در Debian و Ubuntu، وجود فایل /var/run/reboot-required نشان می‌دهد که یک بسته درخواست reboot کرده است و /var/run/reboot-required.pkgs مشخص می‌کند کدام بسته این درخواست را داشته است. در خانواده RHEL چنین فایلی وجود ندارد و دستور needs-restarting -r از بسته dnf-utils به همین پرسش پاسخ می‌دهد. یک بازه زمانی خودکار برای reboot در /etc/apt/apt.conf.d/50unattended-upgrades تنظیم کنید تا آن را به‌طور نامحدود به تعویق نیندازید؛ زیرا ماشینی که یک سال reboot نشده است، علاوه بر داشتن هسته قدیمی، مسیر بوت (boot path) آن نیز تست‌نشده باقی مانده است.

کدام‌یک از این بررسی‌ها را می‌توان با خیال راحت خودکار کرد؟

اقداماتی را خودکار کنید که تصمیم‌گیری درباره آن‌ها از قبل انجام شده است: به‌روزرسانی‌های امنیتی، چرخش لاگ‌ها (log rotation)، تمدید گواهی‌ها و پشتیبان‌گیری‌های زمان‌بندی‌شده. اطلاع‌رسانی را نیز خودکار کنید تا یک سرویس ناموفق یا پر شدن دیسک، بدون نیاز به اجرای دستی دستور توسط شما، گزارش شود. تست بازیابی و ممیزی کلیدها را به‌صورت دستی نگه دارید، زیرا هر کدام نیاز به قضاوت انسانی دارند تا مشخص شود آیا نتیجه صحیح است یا خیر. سپس یک بررسی روی خودِ سیستم اتوماسیون اضافه کنید، چرا که شکستِ بی‌صدای یک به‌روزرسان، دقیقاً مشابه عملکرد صحیح سیستم به نظر می‌رسد.