CloudLinux OS kernel

 

CloudLinux OS ядро

 

🧠 Какво е ядрото на CL9?

При CloudLinux 9 (CL9), нямаме отделно (собствено) ядро, както беше при по-старите версии. Вместо това, използваме ядрото на AlmaLinux, което получава редовни ъпдейти директно от основния източник (upstream).

Но за да осигурим по-голяма стабилност, сме създали и LTS ядро (Long Term Support) – то е базирано на по-стара версия от стандартното, но включва всички важни поправки по сигурността и критични CVE уязвимости.

👉 Препоръчваме LTS ядрото, защото промените в него са по-малко (т.е. по-стабилно е), но същевременно системата е напълно защитена.

 

🛠 Как да го инсталираш?

• Пусни следната команда, за да инсталираш LTS ядрото:
  

dnf install -y –allowerasing kernel-lts kmod-lve-lts perf-lts bpftool-lts

 

• Ако използваш външни модули (например от DKMS), е добре да добавиш и development пакетите:
  

dnf install -y kernel-lts-devel kernel-lts-devel-matched

 

• След това рестартирай сървъра:
  

reboot

 

• След рестарта, за да се увериш, че LTS ядрото ще остане основно (по подразбиране), изтрий стандартните ядра, за да не се презаписват при ъпдейти:
  

dnf remove kernel-core

 

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

 

🧪 Какво е “Хибридно ядро”?

Хибридното ядро ти позволява да използваш новите функции и оптимизации на по-съвременните ядра, без да е нужно да минаваш на изцяло нова версия на операционната система.

📍 Пример: ако си с CloudLinux 7 (с ядро 3.10), можеш да инсталираш хибридно ядро от CL8 (версия 4.18). Това ти дава:

• по-добра производителност
• по-добро управление на паметта
• достъп до повече съвременни възможности на ядрото

🔧 Подходящо е за сървъри, които искат по-добра производителност, но не могат или не искат да минават на по-нова ОС.

 

Как да преминеш от стандартно към хибридно ядро в CloudLinux OS

❗Изискване: Трябва да имаш активен CloudLinux OS лиценз.
⚠️Важно: Ако използваш yum-plugin-protectbase, изключи го преди да продължиш.

 

✅ Стъпки за миграция към хибридно ядро:

• Обнови системата:
  

yum update

 

• Стартирай скрипта за преминаване към хибридно ядро:
  

normal-to-hybrid

 

• Ако скриптът приключи без грешки, рестартирай сървъра:
  

reboot

 

🔁 Как да се върнеш обратно към стандартното ядро:

• Обнови системата:
  

yum update

 

• Стартирай скрипта за връщане към нормалното ядро:
  

hybrid-to-normal

 

⚠️ Ограничения и особености при хибридните ядра

🐧 CloudLinux OS 6:

• След връщане към стандартно ядро, самото хибридно ядро остава инсталирано, но се премахва един важен пакет (linux-firmware), който е нужен за стартиране на хибридното ядро.
  👉 Затова не трябва да рестартираш обратно към хибридното ядро, след като го премахнеш.
• Проверка на подписите на kernel модули (signature check) не работи, защото ядрото 3.10 използва x509 сертификати, които CloudLinux OS 6 не разпознава.

 

🔒 Защита срещу символни линкове (symlink атаки)

CloudLinux OS предлага мощни инструменти за предпазване от така наречените symlink атаки – често срещан метод за достъп до чувствителни файлове в споделен хостинг.

Какво трябва да знаеш?

Системата използва различни kernel параметри, които трябва да настроиш:

🛡 fs.enforce_symlinksifowner

👉 Включва се с:

fs.enforce_symlinksifowner = 1

 

Какво прави?

• Забранява на процеси (например Apache), които работят под определена група (GID), да следват символни линкове, ако линкът и целта му имат различни собственици.

Пример:

• Ако потребител user1 е създал линк към файл на user2, уеб сървърът няма да може да го отвори, ако не е собственик.

⚙️ fs.symlinkown_gid

• Това е ID на групата, която ще бъде ограничена от правилото по-горе.
• По подразбиране:
  • GID за Apache = 48
  • GID за cPanel (nobody) = 99

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

fs.symlinkown_gid = 48

 

После:

sysctl -p

 

🔐 Допълнителна защита: Link Traversal Protection

Позволяваш/забраняваш създаване на символни линкове към чужди файлове чрез:

 

fs.protected_symlinks_create = 1

fs.protected_hardlinks_create = 1

 

❗ Внимание:

Ако не използваш CageFS навсякъде (примерно в cPanel WebDAV, файлов мениджър, уебмейл и др.), само тази настройка не е достатъчна. В такъв случай добави и:

fs.process_symlinks_by_task = 1

 

🧪 Кога да не включваш тази защита?

• При някои control panels (особено cPanel), включването ѝ може да спре някои функции да работят правилно.
• Затова винаги тествай първо в тестова среда.

Защита със fs.process_symlinks_by_task

Налично само за CloudLinux 7 Hybrid, CloudLinux 8 или по-нови версии. Работи само с cPanel.

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

Тази защита предпазва от атаки с символни линкове, при които злонамерен потребител може да чете файлове извън CageFS чрез инструменти в cPanel като File Manager, WebDAV, Webmail и др.

Как работи?

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

Как да включиш защитата:

fs.process_symlinks_by_task = 1

 

Ако искаш да я изключиш (например за тестване):

fs.process_symlinks_by_task = 0

 

⚠️ Известни проблеми при включена fs.protected_symlinks_create=1 в cPanel

Някои функции в cPanel може да спрат да работят правилно, ако включиш fs.protected_symlinks_create=1. Ето какво може да се случи:

❌ Проблеми с rsync:

Ако се използва rsync за копиране или прехвърляне на файлове със символни линкове, ще изскочат грешки като:

rsync error: some files could not be transferred (code 23)

 

Това засяга и автоматичните трансфери през cPanel.

 

❌ Проблеми с възстановяване на архиви (backups):

При опит за възстановяване на акаунт може да видиш грешки от вида:

/bin/tar: .cagefs/tmp/mysql.sock: Cannot create symlink to ‘/var/lib/mysql/mysql.sock’

Permission denied

 

Това означава, че връзката (symlink) не може да бъде създадена, и възстановяването на backup-а се проваля.

 

⚠️ Съобщенията в dmesg и messages логовете се пълнят:

Ще видиш хиляди повтарящи се съобщения като:

may_create_sym_link: can’t find ea-php81 in cron

 

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

 

🔒 fs.process_symlinks_proc

Тази настройка е много важна за CageFS. Какво прави?

➡️ Забранява на процеси в LVE (ограничени от CloudLinux) да следват линкове, които сочат към файлове извън CageFS.

👉 По подразбиране е включена и не е нужно да я променяш, освен ако нямаш конкретна причина.

 

📁 File Change API – по-умен начин за следене на промени по файлове

🧐 Проблем:

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

• inotify е бавен при много файлове
• Сканиране на целия диск е изключително ресурсоемко и бавно

 

✅ Решението на CloudLinux: File Change API

CloudLinux въвежда специален механизъм в ядрото на системата, който:

• Следи кои файлове са се променили
• Буферира тази информация в паметта
• Подава списъка на потребителски софтуер (например backup програми)

Предимства:

• Бързо и леко за системата
• Backup програмите ще могат директно да използват този списък
• Поддържа се от cPanel backup системата (или ще се поддържа съвсем скоро)

 

Как се използва CloudLinux File Change API

🔧 Инструменти за потребителско ниво

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

🛠️ Основен инструмент: /usr/bin/cloudlinux-backup-helper

🔒 Работи само с root права.

Аргументи:

• -t или –timestamp – показва променени файлове след определена дата/час
• -u или –uid – показва файлове, променени само от определен потребител

📤 Формат на изхода:

<версия>,<краен timestamp>

<UID>:<абсолютен път до променен файл>

<UID>:<абсолютен път до променен файл>

 

🧪 Примери:

cloudlinux-backup-helper -t 1700000000 -u 1001

 

Изход:

1,1700000123

1001:/home/user2/public_html/output.txt

1001:/home/user2/public_html/info.php

 

👤 Как обикновен потребител може да провери своите промени

🔐 CloudLinux осигурява отделен инструмент: /usr/bin/cloudlinux-backup-helper-uid

➡️ Това е безопасен начин всеки потребител сам да види кои негови файлове са били променени.

Пример:

cloudlinux-backup-helper-uid -t 1700000000

 

Изход:

1,1700000123

1000:/home/user/file1.txt

1000:/home/user/file2.txt

 

✅ Работи и вътре в CageFS.

 

📥 Инсталиране и настройка

🧩 Пакет: cloudlinux-fchange

❗ Изисква:

• CloudLinux OS 6 (с Hybrid ядро) или
• CloudLinux OS 7 с ядро 3.10+

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

yum install cloudlinux-fchange –enablerepo=cloudlinux-updates-testing   # за CL7

yum install cloudlinux-fchange –enablerepo=cloudlinux-hybrid-testing    # за CL6 Hybrid

 

След инсталация, демонът за следене на файлове стартира автоматично.

 

Ръчно стартиране/спиране:

systemctl start cloudlinux-file-change-collector     # CL7

service cloudlinux-file-change-collector start       # CL6 Hybrid

systemctl stop cloudlinux-file-change-collector

 

⚙️ Конфигурация

Файлът с настройките е:
/etc/sysconfig/cloudlinux-fchange

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

База данни с променени файлове:

database_path=/var/lve/cloudlinux-fchange.db

 

Включване само на конкретни пътища:

include=/home

 

Изключване на пътища от наблюдение:

exclude=/var

exclude=/tmp

 

Интервал за проверка: (на всеки 5 секунди)

polling_interval=5

 

Колко дни да пази данни:

time_to_keep=1

 

Минимален UID за ограничение при отказ на демона (за да не се губят събития):

user_ro_mode_min_uid=-1  # -1 = изключено

 

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

event_types=file_created,file_modified,file_deleted

 

💡 Препоръка: Следи само промените, които ти трябват – така ще пестиш ресурси.

 

Достъп на ниско ниво (Low-level access)

⚠️ Внимание: Тези опции са за напреднали потребители и може да повредят работата на CloudLinux File Change API, ако не се използват правилно.

Ядрото (kernel) на CloudLinux предоставя контрол върху проследяването на файлови промени чрез папката /proc/sys/fs/datacycle/.

Основни файлове и какво правят:

• enable — Активира или деактивира системата за проследяване.
  👉 Запиши 1, за да я активираш; 0, за да я изключиш.

events — Списък на променените файлове в реално време.
Всеки ред е в следния формат:


<ID на събитие>:<тип събитие>:<UID на потребителя>:<път до файл>

• flush — Изчиства списъка със събития.
  👉 Просто запиши последното event_id в този файл, за да изтриеш старите записи.
• user_ro_mode — Забранява писане в домашната директория за потребители с UID над определена стойност.
  ➕ Добре е при извънредни ситуации – за да се гарантира, че няма да се изгубят събития.
• entries_in_buffer — Показва колко събития има в буфера.
• min_event_uid — Минимален UID за проследяване. По подразбиране е 500 (тоест, не проследява системни потребители).

 

tuned-profiles-cloudlinux

Този пакет включва оптимизации за ядрото, които подобряват:

• натоварване на процесора (LA)
• изчакване на вход/изход (IOwait)
• стабилност при проблемни PHP/lsphp процеси

Видове профили:

 

tuned-adm list | grep cloudlinux

 

• cloudlinux-default – активен профил с всички настройки.
• cloudlinux-dummy – празен профил (не прави нищо).
• cloudlinux-vz – за OpenVZ/ Virtuozzo среди.

Използвай cloudlinux-default за нормални системи.

 

Какво прави профилът cloudlinux-default:

• Настройва процесора на максимална производителност
• Подобрява управлението на паметта
• Задава I/O scheduler в зависимост от вида диск:
  • HDD ➜ deadline
  • SSD ➜ noop
• Изключва Transparent HugePages (подобрява стабилността)
• Приоритетно убива PHP процеси при проблеми с RAM (OOM Killer)

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

 

yum install tuned-profiles-cloudlinux

tuned-adm profile cloudlinux-default

 

За спиране:

tuned-adm off

 

⚙️ Kernel конфигурации и променливи

CloudLinux съхранява ядрените си настройки в:

/etc/sysctl.d/90-cloudlinux.conf

 

🟡 Ако променяш kernel параметри, използвай sysctl –system, за да ги приложиш.

Пример:

echo “fs.proc_can_see_other_uid = 0” >> /etc/sysctl.d/90-cloudlinux.conf

sysctl –system

 

⚠️ Важно: Не е препоръчително да редактираш директно 90-cloudlinux.conf. Вместо това, създай файл с по-висок приоритет, например:

/etc/sysctl.d/95-custom.conf

 

🔒 Ограничаване на достъпа до /proc/net/*

По подразбиране CloudLinux ограничава достъпа до почти всичко в /proc/net, освен:

• tcp
• udp
• raw
• unix
• и още няколко

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

 

echo “kernel.proc_disable_net = 1” >> /etc/sysctl.d/95-custom.conf

sysctl –system

 

Ограничаване на достъпа до процеси и системни файлове през /proc

По подразбиране всеки потребител в Linux може да използва команди като ps, top и htop, за да види процесите на други потребители на сървъра. Това не е желано в хостинг среда, където много акаунти споделят един и същи сървър. CloudLinux позволява това поведение да бъде ограничено.

 

Как да забраниш достъпа на потребителите до процесите на други

1️⃣ Добави следните редове в /etc/sysctl.conf:

 

fs.proc_can_see_other_uid = 0

fs.proc_super_gid = 600

 

• fs.proc_can_see_other_uid = 0 – потребителите ще виждат само своите процеси.
• fs.proc_super_gid = 600 – само потребителите, които са част от група с GID 600, ще виждат всички процеси (например zabbix, nagios и други мониторинг потребители).

2️⃣ Приложи промените:

 

sysctl -p

 

Автоматично създаване на специална група clsupergid

От версия lve-utils 4.2.0-1 насам, при инсталация (не при ъпдейт) CloudLinux автоматично:

• Създава група clsupergid
• Задава тази група като fs.proc_super_gid

➕ Ако вече си задал стойност на fs.proc_super_gid, тя няма да бъде презаписана.

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

 

usermod -a -G clsupergid <username>

 

🧩 Какво всъщност ще вижда един обикновен потребител

Дори /proc да изглежда, че съдържа много файлове, потребителят има достъп само до собствените си процеси и до следните файлове:

 

/proc/cpuinfo

/proc/version

/proc/stat

/proc/uptime

/proc/loadavg

/proc/filesystems

/proc/cmdline

/proc/meminfo

/proc/mounts

/proc/net/tcp

/proc/net/tcp6

/proc/net/udp

/proc/net/udp6

/proc/net/assocs

/proc/net/raw

/proc/net/raw6

/proc/net/unix

/proc/net/dev

 

Това са безопасни файлове, които не разкриват чувствителна информация.

 

ℹ️ Забележка

• От lve-utils 3.0-21.2 нататък, параметърът fs.proc_super_gid вече се записва в конфигурационния файл /etc/sysctl.d/90-cloudlinux.conf, вместо директно в /etc/sysctl.conf.

 

Допълнителна защита на /proc с hidepid

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

По подразбиране всеки потребител може да види процесите на всички останали — това не е желателно в хостинг среда.

 

🛡️ Какво прави hidepid

CloudLinux използва kernel настройката fs.proc_can_see_other_uid за да реши с какви параметри да монтира /proc:

Настройка в /etc/sysctl.conf	Как се монтира /proc	Какво означава това?
Не е зададена	hidepid=0	Потребителите виждат всичко
fs.proc_can_see_other_uid=1	hidepid=0	Всички виждат всичко
fs.proc_can_see_other_uid=0	hidepid=2	Всеки вижда само своите процеси
fs.proc_can_see_other_uid=0 + fs.proc_super_gid=600	hidepid=2,gid=600	Само потребителите в група с GID 600 виждат всичко

 

📌 Как да го активираш

• Редактирай /etc/sysctl.conf и добави:

fs.proc_can_see_other_uid=0

fs.proc_super_gid=600

 

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

service lve_namespaces restart

или:

/usr/share/cloudlinux/remount_proc.py

 

🧩 Ако искаш да зададеш опциите в /etc/fstab

Можеш ръчно да контролираш монтирането на /proc чрез този ред в /etc/fstab:

proc /proc proc defaults,hidepid=2,gid=clsupergid 0 0

 

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

mount -o remount /proc

 

⚠️ Препоръчително е да използваш sysctl.conf, защото е по-съвместим метод и се поддържа от CloudLinux автоматично.

 

⚠️ Известни проблеми

• На CloudLinux OS 6 потребителите вътре в CageFS не виждат /proc изцяло, дори и да са в „привилегированата“ група.
• Това не засяга потребители извън CageFS.
• CloudLinux 7 и 8 не са засегнати от този проблем.

 

🧠 Обобщение

Цел	Какво да направиш
Да ограничиш достъпа до процеси	fs.proc_can_see_other_uid=0
Да дадеш достъп само на конкретни админи или инструменти (например zabbix)	Създай група и задай fs.proc_super_gid=600
Да приложиш промените	sysctl -p и/или remount_proc.py
Да провериш текущи стойности	cat /proc/sys/fs/proc_can_see_other_uid

 

Премонтиране на /proc в CloudLinux OS 8

Важно: В CloudLinux OS 8 (от версия на ядрото 4.18.0-193.28.1.lve1.el8) премонтирането на /proc се контролира директно от ядрото. Това означава:

• Не трябва да изпълняваш /usr/share/cloudlinux/remount_proc.py ръчно.
• Настройките се правят само с параметрите на ядрото, записани в конфигурационни файлове.

✅ Как да приложиш промените

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

/etc/sysctl.conf

# или

/etc/sysctl.d/90-cloudlinux.conf

 

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

sysctl –system

 

❌ Промени в /etc/fstab няма да имат ефект

Дори да добавиш hidepid= в /etc/fstab, това няма да промени нищо в CloudLinux OS 8 — ядрото игнорира тези настройки и използва fs.proc_can_see_other_uid вместо това.

 

🔒 Блокиране на ptrace (повишена сигурност)

ptrace е техника, която някои програми използват за следене или отстраняване на грешки в други процеси. Примери: strace, gdb, lsof.

❗ В хостинг среда това е потенциален риск, защото злонамерен потребител може да се опита да шпионира други процеси.

✋ По подразбиране ptrace е разрешен:

 

kernel.user_ptrace = 1

kernel.user_ptrace_self = 1

 

✅ Как да забраниш ptrace изцяло

1. Добави следното в /etc/sysctl.conf:

 

## CloudLinux: Забрана на ptrace функционалност

kernel.user_ptrace = 0

kernel.user_ptrace_self = 0

 

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

 

sysctl -p

 

Това ще забрани както PTRACE_ATTACH, така и PTRACE_TRACEME – с други думи, пълна блокировка на ptrace.

 

🧩 Частична забрана (по избор)

• Ако искаш частична защита (например да работят някои инструменти като lsof), можеш да зададеш само едната стойност на 0.

 

⚠️ Известни проблеми

• Забраната на ptrace може да наруши работата на Plesk PSA услугата (версия 11).
• Увери се, че софтуерът ти не зависи от strace, gdb или други от този тип.

 

Xen XVDA и именуване на дискове

🛠 За CloudLinux OS 6 и Hybrid ядра:

При ядра 2.6.32, устройствата в Xen виртуализирана среда могат да се именуват различно.

Ако искаш да избегнеш автоматичното преименуване на дисковете (например xvda ➝ sda), добави следния параметър към командния ред на ядрото в grub.conf:

 

xen_blkfront.sda_is_xvda=0

 

✅ Това ще запази имената на устройствата като xvde, xvdf и т.н.

 

🎭 Поведение на umask в LVE

За CloudLinux OS 6/7 и техните Hybrid ядра:

От версия lve-kmod-2.0-10 нататък, умаската (umask) на процеса се запазва, когато влиза в LVE.

❗ Преди това, когато даден процес влезе в LVE, се използваше умаската на LVE-то, а не на самия процес. Това може да е довеждало до неочаквани права на файлове.

 

📉 IO ограничение с латентност (забавяне)

Функцията е налична от lve1.2.29+ и по-нови.

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

Когато клиент надхвърли IO лимита си, процесите му “заспиват” (спират временно), за да не нарушат лимита.

Сега можеш да зададеш максимално време на изчакване (в милисекунди), преди процесите да бъдат пуснати отново. Това позволява временен “burst” – процесите временно използват повече IO, отколкото им е позволено, ако чакат прекалено дълго.

🔧 Как да активираш:

Пример: да зададеш макс. латентност от 10 секунди (10 000 милисекунди)

 

echo 10000 > /sys/module/kmodlve/parameters/latency

 

❌ Как да я изключиш:

 

echo 2000000000 > /sys/module/kmodlve/parameters/latency

 

🗂 Постоянна настройка (дори след рестарт):

Създай файл:

/etc/modprobe.d/kmodlve.conf

 

И добави:

options kmodlve latency=1000

 

(тук 1000 = 1 секунда макс. изчакване)

 

За CloudLinux OS 5 (остаряла система):

Използва се друга директория:

 

echo 10000 > /sys/module/iolimits/parameters/latency

 

Как да следиш използването на LVE в реално време

CloudLinux OS ти позволява да следиш какви ресурси използва всеки потребител на сървъра в реално време – директно от системен файл.

📁 Къде се намира тази информация?

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

В зависимост от версията на ядрото, ще получиш:

• Версия 6 – при CloudLinux 6 и Hybrid ядра
• Версия 4 – при по-стари ядра

🆔 Разпознава се по първия ред във файла:

 

6:LVE …   ← версия 6

4:LVE …   ← версия 4

 

🧮 Какви данни се показват?

Пример за изход от файл версия 6:

 

6:LVE  EP  lCPU  lIO  CPU  MEM  IO  lMEM  lEP  nCPU  fMEM  fEP  lMEMPHY  lCPUW  lNPROC  MEMPHY  fMEMPHY  NPROC  fNPROC

0     0    25    1024 0    0    0   262144 20   1     0     0     262144   100    0       0       0        0      0

300   0    25    1024 1862407 0 0  262144  20   1     0     0     262144   100    0      31       0        0      0

 

🧾 Обяснение на най-важните колони:

Колона	Описание
LVE	Идентификатор на потребителя (LVE ID)
EP	Брой текущи входни процеси (например PHP заявки)
lCPU	Ограничение на CPU (в проценти от общото CPU)
lIO	Ограничение на IO (четене/запис) в KB/s
CPU	Използвано CPU от рестарта насам (в наносекунди)
MEM	Използвана виртуална памет (брой 4К страници)
lMEM	Ограничение на виртуалната памет
lEP	Максимален брой входни процеси (напр. едновременни заявки)
nCPU	Лимит на броя ядра, които може да използва потребителят
MEMPHY	Използвана физическа памет (RAM)
lMEMPHY	Ограничение на физическата памет
NPROC	Брой процеси, които потребителят е стартирал
lNPROC	Лимит на броя процеси
fMEM, fEP, fNPROC	“Грешки” – когато лимит е достигнат (faults)

💡 Всички стойности са обновявани в реално време, така че можеш да ги следиш с watch, скрипт или мониторинг инструмент.

 

⚡ Flashcache – ускоряване на I/O с SSD кеш

Само за CloudLinux OS 6 и Hybrid ядра (x86_64)

Flashcache е модул, създаден от Facebook, който позволява бърз диск (SSD) да кешира бавен диск (HDD). Така получаваш най-доброто от двата свята:

• Бързина от SSD
• Обем от HDD

📌 Подходящо е за бази данни или интензивно I/O натоварване.

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

 

yum install flashcache

 

OOM Killer при LVE процеси

Когато даден потребител (LVE) надвиши зададения лимит за памет, системата използва така наречения OOM Killer, за да прекрати процесите му. Това се записва в лог файла /var/log/messages.

❗ Проблем при голямо натоварване

Ако много потребители надвишават лимитите за памет едновременно (или многократно за кратко време), OOM Killer може да натовари допълнително сървъра.

✅ Решение: използване на по-леко спиране (SIGKILL)

В новите версии на ядрото на CloudLinux OS 6 и 7, може да изключиш тежкия OOM Killer и вместо него да се използва обикновено прекратяване на процесите със сигнал SIGKILL, което е по-леко за системата.

🔧 Как да го направиш:

За CloudLinux OS 6:

echo 1 > /proc/sys/ubc/ubc_oom_disable

 

За да се запази и след рестарт, добави това в файла /etc/sysctl.conf:

ubc.ubc_oom_disable=1

 

За CloudLinux OS 7:

echo 1 > /proc/sys/kernel/memcg_oom_disable

 

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

kernel.memcg_oom_disable=1

 

📌 Препоръчва се да изключиш OOM Killer и да използваш SIGKILL вместо него – по-леко е за системата и по-стабилно.

 

📁 Квоти на файлова система (file system quotas)

🧾 Ext4

При файловата система Ext4, системни програми като selectorctl и cagefs не се спират, дори ако даден потребител е надвишил дисковата си квота – благодарение на специално системно разрешение (CAP_SYS_RESOURCE).

➡️ Това позволява на CloudLinux инструменти да работят нормално, дори ако има превишаване.

🧾 XFS

Ако използваш XFS файлова система, трябва ръчно да изключиш проверката за квоти при системни инструменти:

 

echo 1 > /proc/sys/fs/xfs/cap_res_quota_disable

 

Влизане в LVE при използване на cPanel инструменти

Обикновено cPanel инструментите (като file manager, cron и др.) се изпълняват от името на потребителя, но не влизат в неговото LVE (ограниченията за ресурси).

💡 Ако искаш да ограничиш ресурси, използвани от cPanel инструменти, можеш да активираш функцията да влизат в LVE-то на съответния потребител.

⚠️ Важно:

• Това е експериментална функция.
• Може да има конфликти – напр. ако един и същ потребител едновременно използва сайта си и cPanel инструментите, и двете неща ще делят същите лимити, което може да доведе до проблеми с производителността.

🔧 Как да активираш:

Само за CloudLinux OS 7 Hybrid:

 

echo 1 > /sys/module/kmodlve/parameters/lve_setuid_enter

 

🧠 Превантивна система за проследяване на kernel сривове с Sentry и Kernel Panic Receiver

Актуализирането на ядрото (kernel) е чувствителна задача. За да гарантират стабилност, CloudLinux въвеждат инструмент за превантивно улавяне на сривове на ядрото.

🛠️ Kernel Panic Receiver

Това е отворен код проект, който събира логове при kernel crash (срив). Инструментът помага на администраторите бързо да открият причината за проблема и да реагират навреме.

 

Как работи изпращането на логове към CloudLinux при срив (Kernel Panic)

CloudLinux предоставя система за автоматично изпращане на логове от сървъра, ако се случи срив на ядрото (т.нар. kernel panic). Това става с помощта на стандартна Linux функция, наречена netconsole.

🛠️ Как се активира автоматично

Ако използваш следните версии на initscripts пакета:

• CL6: 9.03.61-1.cloudlinux
• CL7: 9.49.49-1.cloudlinux
• CL8: 10.00.4-1.cloudlinux

…то netconsole вече е подготвен да праща логове при сривове.

 

За да се увериш, че имаш най-новата версия, изпълни:

yum update initscripts –enablerepo=cloudlinux-updates-testing

 

След това, при kernel panic, логовете ще се изпратят автоматично до CloudLinux сървър чрез UDP (като обикновен текст).

 

🔐 Каква информация се изпраща?

• Изпращат се само съобщения за сривове на ядрото (OOPS/PANIC).
• НЕ се изпращат чувствителни данни – като потребителски имена, пароли, ключове, пътища и др.
• Безопасно е и не застрашава сигурността на сървъра.

 

❌ Как да изключиш тази функция (не се препоръчва)

Ако все пак не искаш да се изпращат данни, можеш да изключиш netconsole:

 

• Отвори файла:
  

/etc/sysconfig/netconsole

 

• Закоментирай този ред:
  

# SYSLOGADDR=sentrykernel.cloudlinux.com

 

• Спри услугата:
  

service netconsole stop

 

ℹ️ Netconsole се използва само за Kernel Panic Receiver и няма да засегне други услуги на CloudLinux, ако го изключиш.