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

Оттеглени функции

 

Това са функции, които вече не се поддържат или скоро ще бъдат премахнати:

  • Python Selector (Старата версия)

  • Git за cPanel

  • LVE-Stats 0.x

  • OptimumCache

  • TPE разширение

  • Ограничения на CPU

  • Интеграция с пакети – използвайте ръководството за контролен панел вместо това

  • Поддръжка на Redis с HostingLimits

  • Миграция към EasyApache 4 (EA4)

 

Python Selector (старата версия)

Забележка: Това ръководство е за старата версия на Python Selector. За новата версия, потърси актуалната документация.

Старата версия на Python Selector ти позволява да създаваш и управляваш Python приложения чрез mod_passenger, директно на сървъра.

Тази функция е налична само за CloudLinux OS 6 и по-нови версии, и само на сървъри с cPanel.

Проверка за поддържани версии на Python

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

yum grouplist | grep alt-python

 

Инсталиране

Инструкциите са за EasyApache 3 и EasyApache 4. Ако използваш LiteSpeed, следвай тези стъпки:

Инсталирай нужните инструменти:

 

За EasyApache 3:

yum install lvemanager alt-python-virtualenv alt-mod-passenger

 

За EasyApache 4:

yum install lvemanager alt-python-virtualenv ea-apache24-mod-alt-passenger

 

След това инсталирай самите алтернативни Python пакети:

yum groupinstall alt-python

 

Ако ще използваш MySQL:

yum install alt-python27-devel

 

 Увери се, че си отбелязал нужните опции в таба “Options” в LVE Manager, за да виждаш Python App в интерфейса.

 

 За да добавяш Python модули, трябва да имаш достъп до gcc/make. Включи компилаторите от WHM → Compiler Access и изпълни:

cagefsctl –force-update

 

Достъп за потребители

  1. Влез в cPanel и избери Select Python Environment от секцията “Software”.

  2. Ще се появи форма, в която избираш:

    • Версията на интерпретатора (Python 3.7, 3.9 и т.н.)

    • Име на папката на приложението

    • URL адрес (URI), през който ще се достъпва приложението

  3. Натисни “Create project” и ще се създаде ново Python приложение.

  4. След създаване, можеш да редактираш:

    • Пътя към папката

    • URI адреса

    • WSGI входната точка (например flask/run.py:app)

  5. С бутон “Show control” можеш да добавяш/премахваш Python модули директно от интерфейса.

  6. След като направиш промени – задължително натисни Update, за да се запазят. Ако искаш да отмениш промените – натисни Reset.

 Приложението първоначално е празно. Трябва ръчно да качиш твоя код във въведената папка.

 

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

Ако искаш да го премахнеш, натисни Remove – това ще изтрие приложението, но самата папка ще остане.

 

Работа с домейни

Ако имаш LVE Manager версия 0.9-10 или по-нова, можеш да обвързваш приложенията с конкретен домейн.

Пример:

/usr/bin/selectorctl –interpreter=python –version=3.7 –user=exampleuser –domain=mydomain.com –create-webapp myapp /myuri

 

Също така можеш да променяш URI адрес и домейн с:

/usr/bin/selectorctl –interpreter=python –user=exampleuser –domain=newdomain.com –transit-webapp myapp /newuri

 

Тази възможност вече е налична и през уеб интерфейса.

 

Бързи команди през CLI (старият selectorctl)

 Този инструмент не се поддържа в новата версия на Python Selector. Използвай cloudlinux-selector.

 

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

selectorctl –interpreter=python –version=3.7 –create-webapp myapp /myuri

 

Изтриване:

selectorctl –interpreter=python –destroy-webapp myapp

 

Промяна на папка:

selectorctl –interpreter=python –relocate-webapp oldname newname

 

Промяна на URI:

selectorctl –interpreter=python –transit-webapp myapp /newuri

 

Промяна на версия на интерпретатора:

selectorctl –interpreter=python –set-user-current –version=3.9 myapp

 

Задаване на WSGI входна точка:

selectorctl –interpreter=python –setup-wsgi=flask/run.py:app myapp

 

Инсталиране/премахване на модули:

selectorctl –interpreter=python –enable-user-extensions=flask,django myapp

selectorctl –interpreter=python –disable-user-extensions=flask myapp

 

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

selectorctl –interpreter=python –list-user-extensions myapp

 

Преглед на всички приложения на потребител:

selectorctl –interpreter=python –user=exampleuser –user-summary

 

Списък с налични Python версии:

selectorctl –interpreter=python –list

 

Git за cPanel

Важно: Този пакет вече не се поддържа, защото може да създаде проблеми със зависимости (conflicts между пакети).

Защо не е нужен повече?

От версия 11.38 на cPanel насам, не е нужно да използваш специалния „git за cPanel“ пакет. Вместо това, можеш да инсталираш обикновен Git без никакви проблеми.

Как да инсталираш Git:

Обикновен Git:

yum install git

 

Ако все пак искаш да инсталираш специфичния за cPanel пакет:

yum install git-cpanel

 

Препоръка: Най-добре използвай стандартния git пакет, освен ако нямаш конкретна причина за нещо друго.

 

LVE-Stats 0.x

Важно: Тази версия вече не се поддържа. Вместо нея използвай LVE-Stats 2.

Какво представлява LVE-Stats?

lve-stats е пакет, който събира статистика за използването на LVE (Lightweight Virtual Environment) – например използване на CPU, RAM, I/O и т.н. Данните могат да се разглеждат чрез команди или визуализирани в графики.

 

Инсталиране

За да го инсталираш:

yum install lve-stats

 

Ако вече го имаш, просто го обнови:

yum update lve-stats

 

Това ще инсталира и сървърния компонент lvestats-server, който можеш да рестартираш с:

service lvestats restart

 

Къде се съхраняват данните?

Създава се SQLite база данни в:

/var/lve/lveinfo.db

 

В нея се пази информация за последните два месеца, под формата на:

  • на всеки 5 минути – за последния час

  • на всеки час – за останалото време

Файлът /var/lve/info се обновява на няколко секунди и се използва от LVE Manager.

Инструменти

lveinfo

Основният инструмент за преглед на статистики. Намира се на:

/usr/sbin/lveinfo

Някои полезни опции:

  • –from= и –to= – период за отчет (по дата и час)

  • –display-username – показва потребителски имена вместо LVE ID

  • –order-by=cpu_max – сортиране по максимално CPU натоварване (или друг ресурс)

  • –csv – изкарва резултатите в CSV формат

  • –by-usage – показва LVE, които достигат до 90% от лимитите

  • –by-fault – показва LVE с регистрирани грешки (например лимит на RAM)

Пример 1:

Показване на 10-те най-натоварени LVE по CPU между 10 и 15 октомври 2010:

lveinfo –from=’2010-10-10′ –to=’2010-10-15′ -o cpu_max –display-username

 

Пример 2:

Статистика само за потребителя web2:

lveinfo –from=’2010-10-10′ –to=’2010-10-15′ –user=web2 –display-username

 

Централизирано съхранение на статистика в MySQL

Отново, тази функционалност се отнася за LVE-Stats 0.x, който вече е остарял.

 

За да събираш данните от няколко сървъра в една обща база данни:

  • Инсталирай нужния драйвър:

yum install MySQL-python

 

  • Ако имаш MySQL 5.3+ и липсва libmysqlclient_r.so.15, инсталирай:

yum –enablerepo=cloudlinux-updates-testing install mysqlclient15

 

  • Създай база и потребител:

create database lvestats;

grant all on lvestats.* to ‘user’@’localhost’ identified by ‘парола’;

flush privileges;

 

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

  • На всеки сървър редактирай файла:

/etc/sysconfig/lvestats

 

Примерно съдържание:

db_type = mysql

connect_string = хост:база:потребител:парола

server_id = server1

db_port = 3306

COMPACT=slave

 

На един сървър сложи COMPACT=master – той ще се грижи за „почистването“ на старата статистика.

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

service lvestats restart

 

За да свържеш потребителските имена с LVE ID:

/usr/share/lve-stats/save_users_to_database.py

Само първия път – след това ще се пуска автоматично с cron.

 

Централизирано съхранение в PostgreSQL

  • Инсталирай нужния пакет:

yum install postgresql-python

 

  • Създай база и потребител:

createdb lvestats

createuser lveuser

 

  • Създай таблиците и индексите, описани в документацията.

  • Конфигурирай /etc/sysconfig/lvestats:

db_type = postgresql

connect_string = хост:база:потребител:парола

server_id = server2

COMPACT=slave

 

На един сървър отново трябва да е COMPACT=master.

        Ограничения:

  • SERVER_NAME трябва да е максимум 10 символа

  • lvestats.readonly трябва да е достъпен само за четене

  • Файлът /etc/sysconfig/lvestats да е достъпен само за root (например с chmod 600)

Обобщение за настройка на няколко сървъра

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

  • На един от тях да настроиш COMPACT=master

  • На всички останали – COMPACT=slave

Така ще избегнеш дублиране и ще поддържаш базата оптимизирана.

OptimumCache

Важно:
 OptimumCache вече не се поддържа.

Какво представлява OptimumCache (версия 0.2 и нагоре)

OptimumCache е специален тип кеш за файлове, създаден с мисъл за сървъри, на които се хостват много различни сайтове – например такива с WordPress, Joomla и други популярни платформи.

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

OptimumCache решава този проблем, като открива и кешира дублиращите се файлове само веднъж. Така:

  • когато някой от тези файлове се поиска отново, той се зарежда директно от кеша, без да се чете отново от диска;

  • това пести ресурси и ускорява работата на сайтовете;

  • нуждата от памет намалява, защото няма излишни копия в кеша;

  • натоварването върху диска също намалява.

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

Изисквания:

  • Операционна система: CloudLinux OS 6.x или по-нова (64-битова)

  • Файлова система: ext4

  • Ядро: lve 1.2.55 или по-ново

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

С командата:

yum install optimumcache

 

След това трябва да укажете на OptimumCache кои папки да следи за дублиращи се файлове. Например:

# occtl –recursive –mark-dir /home

# occtl –recursive –mark-dir /home2   # ако използвате cPanel

# occtl –recursive –mark-dir /var/www # ако използвате Plesk

 

Важно: В този период процесорът може да се натовари повече (понякога дори двойно), докато системата индексира всички файлове.

Дисково пространство за кеша

По подразбиране, OptimumCache създава специален файл с размер 5GB, който използва за съхраняване на кеша. Този файл се намира в:

/var/share/optimumcache/optimumcache.image

и се монтира в:

/var/cache/optimumcache

 

Съвет:
 Ако прехвърлите този файл на SSD диск, скоростта на зареждане на файловете ще е още по-висока.

 

Управление на кеша (ploop)

Преместване на кеш-файла (ploop):

occtl –move-ploop /път/до/нов/файл [нов_размер]

 

Важно: Трябва да посочите пълния път и име на новия файл, а не просто директория.

 

Пример:

occtl –move-ploop /var/ssh/optimumcache.image

Ако не посочите размер, ще се използва стойността от конфигурационния файл /etc/sysconfig/optimumcache, или 5GB по подразбиране.

 

Включване и изключване на кеша (ploop):

occtl –init-ploop       # включване

occtl –disable-ploop    # изключване

 

Ако използвате по-стара версия (0.1-21), може да се наложи да премахнете ръчно настройката за автоматично монтиране от /etc/fstab, защото новите версии го правят автоматично.

 

Промяна на размера на кеша:

occtl –resize-ploop [нов_размер]

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

Изтриване на кеша (ploop):

occtl –delete-ploop

Ако възникне проблем с демонтирането му, има решения описани в раздел “Troubleshooting”.

Често задаван въпрос:
 Ако съм преместил, създал, изтрил или преоразмерил кеш-файла (ploop), трябва ли да маркирам наново директориите?
 Отговор: Не, не е необходимо.

Използване без ploop

Важно:
 OptimumCache вече не се поддържа.

Ако използвате сървър с по-стара версия на ядрото (преди lve1.2.55), ploop няма да може да се използва поради несъвместимост. В този случай кешът се съхранява директно в папката:

/var/cache/optimumcache

 

Когато свободното място на диска, където се намира кешът, падне под 10%, кешът автоматично се почиства – премахват се около 20% от файловете. Това поведение може да се променя чрез настройката PURGEAHEAD в:

/etc/sysconfig/optimumcache

 

За да влязат промените в сила, трябва да рестартирате услугата optimumcache.

Файловете в кеша се чистят с помощта на скрипт, който се изпълнява всяка минута:

/etc/cron.d/optimumcache_cron

 

Този скрипт извиква:

/usr/share/optimumcache/optimumcache_purge

 

Маркиране на директории за кеширане

Важно:
 OptimumCache вече не се поддържа.

За да кажете на OptimumCache кои директории да следи за дублиращи се файлове, използвайте:

 

occtl –mark-dir /път/до/директория –recursive

 

В повечето случаи администраторите маркират директории като:

 

occtl –mark-dir /home /home2 /home3 –recursive

 

Забележка: Индексирането на тези директории може да отнеме от няколко часа до дни и натоварва системата повече от обичайното. Статуса на тази задача може да се провери с:

at -l

 

Игнориране на определени файлове и папки

Когато даден файл се промени, OptimumCache автоматично спира да го следи, защото променените файлове обикновено нямат дубликати. Всички новосъздадени файлове обаче ще се проверяват.

Има случаи, когато е добре да изключите някои папки от проверка, особено такива с временни файлове (напр. папки за поща, tmp и т.н.), защото проверката за дубликати там е ненужна и тежка.

 

За да игнорирате определени папки, използвайте регулярен израз (regexp):

occtl –add-skip-mask REGEX

 

За да видите текущите „skip“ правила:

occtl –list-skip-mask

 

За да премахнете някое правило:

occtl –remove-skip-mask ID_или_Tag

 

За да приложите новите настройки:

occtl –check

 

Командата –check отнема време и натоварва системата, така че използвайте я внимателно, особено ако /home е над 500 GB.

Конфигурационен файл:

/etc/sysconfig/optimumcache

Примерни параметри, които можете да промените:

  • OPTIMUMCACHE_MNT=/var/cache/optimumcache – място на кеша

  • COUNT=0 – брой кеширани копия

  • MINSIZE – минимален размер на файл за кеширане

  • MAXSIZE=10485760 – максимален размер на файл (10 MB по подразбиране)

  • TIMEOUT=7 – интервал между кеширания (секунди)

  • NOIMMSYNC=1 – изключва честия sync, за по-добра производителност

  • PURGEAHEAD=20 – колко % да се изтрият, когато няма място

  • LOGLEVEL=1 – ниво на логове

  • OCCTL_LVE_IO_LIMIT=5 – лимит на IO при mark/check

  • PERF_LOG_ENABLED=1 – логване на производителността

Работа през команден ред (CLI)

Контролът върху OptimumCache става с инструмента occtl.

Примери:

Покажи статистика:


optimumcache stat

optimumcache stat /home

Подробна информация какво е в кеша:


optimumcache dump –resolve-filenames

Стартиране на кеш файл:


occtl –init-ploop 10G

Преместване на кеш файл:


occtl –move-ploop /нов/път/към/файл 15G

Добавяне на “пропусни” маска:


occtl –add-skip-mask “/cache/”

Спиране на кеша:

occtl –disable-ploop

Изтриване на кеш:

occtl –delete-ploop

Има още много команди, но това са най-често използваните.

 

cloudlinux-collectl: Бърз старт

Какво представлява?

Пакетът cloudlinux-collectl автоматично започва да събира данни за натоварването на системата във фонов режим веднага след инсталиране. Той работи независимо дали OptimumCache е инсталиран или не. Основната му цел е да позволява сравнение на производителността преди и след инсталирането на OptimumCache, за да се види дали има реална полза от него.

Инсталиране

За да го инсталирате:

yum install cloudlinux-collect –enablerepo=cloudlinux-updates-testing

 

Важно:
 Ако ъпдейтнете OptimumCache до версия 0.2-23, cloudlinux-collectl ще се инсталира автоматично.

Измерване на времето за реакция на уебсайт

cloudlinux-collectl може да следи колко бързо отговарят определени URL адреси.

Добавяне на нов URL за наблюдение:

cloudlinux-collect –addurl <име> <http://адрес>

 

Пример:

cloudlinux-collect –addurl localhost http://127.0.0.1/index.php

 

Можете да видите още опции с:

cloudlinux-collect –help

 

Какво се събира?

Ако искате да видите какви статистики се събират:

cloudlinux-collect –test

Логовете се съхраняват компресирани (gzip) в:

/var/log/optimumcache/collectl

 

Подробности за статистиката

Когато изпълните cloudlinux-collect –test, ще видите няколко блока информация:

OPTIMUMCACHE DETAIL – показва доколко ефективно работи OptimumCache.

Пример:

inodes:    4967  общо

uncached:    31  не са кеширани

cached:    4936  кеширани (99.4%)

 

Тези числа показват колко файлове са кеширани и колко не.

URLSTATTRACKER DETAIL – показва времето за отговор на зададените URL адреси в милисекунди.

Ако видите отрицателна стойност (напр. -403 или -500), това не е време, а код за HTTP грешка:

  • -403 = Забранен достъп

  • -500 = Вътрешна грешка на сървъра или проблем със свързването

Ръчна настройка на URL адресите

След чисто инсталиране, по подразбиране се следи само http://localhost/. За да добавите нов:

cloudlinux-collect –addurl alt http://192.168.0.102/

 

За да видите всички наблюдавани адреси:

cloudlinux-collect –info

 

За да изключите някой URL от наблюдение:

cloudlinux-collect –skip <име>

 

Демон collectl-cloudlinux

cloudlinux-collectl използва пакета collectl. При инсталация се стартира автоматично нова услуга collectl-optimumcache.

Тя се пуска автоматично при:

  • инсталиране на пакета

  • рестарт на сървъра

Можете да я контролирате така:

Проверка на състоянието:

service cloudlinux-collect status

  • Старт/спиране:

    service cloudlinux-collect start

service cloudlinux-collect stop

 

Анализ на резултатите

Събраната информация се пази във файлове във формат:

/var/log/cloudlinux-collect/%име-на-сървъра%-%дата%.raw.gz

 

За да ги направите удобни за Excel, LibreOffice или други инструменти:

cloudlinux-collect –genplotfiles

 

Файловете ще се появят тук:

/var/log/cloudlinux-collect/plotfiles

 

Деинсталиране на OptimumCache

Внимание: OptimumCache вече не се поддържа

 

Спрете услугата:

service optimumcache stop

 

Изчистете кеша:

occtl –delete-ploop

:>/var/share/optimumcache_store

 

Деинсталирайте:
yum remove optimumcache

 

Препоръчва се рестарт на сървъра
 След това опцията pfcache= автоматично ще изчезне.

Важно за по-стари версии (преди 0.2-11):
 Ако ploop файлът не може да се демонтира, ще се наложи ръчно да изтриете следните файлове (може да е нужно рестартиране):

 

rm /var/share/optimumcache/optimumcache.image

rm /var/share/optimumcache/DiskDescriptor.xml

rm /var/share/optimumcache/DiskDescriptor.xml.lck

Ако процесът по деинсталиране отнема твърде дълго, потърсете решение в секцията „Troubleshooting“ на документацията.

 

Отстраняване на проблеми с OptimumCache

Забележка:
 OptimumCache вече не се поддържа официално.

 

Инсталиране – само за Ext4 файлови системи

В момента само Ext4 файловата система се поддържа от OptimumCache. Ако сървърът ви няма монтиран дял с Ext4, инсталацията ще се прекрати с грешка като тази:

Ext4 partition is the only supported by OptimiumCache, there is no one in fstab

 

Също така, ако се опитате да добавите директория за кеширане, която не е на Ext4, ще получите грешка:

occtl –mark-dir /home –recursive

optimumcache: Can not mount device. rc[8192]

 

Yum не успява да инсталира нужните Perl модули

Ако при инсталация с yum install optimumcache получите грешки от типа:

 

Requires: perl(Config::Tiny)

Requires: perl(IO::Socket::SSL)

Requires: perl(YAML::Tiny)

 

…вероятно в конфигурационния файл /etc/yum.conf е зададено изключване на всички perl* пакети.

 

Решение:

yum install optimumcache –disableexcludes=all

 

Стар ploop не може да се демонтира (OptimumCache преди версия 0.2-23)

Проблем с демонтирането на стари ploop файлове може да доведе до неуспешно преместване или промяна на размера им. Заобиколно решение:

occtl –move-ploop –ignore-unmount-failure

 

Ако местите към нов файл:

occtl –move-ploop /нов/път/optimumcache.image [размер в GB] –ignore-unmount-failure

 

След това рестартирайте сървъра и изтрийте старите ploop файлове ръчно, ако не са премахнати автоматично.

 

Високо дисково натоварване (IO)

Проблемът с прекомерни операции върху диска беше решен във версия 0.2-6. Ако използвате по-стара версия, обновете така:

yum update optimumcache –enablerepo=cloudlinux-updates-testing

След това, в конфигурационния файл /etc/sysconfig/optimumcache, добавете:

 

NOIMMSYNC=1

LOGLEVEL=2

 

Рестартирайте услугата:

service optimumcache restart

 

Високо натоварване на процесора (CPU)

Ако забележите висока употреба на CPU, проверете дали се извършва преиндексиране на контролни суми (reindexing). Това е нормално и натоварването ще спадне, когато приключи.

 

Проверка с:

grep Reindexing /var/log/messages

 

Ако няма ред „Reindexing finished…“, процесът все още тече.

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

occtl –report

 

Потърсете редове като:

PFL_REINDEX_NUM_FILES:      192810

PFL_REINDEX_THOUGHPUT_KB:   2904007

 

Деинсталирането отнема твърде дълго

Ако командата yum remove optimumcache изглежда „забива“, това е защото премахва маркировки от файловете един по един – което може да отнеме много време.

 

Можете да спрете този процес така:

occtl –cancel-pending-jobs

 

Това ще прекрати текущата операция, а деинсталацията ще приключи почти веднага.

 

Грешка: „Failed to attach peer: Invalid argument“

Тази грешка е по-рядка. За да я поправите, опитайте да обновите статуса на кешираните точки:

 

occtl –remount-cached-points

 

Trusted Path Execution (TPE) – защита чрез ограничаване на изпълнимите файлове

Какво е TPE?

TPE е функция за сигурност, която ограничава изпълнението на програми от потребители, които не са администратори (non-root).
 С нея можете да направите така, че обикновени потребители да не могат да стартират изпълними файлове, освен ако те не се намират в специално позволени директории.

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

Как да я включим?

Поддръжката за TPE е вградена в ядрото на системи с grsecurity. Не е нужно да инсталирате нищо допълнително.

Можете да я настроите, като редактирате файла /etc/sysctl.conf и добавите в края:

 

# Настройки за GRsecurity и TPE

kernel.grsecurity.tpe = 1

kernel.grsecurity.tpe_restrict_all = 1

kernel.grsecurity.grsec_lock = 1

 

След това активирайте промените с:

sysctl -p

Важна забележка

След като зададете grsec_lock = 1, няма да можете да променяте TPE настройките без рестарт на системата. Това заключва настройките, за да се избегне нежелано или злонамерено тяхно променяне.

Файлове, чрез които TPE се конфигурира директно (без sysctl.conf):

  • /proc/sys/kernel/grsecurity/grsec_lock – заключва настройките

  • /proc/sys/kernel/grsecurity/tpe – включва/изключва TPE

  • /proc/sys/kernel/grsecurity/tpe_gid – указва GID (група), която има право да изпълнява файлове извън позволените директории

  • /proc/sys/kernel/grsecurity/tpe_restrict_all – при 1, ограничава всички потребители (включително root, освен ако не е в указаната група)

Произход:
 TPE е част от grsecurity – разширение за ядро, което предлага допълнителни мерки за сигурност в Linux.

Ограничения на CPU (процесорно време)

Важно:
 Тази система за CPU ограничения вече не се използва. Вместо това се използва параметърът SPEED.

 

Как работеше преди (преди версия lve-utils 1.4)

Ограниченията на процесора се определяха чрез две стойности:

  • CPU – процент от общото CPU на сървъра, който е достъпен за потребителя (в LVE).

  • NCPU – брой ядра, които са достъпни за потребителя.

Истинското ограничение се определяше от по-малката стойност между тези две.

Примери:

Ядра на сървъра CPU (%) NCPU Реално ограничение
1 ядро 25% 1 25% от 1 ядро
2 ядра 25% 1 50% от 1 ядро
4 ядра 25% 1 100% от 1 ядро
4 ядра 50% 2 2 ядра
8 ядра 50% 3 3 ядра

Какво се случва, когато се достигне лимитът?

Ако потребителят достигне зададения лимит за CPU, процесите му се забавят нарочно, за да не го превишат.

Например:
Ако лимитът е 10%, и процесите искат да използват повече от това, те ще бъдат „заспивани“ периодично, така че реално използваното време да не надвиши лимита.

Забавянето не е на интервали от 1 секунда – то се случва много по-често, така че натоварването никога не надвишава зададения лимит.

Интеграция с пакети в CloudLinux OS

Важно:
Тази система за интеграция вече не се поддържа активно. Вместо нея се препоръчва използване на интеграционното ръководство за контролни панели.

Какво представлява това?

От версия lve-utils 1.4+, CloudLinux OS автоматично разпознава най-популярните хостинг контролни панели (като cPanel) и ви позволява да задавате различни лимити на ресурси според “пакета” на всеки клиент.

Това означава, че не е нужно:

  • да задавате един и същ лимит за всички потребители, или

  • да въвеждате лимити ръчно за всеки поотделно.

А ако използвате собствен панел?

Ако имате собствено направен контролен панел с ваша система от пакети, пак можете да използвате CloudLinux OS за управление на лимитите.

Нужно е само:

  1. Да напишете скрипт, който свързва потребители с пакети.

  2. Да настроите CloudLinux да използва този скрипт чрез lvectl.

Как трябва да работи скриптът?

Скриптът може да бъде на който и да е език (bash, python и т.н.), стига да е изпълним (chmod +x). Той трябва да поддържа следните опции:

–list-all
 Извежда списък с [userID packageName], напр.:

100 package1  

101 package1  

102 package2

–userid=ID
 Връща името на пакета за даден потребител, напр.:

package1

–package=”име”
 Връща списък от user ID-та, които принадлежат на този пакет:


100  

101

–list-packages
 Извежда списък с всички имена на пакети:

package1  

package2  

package3

 

Как да кажете на CloudLinux да използва вашия скрипт?

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

/etc/sysconfig/cloudlinux

  1. Добавете или редактирайте тази настройка:

    CUSTOM_GETPACKAGE_SCRIPT=/пълен/път/до/вашия/скрипт

 

Примерен скрипт можете да видите в официалната документация: Примерен скрипт от CloudLinux

Как да проверите дали CloudLinux OS е активен?

Проверка за ядрото:

 bash
КопиранеРедактиране
uname -r | grep lve

  •  Ако видите нещо с lve в името, значи ядрото е CloudLinux (напр. 2.6.32-…lve…).

  • Проверка за CageFS:

Дали е активен глобално:

/usr/sbin/cagefsctl –cagefs-status

Дали е активен за конкретен потребител:

/usr/sbin/cagefsctl –user-status потребител

Дали сте вътре в CageFS: Проверете дали съществува файлът:


/var/.cagefs/.cagefs.token

Показване на лимити за CPU, памет и IO

Повечето контролни панели показват информацията от CloudLinux директно на клиентите. За целта lve-stats създава файл с информация, който контролният панел може да прочете лесно:

/var/lve/info

 

Този файл се обновява на всеки 5 минути и съдържа:

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

  • останалите редове – лимити и използване на активните клиенти

Ако клиент липсва в списъка – той не е активен (не е пускал скриптове наскоро), и има стандартните лимити.

 

Какво съдържа всеки ред?

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

№ Какво означава
0 User ID
1 Използвани входни процеси
2 Лимит за входни процеси
3 CPU използване
4 CPU лимит
5 Използвана виртуална памет
6 Лимит за виртуална памет
7 Грешки при виртуална памет
8 Грешки при входни процеси
9 Лимит за физическа памет
10 Използвана физическа памет
11 Грешки при физическа памет
12 Лимит на брой процеси
13 Използвани процеси
14 Грешки при процеси
15 (запазено)
16 IO използване (KB/s)
17 IO лимит (KB/s)

Важно:
 При по-старите версии на LVE (напр. версия 4) се показват само първите 9 полета. При версия 6 – всички 18.

Redis поддръжка в mod_hostinglimits

Внимание:
 От версия 1.0-30 на mod_hostinglimits, Redis вече не се поддържа!
 Тази информация се отнася само за по-стари версии на модула.

Какво представлява Redis поддръжката?

С Redis поддръжка, модулът mod_hostinglimits може да използва Redis база данни, за да определи LVE ID на потребителя според домейна, който е заявен в HTTP заявката.

Пример:

Ако имате Redis база с данни като тази:

КопиранеРедактиране

xyz.com    10001  

bla.com    10002

…когато някой отвори xyz.com, модулът ще открие, че този домейн трябва да се изпълнява под LVE с ID 10001.

Как да активирате Redis поддръжка? (Само за по-стари версии)

Трябва да компилирате mod_hostinglimits ръчно от сорс код с включена Redis поддръжка:

Стъпки:

  • Изтеглете кода:

    wget https://repo.cloudlinux.com/cloudlinux/sources/da/mod_hostinglimits.tar.gz
  1. Инсталирайте нужните инструменти:

    yum install cmake
  2. Разархивирайте и компилирайте:

    tar -zxvf mod_hostinglimits*.tar.gz

cd mod_hostinglimits*

cmake -DREDIS:BOOL=TRUE .

make

make install

  • Конфигуриране на Redis режим

След като модулът е компилиран с Redis поддръжка, трябва да го включите чрез настройка:

apache

КопиранеРедактиране

LVEParseMode REDIS

 

Допълнителни настройки

LVERedisSocket – използване на Unix сокет

  • Какво прави: Задава пътя до Redis сокета.

Пример:

LVERedisSocket /var/run/redis.sock

 

  • По подразбиране: /tmp/redis.sock

LVERedisAddr – използване на IP/порт

  • Какво прави: Позволява връзка към Redis по IP адрес и порт вместо чрез сокет.

Пример:

LVERedisAddr 127.0.0.1 6993

LVERedisTimeout – интервал за повторен опит при грешка

  • Какво прави: Определя колко секунди да изчака, преди да опита отново връзка с Redis при неуспешен опит.

Пример:

LVERedisTimeout 120

  • По подразбиране: 60 секунди

Миграция към EasyApache 4 (EA4) в CloudLinux OS

Основни съвети и ограничения

  • Използвайте cPanel версия 11.55.999.66 или по-нова.

  • Някои по-стари версии на PHP, като ea-php51 и ea-php52, не поддържат PHP-FPM.
     Вместо това използвайте mod_lsapi – следвайте инструкциите за инсталация и конфигурация от сайта на CloudLinux.

Сценарии според вида на системата

 

CentOS със вече инсталиран EasyApache 4

Ако сървърът вече има EasyApache 4, а вие искате да преминете към CloudLinux OS:

Преобразувайте CentOS в CloudLinux OS
 (Вижте официалните инструкции за конвертиране)

Рестартирайте Apache:

service httpd restart

 

CentOS без инсталиран EasyApache 4

Ако сървърът няма EA4, а искате да преминете към CloudLinux и EA4:

Преобразувайте CentOS към CloudLinux OS.

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

cd ~

wget https://repo.cloudlinux.com/cloudlinux/sources/cloudlinux_ea3_to_ea4

sh cloudlinux_ea3_to_ea4 –convert

CloudLinux OS без EasyApache 4

Ако вече сте на CloudLinux, но още нямате EA4:

Инсталирайте cPanel (ако не е инсталиран).

Изпълнете:

cd ~

wget https://repo.cloudlinux.com/cloudlinux/sources/cloudlinux_ea3_to_ea4

sh cloudlinux_ea3_to_ea4 –convert

Какво представлява скриптът cloudlinux_ea3_to_ea4?

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

 

Синтаксис:

cloudlinux_ea3_to_ea4 [допълнителни опции] ДЕЙСТВИЕ

 

Основни действия (задължителни):

Флаг Действие
–convert Преход от EA3 към EA4
–revert Връщане обратно към EA3

Допълнителни опции (по избор):

Флаг Какво прави
–mod_lsapi Инсталира mod_lsapi
–altphp Инсталира или обновява alt-php
–mod_passenger Инсталира alt-mod-passenger

Примери:

Преход към EA4 + mod_lsapi + alt-php:

sh cloudlinux_ea3_to_ea4 –convert –mod_lsapi –altphp

  1. Преход към EA4 + mod_lsapi + alt-php + mod_passenger:
    sh cloudlinux_ea3_to_ea4 –convert –mod_lsapi –altphp –mod_passenger
  2. Връщане обратно към EA3 с mod_lsapi:
    sh cloudlinux_ea3_to_ea4 –revert –mod_lsapi