وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

رفع خطای suPHP_UserGroup و بررسی مدل اجرای PHP

این خطا به تنظیم‌های suPHP مربوط است و نباید با دادن دسترسی 777 پنهان شود. بسیاری از نصب‌های فعلی از PHP-FPM یا روش دیگری استفاده می‌کنند.

انتشار:
آخرین ویرایش:
توسط مصطفی جانقربان
۴ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله رفع خطای suPHP_UserGroup و بررسی مدل اجرای PHP در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
PHP برنامه‌ای است که کد سایت‌هایی مثل وردپرس را اجرا می‌کند. suPHP یکی از روش‌های قدیمی‌تر اجرای آن است. بنابراین وقتی در خطا نام suPHP_UserGroup می‌آید، باید اول بدانیم سرور شما واقعاً از همین روش استفاده می‌کند یا یک تنظیم قدیمی از آن باقی مانده است.

پیدا کردن همان خطی که به خطا مربوط است

مدیر سرور، پیام کامل خطا را در گزارش وب‌سرور می‌خواند. اگر پیام، نام فایل و شمارهٔ خط را نشان می‌دهد، همان فایل را باز می‌کند و چند خط اطراف آن را می‌بیند. برای مثال، تنظیمی که به کاربر حذف‌شده اشاره می‌کند باید با حساب واقعی صاحب سایت اصلاح شود؛ ساختن یک کاربر تصادفی فقط برای خاموش شدن خطا، مشکل مالکیت را حل نمی‌کند.
اگر سرور اکنون PHP-FPM دارد و تنها یک تنظیم قدیمی suPHP باقی مانده، باید آن تنظیم در الگوی مربوط به همان سایت اصلاح شود. اگر سرور هنوز suPHP دارد، نام کاربر و گروه باید با حساب موجود مطابقت داشته باشد. این تصمیم به نصب واقعی بستگی دارد؛ به همین دلیل یک خط ثابت برای کپی روی همهٔ سرورها درست نیست. کاربر هاست می‌تواند نام سایت، ساعت خطا و متن پیام را به میزبان بدهد تا مدیر همان تنظیم مشخص را اصلاح کند.

خطا از کدام درخواست آمده است؟

نام دامنه، زمان درخواست و مسیر صفحه را ثبت کنید. لاگ وب‌سرور همان زمان را بخوانید و ببینید پیام به کدام virtual host و فایل تنظیم اشاره می‌کند. اگر فقط یک دامنه خطا دارد، ویرایش تنظیم سراسری همهٔ سایت‌ها می‌تواند دامنهٔ مسئله را بی‌دلیل گسترش دهد.
نسخهٔ PHP و handler فعال را از پنل و تنظیم مؤثر بررسی کنید. وجود نام suPHP در یک فایل قدیمی، اثبات نمی‌کند همان handler اکنون استفاده می‌شود. ممکن است پس از انتقال یا تغییر PHP، بخشی از تنظیم قبلی باقی مانده باشد.

مالکیت و تنظیم برنامه

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

رفع علت به‌صورت محدود

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

آزمون پس از اصلاح

همان URL خطادار را باز کنید و سپس یک صفحهٔ PHP دیگر، فایل ثابت و فرم برنامه را امتحان کنید. نتیجهٔ فایل ثابت با PHP فرق دارد؛ سالم بودن تصویر یا HTML ثابت اثبات نمی‌کند اجرای PHP درست شده است. لاگ تازه را نیز بخوانید تا خطای قبلی با خطای جدید جایگزین نشده باشد.
اگر فقط یک کاربر هاست هستید، متن خطا و مسیر دقیق را به میزبان بدهید و فایل‌های سرور را با حدس تغییر ندهید. اطلاعات مشخص کمک می‌کند مدیر، مدل اجرا و مالکیت همان حساب را بررسی کند و مشکل را بدون دستکاری حساب‌های سالم برطرف کند.

منابع و ادامهٔ مطالعه

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام