آموزش نصب کنترل پنل رایگان کلکسو

کلکسو (Kloxo) یک کنترل پنل رایگان لینوکسی بود که سال‌ها پیش طرفدار داشت، اما همان نسخه‌ای که آموزش‌های فارسی نصبش را توضیح می‌دهند — کلکسو ۶ و فورک Kloxo-MR — سال‌هاست وصله امنیتی نگرفته و نصب آن روی یک سرور تازه نه عملی است و نه امن. نام کلکسو با پروژه‌ای به نام Kloxo Next Generation ادامه پیدا کرده که نسخه ۸ آن روی راکی لینوکس و آلما لینوکس نصب می‌شود، ولی اگر دنبال کنترل پنل رایگان هستید پروژه‌هایی با انتشار منظم‌تر مانند HestiaCP، CyberPanel، ISPConfig یا Virtualmin انتخاب مطمئن‌تری هستند و اگر به پشتیبانی رسمی و پایداری بلندمدت نیاز دارید، دایرکت ادمین و سی پنل مسیر استاندارد به شمار می‌روند. اگر دنبال خودِ دستور نصب کلکسو روی لینوکس بوده‌اید، همان مسیر و دلیل کنار گذاشتنش را در آموزش نصب kloxo در لینوکس هم بررسی کرده‌ایم و اگر تصمیم گرفتید سراغ پنل تجاری بروید، معرفی کنترل پنل دایرکت ادمین نقطه شروع کار است. و اگر به این صفحه رسیده‌اید چون می‌خواستید Nginx را روی سرور کلکسو بالا بیاورید، روش درست امروزی آن را در بخش «اگر برای نصب Nginx روی سرور کلکسو آمده‌اید» همین مقاله آورده‌ایم.

کلکسو چه بود و چرا مسیر اصلی‌اش متوقف شد

کلکسو از دل پروژه‌ای به نام LxAdmin بیرون آمد که شرکت Lxlabs آن را در کنار سامانه مجازی‌سازی HyperVM توسعه می‌داد. در سال ۲۰۰۹ یک آسیب‌پذیری در HyperVM باعث نابودی حجم بزرگی از سرورهای مجازی چند سرویس‌دهنده شد و خودِ Lxlabs پس از آن ماجرا و درگذشت بنیان‌گذارش از هم پاشید. همین سرنوشت و اینکه امروز به جای آن باید سراغ چه مجازی‌سازی رفت، در بررسی HyperVM و جایگزین‌های امروزی مجازی‌سازی آمده است. بعد گروهی با نام LxCenter نگهداری کلکسو را به دست گرفت و نسخه ۶ را منتشر کرد، ولی آن مسیر هم ادامه پیدا نکرد و فورک جامعه‌محور Kloxo-MR هم از حدود سال ۲۰۱۷ به بعد انتشار تازه‌ای نداشته است.

دستورالعمل قدیمی نصب کلکسو، که هنوز در مقاله‌های فارسی بازنشر می‌شود، سرور را روی CentOS 5 نسخه ۳۲ بیتی می‌خواست و صراحتاً می‌گفت CentOS 6 و معماری ۶۴ بیتی پشتیبانی نمی‌شود. این فقط یک محدودیت سلیقه‌ای نیست: CentOS 5 در سال ۲۰۱۷ و CentOS 6 در سال ۲۰۲۰ به پایان چرخه پشتیبانی رسیدند، پس حتی سیستم‌عاملِ لازم برای آن دستورالعمل هم دیگر به‌روزرسانی امنیتی نمی‌گیرد. اگر امروز سرویس سرور مجازی تهیه می‌کنید، سیستم‌عاملی را انتخاب کنید که هنوز در چرخه پشتیبانی رسمی است، نه نسخه‌ای که یک آموزش قدیمی می‌خواهد. مخزن دانلود اسکریپت نصب هم منبع قابل اتکایی نیست و اجرای اسکریپت از میزبانی رهاشده خودش یک ریسک مستقل است.

یک نکته را هم شفاف بگوییم تا تصویر ناقص نماند: نام کلکسو کاملاً کنار نرفته است. گروهی با عنوان Kloxo Next Generation کد را ادامه داده‌اند و در سال ۲۰۲۴ نسخه ۸ را برای راکی لینوکس و آلما لینوکس ۸ و ۹ و CentOS Stream 9 منتشر کرده‌اند و اعلام کرده‌اند بخشی از باگ‌ها و مشکلات امنیتی کلکسوی اصلی و Kloxo-MR را هم برطرف کرده‌اند. پس دقیق‌تر آن است که بگوییم آنچه از کار افتاده، کلکسوی نسخه ۶ و Kloxo-MR است؛ یعنی دقیقاً همان چیزی که آموزش‌های قدیمی فارسی نصبش را یاد می‌دهند. اگر به سراغ Kloxo 8 می‌روید، پیش از تکیه بر آن تاریخ آخرین انتشار و میزان فعالیت پروژه را روی سایت رسمی خودش ببینید؛ فاصله میان نسخه‌های این مسیر کوتاه نبوده است.

ریسک واقعی اجرای یک پنل رهاشده

• وصله نشدن آسیب‌پذیری‌ها: در پروژه‌ای که نگهداری نمی‌شود، باگ امنیتی کشف‌شده هرگز اصلاح نمی‌شود ولی جزئیاتش عمومی می‌شود؛ یعنی مهاجم نقشه راه دارد و شما وصله ندارید.
• اجرا با بالاترین سطح دسترسی: هر کنترل پنلی برای ساخت کاربر و پیکربندی سرویس‌ها با دسترسی root کار می‌کند. یک نقص در پنل یعنی تصرف کل سرور، نه فقط یک سایت.
• رابط مدیریتی بدون رمزنگاری: پورت پیش‌فرض ۷۷۷۸ کلکسو روی HTTP ساده باز می‌شد و نام کاربری و رمز مدیر رمزنگاری‌نشده رد و بدل می‌شد.
• اعتبار پیش‌فرض شناخته‌شده: نام کاربری و رمز اولیه admin بود و اسکنرهای خودکار دقیقاً همین ترکیب را روی پورت‌های شناخته‌شده امتحان می‌کنند.
• ناسازگاری با نرم‌افزار امروز: نسخه‌های PHP و MySQL آن دوره برای وردپرس امروزی کافی نیستند و TLS 1.3، HTTP/2 و صدور خودکار گواهی با پروتکل ACME هم در چنین پشته‌ای وجود ندارد.

اگر سروری همین حالا با کلکسوی نسخه ۶ یا Kloxo-MR کار می‌کند، منطقی‌ترین کار مهاجرت است، نه به‌روزرسانی درجا.

منطق مشترک نصب هر کنترل پنل

روش نصب پنل‌ها در جزئیات فرق دارد، اما چارچوب کار یکسان است و با دانستن آن، دستورالعمل رسمی هر پروژه برایتان قابل فهم می‌شود:

• سرور تازه و تمیز: تقریباً همه پنل‌ها انتظار نصب خام دارند و روی سروری که قبلاً پنل یا وب‌سرور دستی دارد درست کار نمی‌کنند؛ کار را با یک سرور تازه نصب‌شده و بدون سرویس اضافی شروع کنید.
• سیستم‌عامل پشتیبانی‌شده: فهرست توزیع‌ها و نسخه‌های مجاز را فقط از مستندات رسمی همان پنل بردارید؛ این فهرست مرتب تغییر می‌کند.
• نام میزبان معتبر: یک FQDN مثل srv1.example.com تنظیم کنید که رکورد DNS آن به آی‌پی سرور اشاره کند؛ بسیاری از خطاهای نصب ریشه در همین یک مورد دارند.
• دسترسی و پیش‌نیازها: با SSH و کاربر root وارد شوید، سیستم را با dnf update (در توزیع‌های قدیمی‌تر خانواده رد هت yum update) یا apt update && apt upgrade به‌روز کنید و اسکریپت نصب را فقط از دامنه رسمی پروژه بگیرید.
• سخت‌سازی بعد از نصب: رمز پیش‌فرض را همان دقیقه اول عوض کنید، ورود با کلید SSH را جایگزین رمز کنید (پیش از بستن ورود با رمز، حتماً در یک نشست جداگانه ورود با کلید را آزمایش کنید تا پشت در نمانید)، پورت پنل را به آی‌پی‌های مدیریتی محدود کنید، گواهی معتبر بگیرید و پشتیبان‌گیری خودکار را پیش از آمدن داده واقعی فعال کنید.

اگر برای نصب Nginx روی سرور کلکسو آمده‌اید

یکی از پرتکرارترین کارهایی که مدیران سرورهای کلکسو دنبالش بودند، نشاندن Nginx به جای Apache یا جلوی آن بود. آموزش‌های آن دوره می‌گفتند با دسترسی root به سرور وصل شو، سرویس httpd را متوقف کن، بسته nginx-0.8.33 را دانلود و باز کن، با یک خط ./configure بسیار طولانی کامپایلش کن و بعد با /etc/init.d/nginx start اجرایش کن. امروز تک‌تک این مرحله‌ها ایراد دارد؛ اگر عیناً اجرایشان کنید به وب‌سروری می‌رسید که نه HTTPS دارد، نه PHP را اجرا می‌کند و نه وصله امنیتی می‌گیرد.

ایرادهای آن دستورالعمل قدیمی

• نسخه بسیار قدیمی: شاخه ۰.۸ انجین‌ایکس مربوط به حدود سال ۲۰۱۰ است و سال‌هاست پشتیبانی نمی‌شود. نسخه‌ای که با یک آدرس ثابت دانلود می‌کنید هیچ‌وقت به‌روز نمی‌شود.
• کامپایل دستی: باینری‌ای که خودتان از سورس می‌سازید در پایگاه بسته‌های سیستم ثبت نمی‌شود؛ یعنی نه dnf update و نه apt upgrade وصله امنیتی‌اش را می‌آورد و هر ارتقا دوباره کار دستی است.
• ماژول‌های حذف‌شده: آن خط طولانی configure با --without-http_rewrite_module و --without-pcre بازنویسی آدرس را حذف می‌کند (یعنی پیوندهای یکتای وردپرس کار نمی‌کنند)، با --without-http_fastcgi_module راه اتصال به PHP-FPM را می‌بندد، با --without-http_gzip_module فشرده‌سازی و با --without-http_access_module محدودسازی بر اساس آی‌پی را از دست می‌دهد. نتیجه، وب‌سروری است که برای میزبانی وب معمولی به درد نمی‌خورد.
• نبود پشتیبانی SSL: در آن خط --with-http_ssl_module اصلاً نیامده، پس Nginx بدون توانایی سرو کردن HTTPS ساخته می‌شود. سوئیچ --with-openssl هم مسیر سورس OpenSSL را می‌خواهد، نه مسیری مثل /usr/lib/openssl؛ به‌علاوه در حالت عادی اصلاً لازم نیست و Nginx به OpenSSL سیستم لینک می‌شود.
• اسکریپت راه‌اندازی: دستور make install فایل /etc/init.d/nginx نمی‌سازد؛ آن فایل از بسته توزیع می‌آید. پس chmod 755 /etc/init.d/nginx بعد از یک نصب سورسی روی فایلی اجرا می‌شود که وجود ندارد.
• ویرایش «خط ۳۲»: در بسته‌های امروزی خط include /etc/nginx/conf.d/*.conf; از پیش داخل nginx.conf هست و شماره خطش هم ثابت نیست. به جای شمردن خط، فایل را بخوانید و درستی پیکربندی را با nginx -t بسنجید. ضمناً نصب سورسی به‌طور پیش‌فرض در /usr/local/nginx می‌نشیند، نه /etc/nginx.

روش درست امروز

Nginx را با کاربر root (یا با sudo) از مخزن توزیع یا مخزن رسمی nginx.org نصب کنید تا هم نسخه پشتیبانی‌شده بگیرید و هم به‌روزرسانی امنیتی از مسیر عادی سیستم برسد. فقط خط مربوط به توزیع خودتان را اجرا کنید، نه هر دو خط را؛ و اگر روی همین سرور از قبل Apache یا وب‌سرور دیگری پورت ۸۰ را در اختیار دارد، پیش از اجرا بخش بعدی را بخوانید، چون سرویس Nginx با خطای اشغال بودن پورت بالا نمی‌آید:

dnf install nginx                  # AlmaLinux / Rocky / RHEL
apt update && apt install nginx    # Debian / Ubuntu
systemctl enable --now nginx
nginx -v

برای اینکه مطمئن شوید Nginx واقعاً بالا آمده و پاسخ می‌دهد، خروجی systemctl status nginx را ببینید و بعد روی خود سرور curl -I http://127.0.0.1 بگیرید یا آی‌پی سرور را در مرورگر باز کنید؛ باید صفحه خوش‌آمد پیش‌فرض Nginx یا هدر Server: nginx را ببینید. اگر سرویس بالا نیامد، شایع‌ترین علت این است که وب‌سرور دیگری پورت ۸۰ را گرفته است.

مدیریت سرویس‌ها هم دیگر با service و /etc/init.d/ انجام نمی‌شود؛ در توزیع‌های اصلی امروزی (رد هت، آلما لینوکس، راکی لینوکس، دبیان و اوبونتو) systemd این کار را بر عهده دارد و آن دستورهای قدیمی حداکثر به شکل یک لایه سازگاری کار می‌کنند. معادل‌های امروزیِ دستورهای آن آموزش این‌هاست (نام سرویس Apache در خانواده رد هت httpd و در دبیان و اوبونتو apache2 است). یک هشدار پیش از اجرا: متوقف کردن Apache روی یک سرور فعال، همان لحظه همه سایت‌های آن سرور را از دسترس خارج می‌کند؛ پس این خط‌ها را یک‌جا کپی نکنید، فقط دستور مربوط به توزیع و وضعیت خودتان را در بازه کم‌ترافیک و با پشتیبان آماده اجرا کنید، و اگر روی سرور کنترل پنل نصب است اصلاً از این مسیر نروید و بخش بعدی را بخوانید:

systemctl stop httpd      # به جای service httpd stop
systemctl stop apache2    # روی دبیان و اوبونتو
systemctl start nginx     # به جای /etc/init.d/nginx start
systemctl status nginx

Apache و Nginx نمی‌توانند هم‌زمان پورت ۸۰ را بگیرند؛ برای همین بود که آن آموزش اول httpd را متوقف می‌کرد. امروز دو انتخاب دارید: یا Apache را کنار می‌گذارید و Nginx تنها وب‌سرور می‌شود، یا Apache را روی یک پورت داخلی مثل ۸۰۸۰ می‌برید و Nginx را جلویش به عنوان reverse proxy می‌نشانید تا کش و TLS و فایل‌های ایستا با Nginx و اجرای PHP با Apache باشد. پیش از هر systemctl reload nginx هم حتماً nginx -t بگیرید تا سرویس با پیکربندی خراب از دسترس خارج نشود.

روی سروری که کنترل پنل دارد، از خود پنل استفاده کنید

مهم‌ترین نکته همین است و در آموزش‌های قدیمی گم شده بود: وقتی یک کنترل پنل روی سرور نشسته، فایل‌های vhost و تنظیمات SSL را خود پنل تولید و بازتولید می‌کند. اگر کنارش یک Nginx کامپایل‌شده دستی بگذارید، یا پنل در اولین بازسازی پیکربندی، تنظیمات شما را پاک می‌کند یا سایت‌ها و تمدید خودکار گواهی بی‌سروصدا از کار می‌افتند. پنل‌های امروزی خودشان انتخاب وب‌سرور را در اختیارتان می‌گذارند: HestiaCP هم حالت Nginx تنها و هم Nginx جلوی Apache را دارد، CyberPanel روی OpenLiteSpeed بنا شده، دایرکت ادمین وب‌سرور را با ابزار CustomBuild عوض می‌کند و سی پنل هم بسته رسمی Nginx را برای حالت reverse proxy ارائه می‌دهد. مسیر درست، دنبال کردن مستندات همان پنل است، نه کامپایل دستی روی سروری که مدیریتش دست پنل است.

کنترل پنل‌های رایگانی که هنوز نگهداری می‌شوند

«رایگان» لزوماً به معنای بی‌کیفیت نیست، اما یعنی بار نگهداری و رفع مشکل روی دوش خودتان است. گزینه‌های زیر برخلاف کلکسوی نسخه ۶ و Kloxo-MR هنوز به‌طور منظم نسخه و وصله منتشر می‌کنند:

• HestiaCP — فورک فعال VestaCP روی دبیان و اوبونتو؛ سبک و مناسب چند سایت روی یک سرور کوچک و با امکان انتخاب Nginx به‌تنهایی یا Nginx جلوی Apache.
• CyberPanel — بر پایه OpenLiteSpeed با ابزارهای کش و مدیریت وردپرس؛ برای کسانی که کارایی وب‌سرور برایشان مهم است.
• ISPConfig — پروژه‌ای قدیمی و پایدار که مدیریت چند سرور از یک رابط را هم پوشش می‌دهد.
• Webmin و Virtualmin — نزدیک‌تر به مدیریت سیستم‌عامل تا میزبانی وب؛ برای مدیرانی که دسترسی مستقیم به همه سرویس‌ها می‌خواهند.
• aaPanel — نصب سریع و رابط ساده؛ برای سرورهای تک‌منظوره و محیط‌های آزمایشی گزینه رایجی است.

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

وقتی پنل تجاری انتخاب منطقی‌تری است

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

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

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

مهاجرت از یک سرور قدیمی کلکسو

مهاجرت را به صورت «ساخت دوباره» انجام دهید، نه ارتقای درجا. سرور مقصد را با سیستم‌عامل و پنل تازه بالا بیاورید، از دیتابیس‌ها با mysqldump خروجی بگیرید، فایل‌ها را با rsync یا tar منتقل کنید و اکانت‌های ایمیل و رکوردهای DNS را دستی بازسازی کنید؛ خروجی پشتیبان پنل قدیمی معمولاً با پنل‌های امروزی سازگار نیست. اگر روی سرور قدیمی وب‌سرور یا ماژولی را دستی کامپایل کرده بودید، آن را به سرور جدید نبرید؛ معادل بسته‌ای و پشتیبانی‌شده‌اش را از پنل جدید فعال کنید. بعد سایت‌ها را پیش از تغییر DNS تست کنید، سپس TTL را کم کرده و رکوردها را جابه‌جا کنید و سرور قدیمی را تا اطمینان از پایداری سرور جدید روشن نگه دارید.

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

جمع‌بندی

هدف مقاله قدیمی «نصب رایگان یک کنترل پنل» بود و آن هدف هنوز شدنی است؛ فقط ابزارش عوض شده. کلکسویی که آن آموزش‌ها توضیح می‌دهند امروز نه روی سیستم‌عامل‌های پشتیبانی‌شده نصب می‌شود و نه اگر بشود باید نصب شود؛ ادامه‌دهنده‌اش Kloxo 8 وجود دارد، ولی پیش از انتخاب آن باید فعال بودن پروژه را خودتان بررسی کنید. ساده‌تر و مطمئن‌تر این است که یک پنل رایگانِ فعال انتخاب کنید یا اگر کارتان تجاری است سراغ دایرکت ادمین و سی پنل بروید. همین منطق درباره وب‌سرور هم صادق است: به جای کامپایل دستی Nginx، آن را از مخزن رسمی یا از خود پنل فعال کنید. در هر دو حالت اصول ثابت را رعایت کنید: سیستم‌عامل پشتیبانی‌شده، بسته‌های نصب‌شده از مخزن معتبر، رمز پیش‌فرض عوض‌شده و پشتیبان آزموده‌شده.