رفع مشکل suspend شدن اکانت در دایرکت ادمین

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

در حالت suspend دقیقاً چه چیزی قطع می‌شود

وقتی دایرکت‌ادمین کاربری را معلق می‌کند، سایت از دسترس خارج می‌شود و بازدیدکننده به‌جای صفحه اصلی یک صفحه تعلیق یا خطای دسترسی می‌بیند، ورود به کنترل پنل و FTP بسته می‌شود و ایمیل‌ها هم تحویل داده نمی‌شوند. اگر ایمیل همهٔ اکانت‌های سرور با هم قطع شده و فقط یک کاربر گرفتار نیست، ماجرا تعلیق نیست و باید سراغ علت start نشدن سرویس exim در دایرکت ادمین بروید. اما هیچ فایلی حذف نمی‌شود؛ کل محتوای /home/<user> و دیتابیس‌ها سر جای خودشان هستند. تعلیق وضعیتی کاملاً برگشت‌پذیر است، پس اولین کاری که نباید انجام دهید حذف و ساخت دوباره اکانت است.

پنج دلیل رایج تعلیق اکانت

• اتمام پهنای باند: اگر مصرف ترافیک ماهانه از سقف بسته عبور کند و سرور طوری پیکربندی شده باشد که در سقف مصرف، کاربر را خودکار معلق کند، تعلیق انجام می‌شود. نکته‌ای که اغلب از قلم می‌افتد این است که سقف پهنای باند نماینده فروش (reseller) مالک آن کاربر هم می‌تواند باعث تعلیق همه زیرمجموعه‌هایش شود.
• پر شدن فضای دیسک: رسیدن به سهمیه (quota) معمولاً اول باعث خطای نوشتن در دیتابیس و آپلود می‌شود و بسته به تنظیمات سرور می‌تواند به تعلیق هم برسد.
• اقدام دستی ادمین یا نماینده: در هاست اشتراکی منابع سرور بین چند سایت تقسیم می‌شود؛ به همین دلیل اگر یک اکانت مصرف غیرعادی داشته باشد، ادمین یا نماینده فروش می‌تواند آن را دستی معلق کند.
• مسائل مالی: اگر سیستم صورت‌حساب (مثلاً WHMCS) به دایرکت‌ادمین متصل باشد، پس از گذشتن از مهلت پرداخت فاکتور، ماژول صورت‌حساب خودش دستور تعلیق را به پنل می‌فرستد.
• تخلف یا ارسال هرزنامه: اگر اسکریپت آسیب‌پذیری آلوده شود و از آن ایمیل انبوه برود، برای نجات اعتبار آی‌پی سرور، اکانت سریع معلق می‌شود.

چطور بفهمیم کدام دلیل بوده است

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

اگر به SSH دسترسی دارید، سریع‌ترین راه خواندن مستقیم فایل پیکربندی کاربر است:

grep -E 'suspended|bandwidth|quota' /usr/local/directadmin/data/users/USERNAME/user.conf

مقدار suspended=yes یعنی اکانت در وضعیت تعلیق است و با رفع تعلیق به suspended=no برمی‌گردد. برای دیدن مصرف واقعی همان کاربر:

cat /usr/local/directadmin/data/users/USERNAME/user.usage

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

grep -i suspend /var/log/directadmin/system.log | tail -n 20

در system.log دستورهای اجراشده در پنل همراه با نام کاربر اجراکننده و زمان ثبت می‌شوند؛ اگر تعلیق دستی یا از طریق API سیستم صورت‌حساب انجام شده باشد، ردش همین‌جاست. برای موارد مربوط به ایمیل هم شمارنده ارسال هر کاربر در مسیر /etc/virtual/usage/ نگهداری می‌شود. توجه کنید که دایرکت‌ادمین فقط روی سیستم‌عامل‌های لینوکسی اجرا می‌شود و برای استفاده از آن روی سرور مجازی یا اختصاصی به لایسنس دایرکت‌ادمین نیاز دارید.

خارج کردن اکانت از حالت تعلیق

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

از داخل پنل، در سطح ادمین یا نماینده کاربر را از فهرست انتخاب و گزینه Unsuspend را اجرا کنید. از خط فرمان و با کاربر root هم همین کار با خودِ باینری دایرکت‌ادمین انجام می‌شود:

/usr/local/directadmin/directadmin unsuspend-user --user=USERNAME

روی نسخه‌هایی که میان‌بر da نصب است، شکل کوتاه‌تر همین دستور کار می‌کند:

da unsuspend-user --user=USERNAME

هشدار مهم: مقدار suspended را مستقیماً داخل user.conf ویرایش نکنید. تعلیق و رفع تعلیق چند کار همزمان است (تغییر پیکربندی وب‌سرور، قفل‌کردن رمز کاربر سیستمی و به‌روزرسانی تنظیمات ایمیل) و دستکاری دستی فایل، اکانت را در وضعیتی نیمه‌کاره رها می‌کند که عیب‌یابی‌اش از خود مشکل اول سخت‌تر است؛ نتیجهٔ رایج همین دست‌بردن‌ها، ناهماهنگی رکورد پنل با کاربر سیستمی و ظاهر شدن خطای User does not exist on the system است.

اگر ارقام مصرف با واقعیت نمی‌خواند (مثلاً فایل‌های حجیم را پاک کرده‌اید ولی سهمیه هنوز پر نشان داده می‌شود)، محاسبه مصرف را دوباره در صف کارهای دایرکت‌ادمین بگذارید:

echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue

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

/usr/local/directadmin/dataskq d80

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

مورد خاص: تعلیق مکرر بدون علت ظاهری

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

برای اصلاح، وارد پنل کاربری شوید، به بخش Domain Setup بروید، روی نام دامنه کلیک کنید، برای گزینه Bandwidth تیک Same as Main Account را فعال کنید و تغییرات را ذخیره نمایید. با این کار سقف دامنه به سقف کل اکانت گره می‌خورد و دیگر مستقل از آن پر نمی‌شود. همزمان یادتان باشد پهنای باند نماینده فروش بالادستی را هم بررسی کنید.

چطور از تکرار جلوگیری کنیم

هشدار پیش از سقف را روشن کنید. دایرکت‌ادمین می‌تواند پیش از رسیدن مصرف به سقف، به کاربر و ادمین ایمیل هشدار بدهد؛ آستانه این هشدار در تنظیمات سطح ادمین قابل تعیین است و متن آن هم از قالب‌های user_limit.txt و reseller_limit.txt خوانده می‌شود. رسیدن یک ایمیل هشدار خیلی بهتر از دیدن صفحه تعلیق است.

فضای اشغال‌شده را دوره‌ای مرور کنید. برای پیدا کردن پرحجم‌ترین پوشه‌ها:

du -sh /home/USERNAME/* | sort -h

معمول‌ترین متهم‌ها بکاپ‌های قدیمی در /home/USERNAME/backups، لاگ‌های دامنه در /home/USERNAME/domains/DOMAIN/logs، فایل‌های error_log داخل public_html و پوشه‌های Trash و Junk صندوق‌های ایمیل هستند. پیش از حذف هر چیزی از این مسیرها مطمئن شوید نسخه پشتیبان سالمی بیرون از سرور دارید؛ فایل حذف‌شده با rm برنمی‌گردد.

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

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

جمع‌بندی

تعلیق در دایرکت‌ادمین یک هشدار است، نه خرابی. مسیر درست همیشه یکی است: تشخیص علت از روی user.conf، user.usage و system.log، رفع همان علت، و بعد خارج‌کردن اکانت از تعلیق. اگر تعلیق‌ها تکرار می‌شوند، تقریباً همیشه پای یک سقف فراموش‌شده یا رشد واقعی مصرف در میان است.