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

دستورات لینوکس برای مدیر سرور یک مجموعه کوچک و تکراری اند. لازم نیست صدها دستور بدانید؛ حدود سی دستور مشکل های روزمره سرور را حل می کنند: پر شدن دیسک، سرویسی که بالا نمی آید، پورتی که بسته است، فرایندی که CPU را می خورد. دستورها را بر اساس کاری که می کنند دسته بندی کرده ایم تا مثل مرجع سریع به کار بیایند. فرض بر این است که با SSH به سرور وصل شده اید (SSH چیست).

حرکت و کار با فایل

قبل از rm -r مسیر را دوباره بخوانید و مخصوصاً از زدن آن با sudo و مسیر نادرست پرهیز کنید. اشتباه تایپی مثل فاصله اضافه بعد از اسلش یک بار کل سرور را پاک کرده است.

مجوزها و مالکیت

chmod 640 config.php
chmod -R u+rwX,go-rwx ~/.ssh
chown www-data:www-data /var/www/site -R
stat config.php

مجوز 640 یعنی مالک بخواند و بنویسد، گروه فقط بخواند و بقیه هیچ. عدد 777 را به عنوان راه حل «مشکل مجوز» استفاده نکنید؛ هر کاربر سرور را به نویسنده فایل تبدیل می کند. به جای آن مالک و گروه درست را تنظیم کنید.

جستجو در متن و فایل ها

grep -ri "error" /var/log/nginx/
grep -n "listen" /etc/nginx/sites-enabled/*
find /var/www -name "*.php" -mtime -1
find / -type f -size +500M 2>/dev/null

grep متن را در فایل ها پیدا می کند (-r بازگشتی، -i بدون حساسیت به حروف، -n شماره خط). find بر اساس نام، زمان تغییر یا اندازه فایل می گردد. مثال آخر فایل های بزرگ تر از 500 مگابایت را پیدا می کند، که برای پیدا کردن دلیل پر شدن دیسک عالی است. مثال سوم فایل های PHP تغییر کرده در 24 ساعت اخیر را نشان می دهد، که در بررسی علائم هک شدن سایت کاربرد دارد.

فرایندها و منابع

top
htop
ps aux --sort=-%mem | head
free -h
uptime
kill 1234
kill -9 1234

top و htop نشان می دهند چه چیزی CPU و رم می خورد. free -h رم و swap، و uptime میانگین بار (load) را نشان می دهد. عدد load باید در حالت عادی از تعداد هسته های پردازنده کمتر باشد. kill به فرایند اجازه می دهد خودش را درست ببندد؛ kill -9 فوراً می کشدش و فقط وقتی استفاده شود که راه دیگری نیست. بیشتر نکته های عیب یابی کندی در افزایش سرعت سرور مجازی است.

سرویس ها و لاگ ها

systemctl status nginx
sudo systemctl restart nginx
sudo systemctl enable --now fail2ban
journalctl -u nginx --since "1 hour ago"
journalctl -xe
tail -f /var/log/syslog

systemctl سرویس ها را مدیریت می کند. دستور enable سرویس را برای بالا آمدن بعد از ریبوت تنظیم می کند. journalctl لاگ سرویس ها را می خواند؛ گزینه -u یک سرویس مشخص را فیلتر می کند. وقتی سرویسی بالا نمی آید، اول خروجی systemctl status و بعد journalctl -xe علت را معمولاً نشان می دهند.

دیسک و فضا

df -h
du -sh /var/* | sort -h
lsblk
mount | grep ext4
df -i

اگر سرور ناگهان خطای «No space left on device» داد، df -h را بزنید ببینید کدام پارتیشن پر است، و بعد du -sh /var/* نشان می دهد کدام پوشه جا گرفته است. df -i هم گاهی دلیل است: دیسک فضای آزاد دارد ولی inode ها تمام شده اند، که با میلیون ها فایل کوچک پیش می آید. شایع ترین مقصرها لاگ های بدون چرخش، بکاپ های قدیمی و فایل های موقت اند. بحث RAID و رابط های دیسک جداگانه در مقاله های دیگر آمده است.

شبکه

ip addr
ip route
ss -tulpn
curl -I https://example.com
ping -c 4 8.8.8.8
dig example.com +short

دستور ss -tulpn نشان می دهد کدام برنامه روی کدام پورت گوش می دهد، که برای فهمیدن «سرویس بالا است ولی از بیرون نمی شود وصل شد» ضروری است. اگر برنامه فقط روی 127.0.0.1 گوش می دهد، از بیرون در دسترس نیست. curl -I فقط هدر جواب وب را می آورد و کد وضعیت (200، 301، 502) را نشان می دهد. ادامه عیب یابی شبکه در عیب یابی شبکه است.

کاربران و دسترسی

whoami
id deploy
sudo adduser deploy
sudo usermod -aG sudo deploy
last -n 20
sudo lastb | head

last آخرین ورودهای موفق و lastb تلاش های ناموفق را نشان می دهد. اگر در lastb صدها تلاش ورود از آدرس های ناشناس می بینید، سرور هدف حدس رمز است؛ با کلید SSH و Fail2ban جلویش را بگیرید. چک لیست بیشتر در هاردنینگ سرور است.

بسته ها و به روزرسانی

sudo apt update && sudo apt upgrade
apt list --upgradable
dnf check-update
sudo dnf upgrade

دستورهای اول مال اوبونتو و دبیان و دسته دوم مال AlmaLinux و خانواده RHEL اند. قبل از به روزرسانی سرور تولیدی، بکاپ داشته باشید و اگر کرنل به روز می شود، ریبوت را در ساعت مناسب برنامه ریزی کنید.

چند عادت خوب

• قبل از ویرایش فایل تنظیمات یک کپی بگیرید: cp nginx.conf nginx.conf.bak.
• بعد از تغییر تنظیمات سرویس، آن را تست کنید (مثلاً nginx -t)، بعد reload کنید.
• دستورهای خطرناک را روی سرور آزمایشی تست کنید. برای دستورهای شبکه و فایروال یک جلسه SSH دوم باز نگه دارید.
• تاریخچه دستورها را با history ببینید؛ در بررسی حادثه هم مفید است.
• برای کارهای تکراری اسکریپت بنویسید و در Git نگه دارید.

ترکیب دستورها با pipe

قدرت خط فرمان در وصل کردن دستورهاست. خروجی هر دستور با علامت | ورودی بعدی می شود:

ps aux | grep nginx | grep -v grep
journalctl -u nginx --since today | grep -i error | tail -20
du -sh /var/* 2>/dev/null | sort -h | tail -5
ss -tn | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

مثال آخر IP هایی را که بیشترین اتصال را به سرور دارند فهرست می کند. اگر سرور ناگهان کند شده، یک نگاه به این خروجی نشان می دهد چند IP مشکوک بار را ایجاد کرده اند یا نه.

کار طولانی با tmux

اگر اتصال SSH قطع شود، دستوری که در آن اجرا می شد هم می میرد. tmux نشستی می سازد که بعد از قطع شدن اتصال ادامه پیدا می کند:

sudo apt install tmux
tmux new -s upgrade
# کار طولانی را اجرا کنید، بعد با Ctrl+b و بعد d جدا شوید
tmux attach -t upgrade

برای به روزرسانی بزرگ یا انتقال داده روی سرور، همیشه داخل tmux کار کنید.

زمان بندی کارها: cron و systemd timer

crontab -e
# هر شب ساعت 2:30
30 2 * * * /usr/local/bin/backup.sh
crontab -l

پنج ستون اول: دقیقه، ساعت، روز ماه، ماه و روز هفته. در ساخت کرون، مسیر کامل دستور را بنویسید، چون محیط cron مسیرهای کاربر را ندارد. خروجی خطا را هم ذخیره کنید (>> /var/log/backup.log 2>&1) وگرنه اگر شکست بخورد کسی نمی فهمد. systemd timer جایگزین مدرن cron است که لاگ بهتری در journalctl دارد. مثال کامل زمان بندی بکاپ در بکاپ گیری از سرور آمده.

پنج مشکل روزمره و دستور حل آن

اگر هیچ کدام مشکل را پیدا نکرد، نوبت مانیتورینگ و لاگ مرکزی است (نصب Grafana و Prometheus).

منابع و مستندات رسمی

• فهرست رسمی man page های لینوکس
• man page دستور chmod
• man page ساختار دایرکتوری های لینوکس (hier)

اگر ترجیح می دهید به روزرسانی، مانیتورینگ و رفع مشکل روزمره سرور را به یک تیم بسپارید، مدیریت سرور لینوکس همین کارها را پوشش می دهد. برای نصب اولیه هم نصب لینوکس روی سرور مناسب است.

نحوه تهیه مقاله ها