logo-white.webp
Вход
Февруари 24, 2026

Интеграция с контролен панел

 

Въведение

Ако разработвате или използвате контролен панел и искате той да работи добре с CloudLinux OS, имате няколко начина да го направите:

✅ Препоръчано: Пълна интеграция чрез новия API

Това е най-добрият и препоръчван начин. Така контролният панел ще поддържа всички функции на CloudLinux OS – както настоящите, така и бъдещите. Получавате пълна съвместимост и техническа поддръжка от CloudLinux.

⚠️ Алтернативен: Ръчна интеграция чрез CLI инструменти

Тук панелът използва ниско-ниво команди (като lvectl) за ръчно управление на ресурсите. Това не се препоръчва – трудно е за поддръжка, обхваща ограничени функции и не се обновява автоматично при промени в CloudLinux.

❌ Стар API (Deprecated)

Старият метод на интеграция все още работи, но не се поддържа и не се обновява. Не е добра идея да го използвате.

 

Новият API – Как работи?

Новият API цели да улесни интеграцията – вместо панелът да контролира всичко, CloudLinux OS поема тази роля чрез свой интерфейс и помощни инструменти.

Интеграцията се състои от няколко основни стъпки:

  • Панелът трябва да създаде 7 прости скрипта, които CloudLinux ще извиква, за да получава информация като списък с потребители, домейни, хостинг планове и др.

  • При промени в панела (напр. нов потребител, редакция на домейн) – панелът трябва да извика специални “куки” (hooks), за да уведоми CloudLinux, който ще се преконфигурира автоматично.

  • Координация с CageFS – изисква се лека конфигурация, за да работят двете системи заедно.

  • (По избор) Вграждане на CloudLinux интерфейса в контролния панел – силно препоръчано, тъй като позволява лесен достъп до мениджъра на лимити (LVE Manager) и PHP версиите (PHP Selector).

 

🗂️ Общи изисквания и структура

За да работи интеграцията:

  • Контролният панел трябва да предостави скриптовете (CPAPI) и конфигурационен .ini файл.

  • Препоръчва се скриптовете да се намират в /opt/cpvendor/bin/ – така ще работят автоматично и с CageFS.

  • Всички потребители трябва да имат достъп за четене до конфигурационния файл /opt/cpvendor/etc/integration.ini, защото част от функциите се използват и от крайни потребители.

CloudLinux само чете този файл – не го променя и не го създава автоматично.

 

📦 Препоръка за доставчици на панели

  • Най-добрата практика е да опаковате скриптовете и конфигурационния файл в отделен RPM пакет.

  • Това улеснява актуализациите и ви позволява да ги разпространявате независимо от самия контролен панел.

  • Можете да настроите зависимостите (dependencies) така, че при нужда от нова версия на API, системата автоматично да я инсталира.

 

🔄 Версиониране и съвместимост

CloudLinux предоставя текущата версия на API-то чрез “Provides public_cp_vendors_api = VERSION” в техните пакети.

Ако вашият панел има нужда от конкретна версия, можете да зададете в RPM спецификацията:

Conflicts: public_cp_vendors_api < VERSION

 

Това гарантира, че ще се използва съвместима версия и ще се избегнат конфликти между вашите скриптове и CloudLinux.

 

Промени и нововъведения (Changelog)

🔄 Версия 1.4 — Добавена поддръжка за AccelerateWP

  • CloudLinux вече поддържа AccelerateWP интеграция с контролни панели.

  • Ново поле Provides public_cp_vendors_api = 1.4 е добавено в RPM пакета alt-python27-cllib. Това показва, че скриптовете ви поддържат новата версия на API-то.

  • Нов флаг accelerate_wp може да бъде добавен във panel_info скрипта, за да показва, че вашият контролен панел поддържа AccelerateWP.

  • Добавен е нов скрипт php, нужен за AccelerateWP.

  • В скрипта domains са добавени нови полета:

  • php_version_id — показва конкретната PHP версия

  • handler — информация за PHP handler (например LSAPI, PHP-FPM)

📌 За да поддържате AccelerateWP:

  • трябва да добавите скрипт php,

  • да следвате инструкциите за интеграция с X-Ray,

  • и да добавите полето php_version_id в domains.

 

🔄 Версия 1.3 — Поддръжка за CloudLinux Wizard

  • Добавена поддръжка за CloudLinux Wizard.

  • Нов флаг wizard в скрипта panel_info, за да покажете, че вашият панел поддържа Wizard.

  • Добавено е Provides public_cp_vendors_api = 1.3 в RPM-а.

 

🔄 Версия 1.2 — Поддръжка за X-Ray

  • Добавена възможност за интеграция с X-Ray UI.

  • Скриптът domains вече поддържа флаг –with-php, който е нужен за X-Ray.

  • В panel_info можете да добавите флаг xray, за да активирате X-Ray в интерфейса.

 

🔄 Версия 1.1 — Нови възможности за UI

  • Нов ключ supported_cl_features в panel_info, чрез който указвате кои CloudLinux функции искате да се виждат (например LVE Manager, Wizard и др.)

  • Добавено е Provides public_cp_vendors_api = 1.1.

 

🧩 Пример за конфигурационен файл (integration.ini)

 

[integration_scripts]

panel_info = /opt/cpvendor/bin/panel_info

db_info = /opt/cpvendor/bin/db_info

packages = /opt/cpvendor/bin/packages

users = /opt/cpvendor/bin/users

domains = /opt/cpvendor/bin/vendor_integration_script domains

resellers = /opt/cpvendor/bin/vendor_integration_script resellers

admins = /opt/cpvendor/bin/vendor_integration_script admins

php = /opt/cpvendor/bin/vendor_integration_script php

 

[lvemanager_config]

ui_user_info = /panel/path/ui_user_info.sh

base_path = /panel/path/lvemanager

run_service = 1

service_port = 9000

use_ssl = 1

ssl_cert = /path/to/domain_srv.crt

ssl_key = /path/to/domain_srv.key

 

🔗 Интеграция с Control Panel API (CPAPI)

За да свържете панела си с CloudLinux, трябва:

  • Да настроите пътищата към скриптовете в integration.ini в секцията [integration_scripts].

  • Всеки скрипт трябва да връща валиден JSON, когато бъде извикан с определени аргументи.

Може да имате:

  • Отделен скрипт за всяка функция, или

  • Един общ скрипт, който приема различни аргументи (пример: vendor_integration_script domains).

 

📌 Изисквания към скриптовете

Скрипт Задължителен? Достъп от Работи ли в CageFS?
panel_info Да Всички потребители ✅
db_info Само ако използвате LVE-Stats Само root ❌
packages За лимити Само root ❌
users Да Само root ❌
domains Да (Selectors/X-Ray) Всички потребители Частично
resellers Да Само root ❌
admins Да Само root ❌
php За AccelerateWP Само root ❌

 

⚠️ Сигурност при изпълнение на скриптове

Когато CloudLinux стартира скрипт (особено ако е написан на Python), трябва да сте внимателни – някои интерпретатори позволяват изпълнение на произволен код още преди главната логика на скрипта. Това може да даде възможност на потребители да заобиколят CageFS и да достъпят чувствителни системни файлове.

➡️ Уверете се, че вашите скриптове не съдържат риск от такова поведение.

Ако не сте сигурни – обърнете се към CloudLinux поддръжка.

Работа със CPAPI и CageFS

Някои от интеграционните скриптове (например domains, panel_info и др.) не се изпълняват само от root, а понякога и директно от крайния потребител (end-user). Затова при разработка е важно да имаш предвид следното:

 

🔐 CageFS може да е включен, но може и да не е!

Твоите скриптове трябва да работят коректно:

  • ако CageFS е включен за потребителя

  • ако CageFS е изключен

  • ако въобще не е инсталиран

 

🛠 Как да осигуриш съвместимост?

Имаш 3 варианта:

✅ 1. Всичко необходимо трябва да е достъпно за потребителя

  • Скриптът, всички библиотеки, конфигурации, помощни програми, кешове и т.н.

  • Ако това е изпълнимо — супер, най-лесният път.

 

⚙️ 2. Използвай proxyexec от CageFS

  • Това изпълнява скрипта извън CageFS, но като потребителя, запазвайки ограниченията.

  • Подходящо, ако не искаш да дублираш файлове в CageFS.

 

🔐 3. Използвай комбинация от sudo и proxyexec

  • Ако скриптът трябва да чете чувствителни файлове или данни, които не са достъпни за обикновен потребител — използвай sudo.

  • sudo работи, дори и когато CageFS не е инсталиран или е изключен.

  • proxyexec е нужен, когато потребителят е в CageFS.

Примерен wrapper скрипт:

 

#!/usr/bin/env bash

sudo /opt/cpvendor/bin/domains_real

 

Важно! Конфигурирай /etc/sudoers така, че sudo:

  • да работи без парола

  • да има точен контрол върху какво се изпълнява

 

⚠️ Важно предупреждение!

Ако използваш sudo, трябва да включиш NOSETENV в /etc/sudoers, за да не могат потребителите да променят променливите на средата и да заобикалят ограниченията.

 

📦 Защо препоръчваме sudo вместо SUID?

  • sudo има вградени логове

  • По-сигурен е

  • По-лесно се следят грешки

 

🔁 Формат на отговор от скриптовете

Всички скриптове трябва да връщат JSON, кодиран в UTF-8.

 

✅ Успешен отговор:

 

{

  “data”: [или обект],

  “metadata”: {

    “result”: “ok”

  }

}

 

❌ Грешки — възможни видове:

🧱 Вътрешна грешка (например: паднала база данни)

 

{

  “data”: null,

  “metadata”: {

    “result”: “InternalAPIError”,

    “message”: “API is restarting, try again later”

  }

}

 

⛔ Достъпът е отказан (потребител се опитва да види чужди данни)

 

{

  “data”: null,

  “metadata”: {

    “result”: “PermissionDenied”,

    “message”: “Only sudoers can view this section.”

  }

}

 

🔒 Пример: ако user1 изпълни domains –owner=user2 — трябва да върнеш точно тази грешка.

Грешка при невалидни аргументи

Ако потребителят подаде грешни аргументи към някой от скриптовете (например непозната опция или неправилно поле), скриптът трябва да върне следния JSON:

 

{

  “data”: null,

  “metadata”: {

    “result”: “BadRequest”,

    “message”: “Unknown field ‘nosuchfield’”

  }

}

 

🔎 Пример кога става това:

  • Използвано е поле, което не съществува: –fields=nosuchfield

  • Подаден е напълно непознат аргумент

 

🚫 Несъществуваща стойност (потребител, домейн и др.)

Когато скриптът търси нещо (напр. потребител или домейн), но то не съществува в панела, се връща:

 

{

  “data”: null,

  “metadata”: {

    “result”: “NotFound”,

    “message”: “No such user `unix_user_name`”

  }

}

 

📝 Важно: Това се използва само при заявки с филтър — например: –user=username, и потребителят не е намерен.

Ако няма никакви данни (например списък с домейни е празен), върни просто празен списък, не грешка.

 

📜 Списък с нужните интеграционни скриптове:

Скрипт Какво прави
panel_info Информация за контролния панел и неговите възможности
db_info Информация за бази данни (използва се при LVE-Stats)
packages Списък с хостинг пакети и техните ограничения
users Списък с потребители на сървъра
domains Домейни, свързани с потребители
resellers Реселъри, ако има такива
admins Администратори на контролния панел
php Информация за PHP версии (AccelerateWP и др.)

 

🧾 Примерен panel_info отговор

 

{

  “data”: {

    “name”: “SomeCoolWebPanel”,

    “version”: “1.0.1”,

    “user_login_url”: “https://{domain}:1111/”,

    “supported_cl_features”: {

      “php_selector”: true,

      “ruby_selector”: true,

      “python_selector”: true,

      “nodejs_selector”: false,

      “mod_lsapi”: true,

      “mysql_governor”: true,

      “cagefs”: true,

      “reseller_limits”: true,

      “xray”: false,

      “accelerate_wp”: false,

      “autotracing”: true

    }

  },

  “metadata”: {

    “result”: “ok”

  }

}

 

🧠 Какво ни казва това?

  • Панелът се казва SomeCoolWebPanel, версия 1.0.1

  • Поддържа PHP, Ruby, Python селектори, CageFS, reseller лимити и др.

  • Не поддържа Node.js и X-Ray

  • AccelerateWP е изключен

Описание на данните (data description)

🔑 Основни ключове в panel_info скрипта:

Ключ Позволено ли е да е празен? Какво означава
name ❌ Не Името на контролния панел (напр. cPanel, DirectAdmin)
version ❌ Не Версия на панела (напр. 1.0.0)
user_login_url_template ❌ Не Шаблон за URL към входа за потребителите. Използва се в автоматичните известия за високо натоварване. Например: https://{domain}:2087/login – {domain} се заменя автоматично с реалния домейн.
supported_cl_features ❌ Не Обект, описващ кои функции на CloudLinux OS се поддържат от панела. Всичко, което не е описано, се счита за изключено. Ако обектът е празен – всичко ще бъде скрито в интерфейса.

📌 Препоръчително е винаги да връщате този обект, дори ако всички функции са изключени, защото CloudLinux може да добави нови и е добре да имате контрол върху видимостта им.

 

✅ Поддържани CloudLinux OS функционалности (supported_cl_features):

Функция Какво прави Изисквания
php_selector Позволява потребителят да избере PHP версия –
ruby_selector Позволява работа с Ruby приложения –
python_selector Позволява работа с Python приложения –
nodejs_selector Позволява работа с Node.js –
mod_lsapi Поддържа LSAPI за по-бърза PHP обработка –
mysql_governor Контролира MySQL ресурси –
cagefs Изолира потребителите в собствена среда –
reseller_limits Позволява лимити за реселъри –
xray Отстраняване на проблеми в PHP (CloudLinux Shared Pro лиценз) API v1.2+
accelerate_wp Оптимизация на WordPress сайтове API v1.4+
wizard Интеграция с CloudLinux Wizard (упростена настройка) API v1.3+

 

🛢 db_info – Информация за бази данни

Този скрипт връща информация за базите данни, които потребителите в контролния панел могат да използват.

🔔 Важно: Поддържат се само MySQL бази в момента.

📌 Скриптът е незадължителен – ако го няма, CloudLinux няма да събира информация за SQL натоварване чрез lve-stats.

▶️ Пример за изпълнение:

 

/scripts/db_info

 

📤 Примерен изход:

 

{

  “data”: {

    “mysql”: {

      “access”: {

        “login”: “root”,

        “password”: “Cphxo6z”,

        “host”: “localhost”,

        “port”: 3306

      },

      “mapping”: {

        “unix_user_name”: [

          “db_user_name1”,

          “db_user_name2”

        ],

        “unix_user_name2”: [

          “db_user_name3”,

          “db_user_name4”

        ]

      }

    }

  },

  “metadata”: {

    “result”: “ok”

  }

}

 

🔍 Какво съдържа отговорът:

  • access: Данни за достъп до MySQL – потребителско име, парола, хост и порт.

  • mapping: Съответствие между системни потребители (unix_user_name) и потребители на бази данни.

Пример:

 

“mapping”: {

  “john”: [“john_wp”, “john_shop”],

  “mary”: [“mary_blog”]

}

 

Това казва на CloudLinux, че потребителят “john” има два MySQL потребителя – “john_wp” и “john_shop”.

 

db_info – Информация за бази данни

Този скрипт предоставя информация за достъпа до MySQL бази и как те са свързани с потребителите в контролния панел.

📤 Примерен изход:

 

{

  “data”: {

    “mysql”: {

      “access”: {

        “login”: “root”,

        “password”: “Cphxo6z”,

        “host”: “localhost”,

        “port”: 3306

      },

      “mapping”: {

        “user1”: [“db_user1”, “db_user2”],

        “user2”: [“db_user3”]

      }

    }

  },

  “metadata”: {

    “result”: “ok”

  }

}

 

🧩 Какво означава:

  • access: данни за достъп до MySQL база (логин, парола, хост, порт).

  • mapping: показва кой системен потребител (напр. user1) отговаря за кои потребители в базата (db_user1, db_user2 и т.н.).

 

📦 packages – Списък с пакети

Пакетите са “групи” потребители със споделени лимити.

▶️ Извикване:

 

/scripts/packages

 

Може да добавиш филтър:

 

/scripts/packages –owner=root

 

📤 Примерен изход:

 

{

  “data”: [

    { “name”: “basic”, “owner”: “root” },

    { “name”: “silver”, “owner”: “admin” },

    { “name”: “gold”, “owner”: “reseller1” }

  ],

  “metadata”: {

    “result”: “ok”

  }

}

 

🧩 Какво означава:

  • name: име на пакета.

  • owner: собственик на пакета – може да е root, администратор или реселър.

 

👥 users – Списък с потребители

Този скрипт връща информация за UNIX потребителите, създадени и управлявани от контролния панел.

▶️ Извикване:

 

/scripts/users

 

Можеш да го филтрираш по:

  • собственик: –owner=root

  • пакет: –package-name=basic –package-owner=root

  • конкретен потребител: –username=user1

  • потребителски ID: –unix-id=1001

  • полета: –fields=id,email,domain

📤 Примерен изход (пълен):

 

{

  “data”: [

    {

      “id”: 1000,

      “username”: “john”,

      “owner”: “root”,

      “domain”: “johnsite.com”,

      “package”: {

        “name”: “basic”,

        “owner”: “root”

      },

      “email”: “john@johnsite.com”,

      “locale_code”: “en_US”

    }

  ],

  “metadata”: {

    “result”: “ok”

  }

}

 

📤 Примерен изход (само ID и имейл):

 

/scripts/users –fields=id,email

 

{

  “data”: [

    { “id”: 1000, “email”: “john@johnsite.com” }

  ],

  “metadata”: {

    “result”: “ok”

  }

}

 

🔍 Обяснение на основните полета:

Ключ Какво означава
id UNIX ID на потребителя
username Системно потребителско име
owner Кой е създал този потребител (root, admin, reseller)
domain Основен домейн на потребителя
package Пакетът, към който потребителят принадлежи
email Имейл на потребителя
locale_code Езикова настройка (напр. en_US)

 

🌐 domains – Списък с домейни

Този скрипт връща списък с домейни и поддомейни, които се управляват от контролния панел. За всеки домейн се показва:

  • Кой е собственикът (UNIX потребител)

  • Къде се намира основната директория на сайта (document root)

  • Дали това е основният домейн на потребителя

⚠️ Важно:

  • Скриптът трябва да работи в средата на потребителя (CageFS) и да показва само неговите домейни.

  • Ако даден потребител има само user1.com, скриптът не трябва да връща user2.com.

 

▶️ Примерна команда:

 

/scripts/domains –owner=username

 

📤 Примерен резултат:

 

{

  “data”: {

    “user1.com”: {

      “owner”: “user1”,

      “document_root”: “/home/user1/public_html/”,

      “is_main”: true

    },

    “blog.user1.com”: {

      “owner”: “user1”,

      “document_root”: “/home/user1/public_html/blog/”,

      “is_main”: false

    }

  },

  “metadata”: {

    “result”: “ok”

  }

}

 

🧩 Обяснение на ключовете:

Ключ Задължителен Обяснение
owner Да UNIX потребител, собственик на домейна
document_root Да Път до основната директория на сайта
is_main Да Дали е основен домейн за този потребител (true или false)
php Не PHP конфигурация за X-Ray или AccelerateWP (ако е активирана)

 

⚙️ Пример с X-Ray и AccelerateWP поддръжка:

 

“php”: {

  “php_version_id”: “alt-php72”,

  “version”: “72”,

  “ini_path”: “/opt/alt/php72/link/conf”,

  “handler”: “fpm”

}

 

resellers – Списък с реселъри

Реселърите са потребители, които могат да създават и управляват други потребители през контролния панел. Те не е задължително да имат системен UNIX акаунт.

 

▶️ Примерна команда:

 

/scripts/resellers

 

Или с филтри:

 

/scripts/resellers –name=reseller1

 

📤 Примерен резултат:

 

{

  “data”: [

    {

      “name”: “reseller1”,

      “locale_code”: “EN_us”,

      “email”: “reseller1@example.com”,

      “id”: 10001

    }

  ],

  “metadata”: {

    “result”: “ok”

  }

}

 

🧩 Обяснение на ключовете:

Ключ Задължителен Обяснение
name Да Име на реселъра в контролния панел
locale_code Не Избран език от реселъра (по ISO 639-1), напр. EN_us
email Не Имейл за уведомления от CloudLinux (ако няма, се връща null)
id Не Уникален ID на реселъра в системата. Ползва се за второ ниво лимити.

 

admins – Администратори на контролния панел

Този скрипт връща информация за администраторите, управлявани от контролния панел. Това включва:

  • Администратори, които притежават потребители

  • Администратори, които притежават пакети

  • Администратори с UNIX акаунт, които имат достъп до LVE Manager

 

▶️ Примерна команда:

 

/scripts/admins

 

Или с филтър:

 

/scripts/admins –name=admin1

 

📤 Примерен резултат:

 

{

  “data”: [

    {

      “name”: “admin1”,

      “unix_user”: “admin”,

      “locale_code”: “EN_us”,

      “email”: “admin1@domain.zone”,

      “is_main”: true

    },

    {

      “name”: “admin2”,

      “unix_user”: “admin”,

      “locale_code”: “Ru_ru”,

      “email”: “admin2@domain.zone”,

      “is_main”: false

    }

  ],

  “metadata”: {

    “result”: “ok”

  }

}

 

🧩 Обяснение на ключовете:

Ключ Задължително Обяснение
name Да Име на администратора (уникално)
unix_user Не Системен UNIX акаунт, ако има такъв
locale_code Не Избран език (напр. EN_us)
email Не Имейл за известия от CloudLinux
is_main Да true – това е главният администратор (получава сървърни уведомления)

 

🧪 php – Поддържани PHP версии от панела

Този скрипт показва кои PHP версии се поддържат от контролния панел и къде се намират файловете, нужни за работа (модули, конфигурации и т.н.).

 

▶️ Примерна команда:

 

/scripts/php

 

📤 Примерен резултат:

 

{

  “data”: [

    {

      “identifier”:  “alt-php74”,

      “version”: “7.4”,

      “modules_dir”:  “/opt/alt/php74/usr/lib64/modules”,

      “dir”: “/opt/alt/php74/”,

      “bin”:  “/opt/alt/php74/usr/bin/php”,

      “ini”: “/opt/alt/php74/link/conf/default.ini”

    }

  ],

  “metadata”: {

    “result”: “ok”

  }

}

 

🧩 Обяснение на ключовете:

Ключ Задължително Обяснение
identifier Да Уникален ID на PHP версията (напр. alt-php74)
version Да PHP версия (напр. 7.4)
modules_dir Да Път до директорията с модули (.so файлове)
dir Да Основна директория на PHP инсталацията
bin Да Път до PHP изпълнимия файл
ini Да Път до основния php.ini конфигурационен файл

 

🔄 Хукове (hooks) за администратори

Контролният панел трябва да изпълни определени скриптове, когато:

  • Създаваш администратор

  • Премахваш администратор

Тези скриптове се пускат с root права и са нужни, за да се добави/премахне достъп до LVE Manager.

 

➕ Добавяне на администратор:

 

/usr/share/cloudlinux/hooks/post_modify_admin.py create –username admin1

 

➖ Премахване на администратор:

 

/usr/share/cloudlinux/hooks/post_modify_admin.py delete –name admin1

 

📌 Бележки:

  • Ако панелът поддържа няколко администратори, всеки трябва да е в групите sudoers и clsupergid.

  • Ако панелът работи само с един root администратор, не е нужно да добавяш тези hook-ове.

 

Управление на потребители

CloudLinux OS трябва да бъде информиран от контролния панел, когато се извършват действия с потребителите – създаване, промяна, изтриване и т.н. За тази цел се използват специални hooks (скриптове), които се извикват автоматично в съответните моменти.

➕ Създаване на потребител:

Изпълнява се след като е създаден нов потребител:

 

/usr/share/cloudlinux/hooks/post_modify_user.py create –username user –owner owner

 

Параметър Задължителен Описание
–username или -u Да Потребителското име
–owner или -o Да Администратор или реселър, който притежава потребителя

 

✏️ Преименуване на потребител:

Ако се променя потребителското име или домашната директория:

 

/usr/share/cloudlinux/hooks/post_modify_user.py modify -u olduser –new-username newuser

 

🔁 Смяна на собственик:

Ако потребителят се прехвърля към нов администратор или реселър:

 

/usr/share/cloudlinux/hooks/post_modify_user.py modify -u user –new-owner new_owner

 

❌ Премахване на потребител:

Преди изтриване:

 

/usr/share/cloudlinux/hooks/pre_modify_user.py delete –username user

 

След изтриване:

 

/usr/share/cloudlinux/hooks/post_modify_user.py delete –username user

 

♻️ Възстановяване от архив:

(Използва се само ако панелът поддържа архивиране/възстановяване на потребители)

 

/usr/share/cloudlinux/hooks/post_modify_user.py restore –username user

“>

 

—

 

## 🌐 Управление на домейни

 

⚠️ CloudLinux очаква, че всички файлове, свързани с домейни, се намират в домашната директория на потребителя. Ако панелът съхранява домейн-файлове другаде, е добре да се свържеш с CloudLinux екипа за поддръжка.

 

### ✏️ Преименуване на домейн:

“`bash

/usr/share/cloudlinux/hooks/post_modify_domain.py modify -u user –domain old.com –new-domain new.com [–include-subdomains]

 

Параметър Задължителен Описание
–username или -u Да Потребителят, който притежава домейна
–domain Да Старото име на домейна
–new-domain Да Новото име на домейна
–include-subdomains Не Ако е зададено, поддомейните също ще бъдат преименувани (напр. test.old.com → test.new.com)

 

📦 Управление на пакети (хостинг планове)

CloudLinux трябва да бъде информиран, ако хостинг план (пакет) бъде преименуван. Това помага за коректното проследяване на лимитите на ресурсите.

✏️ Преименуване на пакет:

 

/usr/share/cloudlinux/hooks/post_modify_package.py rename –name стар_пакет –new-name нов_пакет

 

Параметър Задължителен Описание
–name Да Името на пакета, което ще се промени
–new-name Не Новото име на пакета

 

Интеграция на Web интерфейса (Web UI) с контролен панел

CloudLinux позволява визуалната част (Web UI) на LVE Manager да се интегрира директно във вашия контролен панел.

🔧 Конфигурация

Това се настройва в конфигурационния файл /opt/cpvendor/etc/integration.ini, в секцията [lvemanager_config]. Пример:

 

[lvemanager_config]

# Задължителен скрипт

ui_user_info = /panel/path/ui_user_info.sh

 

# Допълнителни опции

base_path = /panel/path/lvemanager

run_service = 1

service_port = 9000

use_ssl = 1

ssl_cert = /path/to/domain_srv.crt

ssl_key = /path/to/domain_srv.key

 

📄 Скриптът ui_user_info

Този скрипт връща информация за текущия потребител, който е отворил интерфейса (напр. чрез token=hash в URL).

Примерен изход (в JSON формат):

 

{

  “userName”: “user1”,

  “userId”: 1000,

  “userType”: “user”,

  “baseUri”: “/user1/lvemanager/”,

  “assetsUri”: “/userdata/assets/lvemanager”,

  “lang”: “en”,

  “userDomain”: “example.com”

}

 

Какво означават полетата:

  • userName — системното име на потребителя

  • userId — UNIX ID на потребителя (ако съществува)

  • userType — може да е: “user”, “reseller” или “admin”

  • baseUri — пътят до LVE Manager в уеб интерфейса

  • assetsUri — път до статичните файлове (икони, стилове и т.н.)

  • lang — езиков код (напр. en, bg, ru)

  • userDomain — домейн на потребителя (използва се при показване на информация в Selector)

 

⚙️ Какво правят останалите настройки:

Настройка Обяснение
base_path Път до директорията с файлове за UI, ако не използвате стандартната
run_service Ако е 1 – LVE Manager работи като самостоятелен уеб сървър
service_port На кой порт работи уеб сървърът
use_ssl Използване на HTTPS (1 = да)
ssl_cert Път до SSL сертификат
ssl_key Път до частния ключ

 

⚠️ Известни проблеми с GUI интеграцията

Когато се използва LVE Manager като отделен уеб сървър (без да се вгражда в контролния панел), може да възникнат някои проблеми:

  • Не може да се изтеглят лог файлове от CloudLinux Wizard

  • Проблеми с дизайна на някои форми (Node.js/Python Selector)

  • Понякога грешките не се показват

Тези проблеми ще бъдат решени в бъдещи версии.

 

💡 PHP-базирана интеграция на UI в контролен панел

✅ Вариант 1: Добавяне на икони за достъп до LVE Manager

 

require_once(‘lvemanager/widget.php’);

 

Този файл генерира бутони/икони, с които се отварят отделните модули (напр. Resource Usage, Selector и т.н.). Може да стилизирате изхода според дизайна на контролния ви панел.

 

✅ Вариант 2: Вграждане на конкретен модул в страница на панела

 

require_once(‘lvemanager/LveManager.php’);

$manager = new LveManager(‘<pluginName>’);

$manager->setCSRFToken(); // защита

 

echo $manager->insertPanel();

 

Това ще покаже SPA приложението (Single Page App) на избрания модул директно вътре във вашия панел.

👉 pluginName може да бъде:
  • resource-usage

  • selector

  • lve-stats

  • mysql-governor

  • и др.

 

📦 Специална PHP логика преди зареждане?

Може да посочите собствен PHP файл за допълнителни настройки:

 

vendor_php = /opt/cpvendor/etc/vendor.php

 

И накрая — заявките от потребителския интерфейс се изпращат към специфични PHP скриптове от директорията на LVE Manager.

 

Видимост на плъгините в контролния панел

Контролният панел може да показва или скрива определени плъгини от крайни потребители (например PHP Selector, X-Ray и др.), като използва настройки, описани във файл за конфигурация, който се намира тук:

 

/usr/share/l.v.e-manager/lvemanager-config.json

 

⚠️ Този файл е само за четене. Не може да се променя директно. Вместо това, вие трябва да четете стойностите от него и да ги използвате, за да покажете/скриете съответните икони в панела си.

Примерен JSON с настройки:

 

“uiSettings”: {

    “hideRubyApp”: true,

    “hideLVEUserStat”: false,

    “hidePythonApp”: false,

    “hideNodeJsApp”: false,

    “hidePHPextensions”: false,

    “hideDomainsTab”: false,

    “hidePhpApp”: false,

    “hideXrayApp”: true,

    “hideAccelerateWPApp”: false

}

 

Какво означават настройките:

Настройка Покажи, ако е false / Скрий, ако е true
hideLVEUserStat „Resource Usage“ плъгин
hidePhpApp „PHP Selector“ плъгин
hidePythonApp „Python Selector“ плъгин
hideNodeJsApp „Node.js Selector“ плъгин
hideXrayApp „X-Ray“ плъгин
hideAccelerateWPApp „AccelerateWP“ плъгин

 

🖼️ Бранд икони

Можете да използвате икони за вградените плъгини, които се намират тук:

 

/usr/share/l.v.e-manager/commons/brand-assets/images

 

🛡️ CageFS и LVE

CageFS е защитена среда за потребители. LVE е системата за лимити.

  • LVE Manager скриптовете се стартират извън CageFS, но при нужда влизат вътре (например Node.js/Python).

  • PHP Selector не работи вътре в CageFS, затова той винаги се изпълнява извън нея.

 

🔧 Интеграция на CageFS

📘 Документация: CageFS

🧾 Минимален UID за CageFS

CageFS ограничава само потребители с UID по-голям или равен на UID_MIN.

Команди:

  • Виж текущата стойност:
     cagefsctl –get-min-uid

  • Задай нова стойност (например 10000):
     cagefsctl –set-min-uid 10000

 

🔐 PAM и CageFS

CageFS е съвместим със su, ssh, cron по подразбиране. Може да се активира и за други PAM-базирани услуги. Полезно е, ако потребителите имат shell (напр. bash).

 

🌐 CageFS + Apache

Ако ползвате Apache, трябва да приложите пачовете на CloudLinux, за да работи правилно с CageFS.

🔁 След преинсталация на Apache:
 cagefsctl –force-update

 

🧰 Изпълнение на команди вътре в CageFS

Примери:

  • От root:

 

/sbin/cagefs_enter_user <user> “<command>”

 

  • Като обикновен потребител:

 

/bin/cagefs_enter “<command>”

 

 Временни LVE лимити при стартиране на команда

Може да пуснете команда вътре в CageFS с временни лимити:

cagefs_enter_user –pmem=512M –speed=70% user “php script.php”

 

След като командата приключи, лимитите се изчистват. Ако искате да ги запазите докато процесът работи, използвайте –no-fork.

 

Обновяване на CageFS скелета

Когато обновите системни пакети (RPM) или самия хостинг контролен панел, е задължително да обновите CageFS скелета. Това става с командата:

cagefsctl –force-update

 

💡 Обновяването гарантира, че потребителските среди (CageFS) имат актуални и правилно монтирани файлове.

 

📆 Автоматично обновяване

CageFS пакетът инсталира cron задача, която автоматично обновява скелета всеки ден:

/etc/cron.d/cp-cagefs-cron

 

Ако желаете да промените на колко дни се извършва това обновяване, използвайте:

cagefsctl –set-update-period <брой-дни>

 

🗃️ PHP сесии и временни директории

По подразбиране, PHP сесиите се записват в /tmp, но всеки потребител в CageFS има свой изолиран /tmp, така че другите потребители не могат да го видят. Въпреки това, ако искате да зададете конкретна директория за сесиите за всяка PHP версия, можете да направите следното:

Добавете в /etc/cagefs/cagefs.mp:

@/opt/alt/php54/var/lib/php/session,700

 

След това изпълнете:

cagefsctl –remount-all

 

Това ще насочи PHP към тази сесийна директория вътре в CageFS.

📁 Къде се намират сесиите реално?
 Ако потребителят е user, а HOME му е /home/user, сесиите ще са в:

 

/home/user/.cagefs/opt/alt/php54/var/lib/php/session

 

🧹 Автоматично почистване:
 Файловете в /tmp се почистват чрез tmpwatch. Можете да настройвате периодите за почистване или да добавите още директории според нуждите си. Или, ако предпочитате – създайте собствен скрипт за почистване на PHP сесиите (но не забравяйте да преминете към потребителя, например със sudo, преди да ги триете).

 

👤 Създаване на нов потребител

След като е създаден потребител или администратор, трябва да се извика съответния hook скрипт, описан тук:
 📎 Control Panel Hooks Integration

✅ Включен shell като /bin/bash е безопасен, когато CageFS е активен.

⚠️ ВАЖНО:
 Ако потребител се прехвърля между сървъри или се възстановява от архив, първо се уверете, че всички файлове в неговата домашна директория са напълно възстановени, включително ~/.cl.selector, преди да стартирате пост-хука. В противен случай, PHP Selector няма да работи коректно.

Ако настройките не са възстановени, използвайте тези команди:

 

rm -rf /var/cagefs/`/usr/sbin/cagefsctl –getprefix $username`/$username/etc/cl.selector

rm -rf /var/cagefs/`/usr/sbin/cagefsctl –getprefix $username`/$username/etc/cl.php.d

/usr/sbin/cagefsctl –force-update-etc “$username”

 

⚠️ Дублирани UID-и

Ако контролният панел създава потребители с еднакъв UID, трябва да създадете празен файл:

 

/etc/cagefs/enable.duplicate.uids

 

➡️ Това казва на CageFS винаги да свързва UID със самия първи запис в /etc/passwd, който го използва.

Без този файл, поведението не е гарантирано и може да се получат неочаквани проблеми.

 

Промяна на потребителски акаунти

Всеки път, когато модифицирате потребител в контролния панел (например сменяте му името или собственика), трябва да извикате съответния hook скрипт, за да може CloudLinux OS да реагира правилно. Виж Control Panel Hooks Integration.

 

❌ Изтриване на потребител

CloudLinux използва специален скрипт при изтриване на потребител:

/usr/bin/userdel.cagefs

 

Този скрипт се посочва в конфигурацията /etc/login.defs с:

USERDEL_CMD /usr/bin/userdel.cagefs

 

Той извършва всички нужни операции при премахване на потребител. Но все пак трябва да извикате и съответния hook скрипт от контролния панел.

 

🚫 Изключване на потребители от CageFS

Ако някои системни потребители не трябва да използват CageFS (например вътрешни акаунти на контролния панел), направете следното:

 

Създайте файл (може да има произволно име) в:

/etc/cagefs/exclude

 

В него добавете потребителските имена – по един на ред.

За да приложите промените, изпълнете:

cagefsctl –user-status ИМЕ_НА_ПОТРЕБИТЕЛ

 

Изходът трябва да показва: Disabled: Excluding users

 

📁 Как да добавим файл или директория към CageFS

Има два основни начина:

1. 📋 Копиране на файлове и директории

Създайте свой собствен конфигурационен файл с разширение .cfg в:


/etc/cagefs/conf.d/

 ⚠️ Не редактирайте съществуващи .cfg файлове, защото ще се презапишат при обновяване.

Ако добавяте файлове от RPM пакет, използвайте:


cagefsctl –addrpm ИМЕ_НА_ПАКЕТ

cagefsctl –force-update

 

📅 CageFS автоматично обновява скелета всеки ден чрез cron, но винаги можете ръчно с –force-update.

✅ Предимства:
 Файловете се копират (не се монтират), така че не могат да бъдат променени от потребител, дори при неправилни права.

 

2. 🔗 Монтиране на директория

По-добър избор за често обновявани файлове или тежки директории.

Редактирайте:


/etc/cagefs/cagefs.mp

 

Добавете директорията, която искате да монтирате.

Приложете промените с:


cagefsctl –remount-all

 

✅ Предимства:
 Файловете се обновяват моментално (в реално време), без да се копират, и така намаляват натоварването на диска.

⚠️ Уверете се, че монтираната директория не съдържа чувствителна информация.

 

🏠 Домашна директория на потребител

CageFS автоматично монтира /home/$USER. Но ако контролният панел използва нестандартна структура, например /home/$USER/data, ще трябва да конфигурирате Base Home Directory.

📝 Виж още: Mounting user’s home directory inside CageFS

 

⛔ Изключване на файлове

Ако искате да скриете файлове от CageFS, можете да го направите чрез конфигурация, описана тук: Excluding files

 

🚪 Изпълнение на команди извън CageFS чрез proxyexec

SUID програми (напр. passwd) не могат да се стартират вътре в CageFS. Но чрез proxyexec можете да позволите изпълнение на определени безопасни команди извън CageFS.

📌 Примери за такива команди:

  • passwd

  • exim

  • sendmail

🔐 Важно:
 Използвайте тази възможност внимателно! Командите от тип SUID могат да се изпълняват с root права – това ги прави потенциално опасни.

📛 Уверете се, че:

  • Командата няма уязвимости.

  • Няма начин потребителят да използва тази команда, за да види/промени чувствителна информация.

  • При нужда ограничете флагове (аргументи), които потребителят може да подаде.

 

Филтриране на команди при proxyexec

Когато позволявате на потребителите да изпълняват команди извън CageFS чрез proxyexec, можете да ограничите опасни параметри (флагове), които могат да се използват с тези команди. Повече инфо тук: Filtering options for proxyexec.

 

🐘 Интеграция на PHP Selector в CloudLinux OS

🔧 За пълна документация: PHP Selector документация.

⚠️ Важно: PHP Selector изисква CageFS, затова първо трябва да настроите CageFS.

Какво да направите:

  1. Контролният ви панел вече има собствен PHP Selector?
     Препоръчително е да не активирате CloudLinux PHP Selector, за да избегнете объркване на потребителите.

  2. Искате все пак да използвате PHP Selector на CloudLinux?
     Ще трябва да конфигурирате как се зареждат разширенията за alt-php. Вижте повече тук: PHP extensions

Укажете местоположението на оригиналните (native) PHP бинарни файлове на вашия панел в конфигурационния файл:


/etc/cl.selector/native.conf

 

Прилагате промените с:


cagefsctl –setup-cl-selector

  1.  🔍 Повече информация: Native PHP конфигурация

  2. Искате да позволите на клиентите си да използват специфични версии на PHP?
     Можете да конфигурирате PHP Selector така, че да поддържа и персонализирани версии на PHP:
     📖 Roll your own PHP

  3. Искате да добавите собствени PHP разширения?
     Можете да ги компилирате и интегрирате в PHP Selector:
     🔨 Compile your own extensions

 

🧱 Интеграция на Apache модули в контролни панели

Контролните панели често използват собствена компилация на Apache, затова CloudLinux ви дава възможност да изградите съвместими версии на модулите като:

  • alt-mod-passenger

  • mod_lsapi

  • mod_hostinglimits

Ако използвате Apache от CloudLinux OS

Използвате това Инсталирайте това
httpd mod_lsapi, mod_hostinglimits, alt-mod-passenger
httpd24-httpd httpd24-mod_lsapi, httpd24-mod_hostinglimits, httpd24-alt-mod-passenger

📌 Поддържани Apache версии: 2.2 и 2.4

 

⚙️ Как да компилирате alt-mod-passenger за вашия Apache

Изтеглете сорс пакета:


yumdownloader –source alt-mod-passenger –enablerepo=*source

Рекомпилирайте пакета:


rpmbuild –rebuild alt-mod-passenger-ver.cloudlinux.src.rpm

 

  1. Променете зависимостите в .spec файла:

    • Премахнете зависимости от httpd, apr, apr-util.

    • Заменете ги с вашите собствени Apache пакети.

    • Задайте правилен път към конфигурационната директория на Apache чрез променливата __apache_conf_dir.

Ако срещнете грешки като:


Found: no (Apache 2 dev headers)

 ➤ Добавете следното преди командата passenger-install-apache2-module във файла utils/passenger:


export APU_CONFIG=”/path/to/apu-1-config”

export HTTPD=”/path/to/httpd”

export APXS2=”/path/to/apxs”

 

  1. Компилирайте отново. Ако всичко е правилно конфигурирано, няма да има грешки.

  2. Инсталирайте модула и се уверете, че е зареден в Apache успешно.

mod_hostinglimits – изграждане с персонализиран Apache

Стъпки:

Изтеглете сорс пакета:

yumdownloader –source mod_hostinglimits –enablerepo=*source

 

Компилирайте с вашия Apache:

rpmbuild –rebuild mod_hostinglimits-версия.src.rpm

 

Редактирайте .spec файла:

    • Отстранете зависимостите от httpd и httpd-devel.

    • Задайте пътищата до вашия Apache (бинарни файлове, модули, include директория).

    • Редактирайте mod_hostinglimits/cmake/FindApacheForBuild.cmake – добавете нещо такова:


FIND_PATH (APACHE2_2_HTTPD_INCLUDE_DIR 

   NAMES httpd.h

   PATHS

      /usr/local/apache/include  # или каквото е при вас

      /usr/include/apache

      …

)

 

Компилирайте отново:

rpmbuild –rebuild mod_hostinglimits-версия.src.rpm

 

Инсталирайте и се уверете, че модулът е зареден в Apache.

 

⚙️ mod_lsapi – компилация с ваш Apache

1. Инсталирайте нужните пакети:

 

yum install -y rpm-build liblsapi liblsapi-devel autoconf cmake apr-devel apr-util-devel

 

За CloudLinux OS 7+ добавете:

 

yum install -y criu-lve python-criu-lve criu-lve-devel crit-lve

 

За CloudLinux OS 8+:

 

yum install -y alt-python37-mock alt-python37-pytest httpd-devel

 

2. Изтеглете сорс кода:

 

yumdownloader –source mod_lsapi –enablerepo=*source

 

3. Генерирайте .spec файла:

 

rpmbuild –rebuild mod_lsapi-версия.src.rpm

 

🔧 Това ще създаде файл ~/rpmbuild/SPECS/mod_lsapi.spec, който ще трябва да редактирате.

 

4. Променете .spec файла:

  • Премахнете зависимостта от httpd-devel.

  • Редактирайте секцията %install и задайте реалните пътища:

 

install -D -m 644 conf/mod_lsapi.conf $RPM_BUILD_ROOT/usr/local/apache/conf/lsapi.conf

install -D -m 755 build/lib/mod_lsapi.so $RPM_BUILD_ROOT/usr/local/apache/modules/mod_lsapi.so

 

  • В секцията %files добавете:

 

%config /usr/local/apache/conf/lsapi.conf

/usr/local/apache/modules/mod_lsapi.so

 

5. Решаване на проблеми с пътища

Ако получите грешки от типа:

 

APACHE2_2_HTTPD_BIN-NOTFOUND

 

Редактирайте файла: mod_lsapi-x.x/cmake/FindApacheForBuild.cmake и добавете:

 

FIND_PATH (APACHE2_2_HTTPD_INCLUDE_DIR 

   NAMES httpd.h

   PATHS

      /usr/local/apache/include/

      /usr/include/httpd

)

 

✅ Може също да използвате променливи:

export CUSTOM_APACHE_ROOT=/usr/local/apache

 

Това ще зададе:

  • bin → Apache бинарни файлове

  • include → заглавни файлове (httpd.h, apr.h, apu.h)

  • lib → библиотеки (libapr.so, libaprutil.so)

  • modules → директория за модули

Или индивидуално:

export CUSTOM_APACHE_INC_HTTPD=/usr/local/apache/include

export CUSTOM_APACHE_MODULES=/usr/local/apache/modules

 

6. (По желание) Добавете собствен скрипт към модул

Ако искате да добавите специален скрипт и конфигурация към mod_lsapi:

В %install секцията:

 

install -D -m 644 config.ini $RPM_BUILD_ROOT/usr/share/lve/modlscapi/custom/config.ini

install -D -m 755 custom.sh $RPM_BUILD_ROOT/usr/share/lve/modlscapi/custom/custom.sh

 

И не забравяйте да добавите и във %files:

 

/usr/share/lve/modlscapi/custom/config.ini

/usr/share/lve/modlscapi/custom/custom.sh

 

7. Финална компилация:

rpmbuild -bb ~/rpmbuild/SPECS/mod_lsapi.spec

 

След това инсталирайте модула и проверете дали се зарежда успешно в Apache.

 

Как да интегрираш switch_mod_lsapi с персонализиран контролен панел

Конфигурационен файл config.ini: Създай файл:


/usr/share/lve/mod_lsapi/custom/config.ini

 Съдържанието трябва да изглежда така:


[GLOBAL]

VERSION = 1.0.0

APACHECTL_BIN_LOCATION = /usr/sbin/apachectl

DOC_URL = http://docs.cloudlinux.com/index.html?apache_mod_lsapi.html

EXECUTABLE_BIN = custom.sh

PANEL_NAME = MyCustomPanel

Изпълним скрипт custom.sh: Създай скрипта в същата папка:


/usr/share/lve/mod_lsapi/custom/custom.sh

  1.  Скриптът трябва да обработва следните команди:

    • –setup

    • –uninstall

    • –enable-domain domain.com

    • –disable-domain domain.com

    • –enable-global

    • –disable-global

Пример:


#!/bin/bash

CMD=$1

DOMAIN=$2

 

if [ “$CMD” == “–setup” ]; then

    echo “application/x-httpd-php81-lsphp /usr/local/apps/php81/bin/lsphp” >> /etc/container/php.handler

fi

 

if [ “$CMD” == “–uninstall” ]; then

    sed -i ‘#application/x-httpd-php81-lsphp#d’ /etc/container/php.handler

fi

 

if [ “$CMD” == “–enable-domain” ]; then

    root_path=$(/opt/MyPanel/domain2root $DOMAIN)

    sed -i ‘/lsphp/d’ “$root_path/.htaccess”

fi

 

if [ “$CMD” == “–disable-domain” ]; then

    root_path=$(/opt/MyPanel/domain2root $DOMAIN)

    sed -i ‘/lsphp/d’ “$root_path/.htaccess”

fi

 

if [ “$CMD” == “–enable-global” ]; then

    echo “Глобалното активиране не се поддържа”; exit 1

fi

 

Готово! Сега можеш да използваш командата switch_mod_lsapi, която ще използва твоя custom.sh автоматично.

 

🛠️ MySQL Governor

Инсталиране:

yum install governor-mysql

 

Избор на версия:

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mysqlXX

 

Инсталация:

/usr/share/lve/dbgovernor/mysqlgovernor.py –install

 

Конфигуриране на потребители: Файлът /etc/container/dbuser-map трябва да съдържа съвпадения между UNIX потребители и бази данни.

Пример:

user1: dbuser1, dbuser2

 

Проверка дали работи:

dbtop

 

Ако виждаш натоварване – всичко е наред.

 

🔩 Пачване на Apache (ако е персонализиран)

Ако не използваш Apache от CloudLinux, трябва да приложиш пачове, за да работят LVE и CageFS правилно.

Изтегли пачовете:

wget https://repo.cloudlinux.com/cloudlinux/sources/da/cl-apache-patches.tar.gz

 

Разархивирай и приложи:

tar xvf cl-apache-patches.tar.gz

cp apr-2.4-httpd.2.patch ./apr-1.4.8

cd apr-1.4.8

patch -p3 < apr-2.4-httpd.2.patch

 

Компилирай отново APR библиотеката или Apache.

 

Ако използваш RPM пакети, добави пачовете в .spec файла:

 

Source0: apr-1.4.8.tar.bz2

Patch100: apr-2.4-httpd.2.patch

 

%prep

%setup -q

%patch100 -p3 -b .lve

 

✅ Алтернатива: използвай alt-apr от CloudLinux

CloudLinux предоставя предварително пачната версия alt-apr, която можеш да използваш вместо да пачваш ръчно.

 

Просто смени symlink-а на библиотеката:

ln -sf /opt/alt/alt-apr17/lib64/libapr-1.so.0.7.4 /usr/local/apache/lib/libapr-1.so.0

 

🛡️ Hardened PHP (Подсилен PHP)

Всички версии на alt-php работят без проблеми с всеки контролен панел.

👉 Инсталиране:

  • За да инсталираш всички налични PHP версии:

yum groupinstall alt-php

 

 

  • За да инсталираш само определена версия, например PHP 8.2:

yum groupinstall alt-php82

 

📚 Повече за инсталацията можеш да видиш тук: PHP Selector Installation and Update

 

🔐 Контрол над достъпа до /proc файловата система

CloudLinux OS позволява да ограничиш достъпа на потребителите до системните процеси чрез настройка на ядрото.

  • Когато параметърът fs.proc_can_see_other_uid е настроен на 0, потребителите могат да виждат само своите процеси – това повишава сигурността.

  • Можеш да го зададеш в /etc/sysctl.conf:

 

fs.proc_can_see_other_uid=0

 

След това приложи с:

 

sysctl -p

 

🔄 При стартиране на lve_namespaces услугата (или при рестарт на системата), настройката hidepid ще се приложи автоматично според тази стойност.

 

👨‍💻 Интегриране на администратори в CloudLinux OS

Ако администраторите в панела не са root потребители, можеш да ги добавиш към нужните групи с тази команда:

/usr/share/cloudlinux/hooks/post_modify_admin.py create –username admin_ime

 

🧠 Това:

  • Добавя администратора в група proc_super_gid (за достъп до процеси),

  • и в clsudoers (за да работи LVE Manager правилно).

 

🔗 Symlink защита (срещу атаки чрез символни връзки)

CloudLinux OS има защита срещу злоупотреба със символни връзки (symlinks) – това е важно за сигурността на сървъра.

🔍 Проверка на статуса:

 

cldiag –symlinksifowner

cldiag –check-symlinkowngid

 

Ако видиш “OK” на двата реда – всичко е наред.

✅ Как да активираш защитата:

 

Определи GID групата на потребителя, под който върви уеб сървърът (например apache, nobody, www-data и т.н.).

Настрой параметъра:

sysctl -w fs.symlinkown_gid=GID

 

Или го добави в /etc/sysctl.conf за перманентна промяна.

⚠️ Важно: Ако контролният ти панел позволява на потребители да създават symlinks към файлове, които не са техни, тази защита ще ги блокира.

 

📦 Квоти на файловата система

Някои CloudLinux инструменти (като cagefsctl, selectorctl и др.) записват файлове в домашните директории на потребителите от тяхно име.

📌 Това значи, че ако има зададени квоти (ограничение на дисково пространство), тези инструменти ще се съобразяват с тях, освен ако не са конфигурирани да ги заобикалят.

➡️ Това важи най-вече за XFS файлови системи. Можеш да управляваш това поведение с kernel параметри.

 

Как да интегрираш X-Ray и AccelerateWP в контролен панел

🔔 Важно: X-Ray работи от API версия v1.2, а AccelerateWP — от v1.4. И двете изискват CloudLinux Shared Pro лиценз.

 

🔧 Стъпка 1: Обнови domains скрипта

Трябва да добавиш PHP конфигурацията на всеки домейн в отговора на domains скрипта, когато той се извика с флага –with-php.

 

Пример:

/opt/cpvendor/bin/vendor_integration_script domains –with-php

 

Как трябва да изглежда изходът:

 

{

  “data”: {

    “example.com”: {

      “owner”: “user1”,

      “document_root”: “/home/user1/public_html/”,

      “is_main”: true,

      “php”: {

        “version”: “74”,

        “ini_path”: “/opt/alt/php74/link/conf”,

        “is_native”: true,

        “handler”: “lsapi”

      }

    },

    “sub.example.com”: {

      “owner”: “user1”,

      “document_root”: “/home/user1/public_html/sub/”,

      “is_main”: false,

      “php”: {

        “version”: “82”,

        “ini_path”: “/opt/alt/php82/link/conf”,

        “fpm”: “alt-php82-fpm”,

        “handler”: “fpm”

      }

    }

  },

  “metadata”: {

    “result”: “ok”

  }

}

 

📘 Обяснение на ключовете:

Ключ Задължителен Значение
version ✅ Да PHP версията, избрана за домейна (напр. “74”, “82”).
ini_path ✅ Да Пътят до конфигурационните .ini файлове на тази PHP версия.
is_native ❌ Препоръчително Ако използвате PHP Selector и тази версия е дефинирана като “native”, стойността е true.
fpm ❌ Само при FPM Името на услугата (service) на FPM за домейна.
handler ✅ Да (за AccelerateWP) Типът PHP handler – cgi, fpm, lsapi, fcgi.

⚠️ За AccelerateWP полето handler е задължително!

 

🧩 Стъпка 2: Активирай поддръжката в panel_info скрипта

След като си готов с domains скрипта, трябва да кажеш на CloudLinux, че панелът ти поддържа X-Ray и/или AccelerateWP.

Примерен изход на panel_info:

 

{

  “data”: {

    “name”: “MyAwesomePanel”,

    “version”: “2.5.1”,

    “user_login_url”: “https://{domain}:1111/”,

    “supported_cl_features”: {

      “php_selector”: true,

      “ruby_selector”: true,

      “python_selector”: true,

      “nodejs_selector”: false,

      “mod_lsapi”: true,

      “mysql_governor”: true,

      “cagefs”: true,

      “reseller_limits”: true,

      “xray”: true,

      “accelerate_wp”: true

    }

  },

  “metadata”: {

    “result”: “ok”

  }

}

 

👆 Важно е да добавиш xray: true и/или accelerate_wp: true към supported_cl_features.

 

📌 Накратко:

Действие За X-Ray За AccelerateWP
–with-php флаг ✅ ✅
php.version, php.ini_path ✅ ✅
php.fpm препоръчително ❌
php.handler ❌ ✅ задължително
panel_info → supported_cl_features xray: true accelerate_wp: true