Для розміщення сайтів не завжди потрібен важкий і складний вебсервер. На системах із невеликим обсягом оперативної пам’яті або помірним навантаженням часто використовували Lighttpd — компактний вебсервер, орієнтований на швидку обробку запитів і невелике споживання ресурсів.

У цьому історичному матеріалі розглядається встановлення Lighttpd на CentOS 6.0 із підтримкою PHP5 через FastCGI та бази даних MySQL. Така конфігурація дозволяла створити повноцінне середовище для запуску динамічних вебсайтів, систем керування контентом і власних PHP-проєктів.

Наведені версії операційної системи та програмного забезпечення давно застаріли. Тому матеріал слід використовувати для вивчення принципів роботи вебсервера, PHP через FastCGI та взаємодії з MySQL, а не як готову інструкцію для сучасного виробничого сервера.

Початкова конфігурація

У прикладі використовувався сервер із повним доменним ім’ям server1.example.com і локальною IP-адресою 192.168.0.100.

На реальному сервері ці значення потрібно замінити власними параметрами:

доменним ім’ям;

IP-адресою;

мережевими налаштуваннями;

паролями адміністраторів;

каталогами сайтів.

Усі дії виконувалися з адміністративними правами. Перед початком встановлення бажано було переконатися, що система має доступ до репозиторіїв і може завантажувати пакети через менеджер yum.

Встановлення MySQL

Першим компонентом встановлювалася система керування базами даних MySQL.

Для цього через yum додавалися клієнтська та серверна частини MySQL. Після встановлення службу вмикали в автозапуск, щоб вона автоматично запускалася під час завантаження операційної системи.

Потім сервер MySQL запускався вручну.

Початкове встановлення MySQL потребувало додаткового захисту. Для цього використовувався системний сценарій mysql_secure_installation.

Він послідовно пропонував:

встановити пароль адміністратора MySQL;

видалити анонімних користувачів;

заборонити віддалений вхід користувача root;

видалити тестову базу даних;

перезавантажити таблиці привілеїв.

Після проходження цього налаштування база даних була готова до створення користувачів, таблиць і баз для вебсайтів.

Важливо, щоб пароль адміністратора MySQL був складним і не збігався з паролем системного користувача. Для кожного сайту також бажано створювати окремого користувача бази даних із доступом лише до потрібної бази.

Підключення додаткового репозиторію

У стандартних репозиторіях CentOS 6.0 пакет Lighttpd був відсутній. Тому в оригінальній конфігурації підключався сторонній репозиторій RPMforge, призначений для сумісних із Red Hat Enterprise Linux систем.

Для 64-бітної та 32-бітної архітектур використовувалися різні RPM-пакети репозиторію.

Спочатку відповідний пакет завантажувався на сервер, після чого встановлювався через rpm.

Після підключення RPMforge менеджер yum отримував можливість знаходити та встановлювати Lighttpd разом із необхідними залежностями.

Використання стороннього репозиторію завжди потребує обережності. Перед підключенням необхідно перевіряти його походження, актуальність, підписи пакетів і сумісність із поточною системою.

Встановлення Lighttpd

Після підключення репозиторію Lighttpd встановлювався через yum.

Далі службу додавали до автозапуску на основних рівнях завантаження системи та запускали вручну.

Якщо встановлення пройшло успішно, Lighttpd починав приймати HTTP-запити. Для перевірки достатньо було відкрити IP-адресу сервера у браузері.

Під час першого відкриття могла з’явитися сторінка з помилкою 404 Not Found. У цьому випадку помилка не означала, що вебсервер не працює.

За замовчуванням каталогом сайту в цій конфігурації був:

/srv/www/lighttpd

Якщо в ньому не було файлу index.html або іншого індексного документа, Lighttpd повертав відповідь 404.

Для перевірки можна було створити звичайний HTML-файл у цьому каталозі та повторно відкрити адресу сервера.

Помилка запуску через IPv6

На деяких системах під час запуску Lighttpd виникала помилка, пов’язана з непідтримуваною сім’єю мережевих адрес.

Повідомлення вказувало, що сервер не може створити потрібний сокет.

У такому випадку відкривався основний конфігураційний файл Lighttpd:

/etc/lighttpd/lighttpd.conf

У ньому параметр використання IPv6 змінювався з увімкненого стану на вимкнений.

Після збереження конфігурації Lighttpd запускався повторно.

Якщо причина справді була пов’язана з відсутністю або неправильною конфігурацією IPv6, після зміни параметра служба починала працювати.

На сучасній системі краще спочатку правильно налаштувати IPv6, а не відключати його без перевірки. Проте для старої конфігурації CentOS цей спосіб використовувався як швидке усунення помилки запуску.

Встановлення PHP5

Сам Lighttpd обробляє статичні файли, але не виконує PHP-код без додаткового обробника.

Для запуску PHP5 використовувався механізм FastCGI. Він дозволяв вебсерверу передавати PHP-файли окремим процесам інтерпретатора.

Встановлювалися пакети:

lighttpd-fastcgi;

php-cli.

Пакет Lighttpd FastCGI додавав необхідні компоненти для передачі запитів, а PHP CLI містив виконувані файли PHP, включаючи PHP CGI.

Після встановлення потрібно було окремо налаштувати PHP та конфігурацію Lighttpd.

Налаштування PHP

У конфігураційному файлі PHP:

/etc/php.ini

додавався параметр:

cgi.fix_pathinfo = 1

Він впливав на визначення шляхів під час роботи PHP у режимі CGI або FastCGI.

Після зміни php.ini необхідно було налаштувати Lighttpd так, щоб він передавав файли з розширенням .php обробнику PHP CGI.

Увімкнення FastCGI в Lighttpd

У конфігурації модулів Lighttpd підключався файл FastCGI.

Для цього відкривався файл:

/etc/lighttpd/modules.conf

У ньому активувався рядок підключення:

include "conf.d/fastcgi.conf"

Потім редагувався окремий файл:

/etc/lighttpd/conf.d/fastcgi.conf

У ньому налаштовувалася обробка файлів із розширенням .php.

Для PHP задавалися:

шлях до UNIX-сокета;

шлях до виконуваного файлу PHP CGI;

максимальна кількість процесів;

кількість дочірніх PHP-процесів;

кількість запитів, які може обробити один процес;

параметри перевірки локального файлу;

параметри роботи зі шляхом сценарію.

У прикладі PHP CGI запускався через:

/usr/bin/php-cgi

Для різних варіантів обробки використовувалися окремі сокети в каталозі /tmp.

Один із блоків конфігурації запускав локальний PHP-процес через UNIX-сокет. Інший показував можливість підключення до FastCGI-сервера через адресу 127.0.0.1 і окремий порт.

Також демонструвався варіант із кількома PHP-процесами, де через змінні середовища встановлювалася кількість дочірніх процесів і максимальна кількість запитів до їх перезапуску.

Після внесення змін Lighttpd перезапускався.

Перевірка роботи PHP

Для перевірки роботи PHP у кореневому каталозі сайту створювався файл info.php.

У ньому викликалася стандартна функція phpinfo.

Після відкриття цього файлу через браузер відображалася детальна інформація про конфігурацію PHP:

версія інтерпретатора;

режим запуску;

шлях до php.ini;

активні розширення;

ліміти пам’яті;

максимальний розмір завантаження;

налаштування сесій;

змінні середовища;

параметри FastCGI.

У рядку Server API мав відображатися режим CGI/FastCGI. Це підтверджувало, що Lighttpd правильно передає PHP-файли окремому обробнику.

Після завершення перевірки файл info.php необхідно видалити. Він розкриває багато інформації про сервер і може бути корисним зловмиснику.

Підтримка MySQL у PHP

Наявність сервера MySQL ще не означала, що PHP може автоматично підключатися до бази даних.

Для цього потрібно було встановити відповідне розширення PHP.

У старій конфігурації використовувався пакет php-mysql.

Додатково можна було встановити інші модулі PHP, необхідні для вебзастосунків:

php-gd — обробка зображень;

php-imap — робота з поштовими скриньками;

php-ldap — підключення до LDAP;

php-odbc — робота через ODBC;

php-pear — бібліотеки та пакети PEAR;

php-xml — обробка XML;

php-xmlrpc — підтримка XML-RPC.

Список доступних модулів можна було знайти через пошук пакетів yum.

Після встановлення потрібних розширень Lighttpd перезапускався.

Потім сторінка phpinfo відкривалася повторно. У переліку модулів мала з’явитися підтримка MySQL та інші встановлені розширення.

Структура роботи системи

У результаті створювалася така схема:

браузер користувача надсилає HTTP-запит;

Lighttpd приймає запит;

статичні файли Lighttpd віддає самостійно;

PHP-файли передаються через FastCGI;

PHP CGI виконує програмний код;

за потреби PHP підключається до MySQL;

MySQL повертає дані;

PHP формує HTML-відповідь;

Lighttpd відправляє результат користувачеві.

Такий поділ дозволяв не вбудовувати PHP безпосередньо у вебсервер. PHP-процеси запускалися окремо, а Lighttpd залишався відповідальним за приймання з’єднань і обслуговування статичного вмісту.

Переваги Lighttpd

Lighttpd створювався як легкий вебсервер для систем, де важливі швидкість і економне використання ресурсів.

Його перевагами були:

невелике споживання оперативної пам’яті;

швидка обробка статичних файлів;

підтримка FastCGI;

відносно проста конфігурація;

можливість роботи на малопотужному обладнанні;

підтримка віртуальних хостів;

ведення журналів доступу та помилок.

Завдяки цим властивостям Lighttpd використовували на домашніх серверах, невеликих VPS, вбудованих системах і проєктах із невисоким навантаженням.

Можливі проблеми

Під час налаштування могли виникнути такі труднощі:

Lighttpd не запускається через неправильну мережеву конфігурацію;

PHP-файли завантажуються як текст або не виконуються;

у конфігурації не підключено fastcgi.conf;

указано неправильний шлях до php-cgi;

FastCGI не може створити сокет;

каталог сайту має неправильні права;

у PHP відсутній модуль MySQL;

служба не додана до автозапуску;

після зміни конфігурації сервер не був перезапущений.

Для пошуку причини необхідно перевіряти конфігурацію та системні журнали Lighttpd. Загальне повідомлення про помилку не завжди показує точне джерело проблеми, тому особливу увагу потрібно приділяти шляхам, сокетам, власникам файлів і підключеним модулям.

Безпека

Навіть для невеликого сервера необхідно дотримуватися базових правил захисту.

Після встановлення MySQL потрібно видалити тестову базу й анонімних користувачів, заборонити віддалений вхід root і встановити складний пароль.

Файл phpinfo після перевірки необхідно видалити.

Каталоги сайтів не слід відкривати на запис усім користувачам. Права потрібно видавати лише тим службам і обліковим записам, яким вони справді необхідні.

Також важливо контролювати відкриті порти, регулярно переглядати журнали, створювати резервні копії та своєчасно оновлювати встановлені пакети.

Сучасна альтернатива

Описана конфігурація належить до періоду використання CentOS 6.0 і PHP5.

На сучасному сервері застосовуються підтримувані операційні системи, актуальні версії PHP, MariaDB або MySQL і сучасні механізми керування процесами PHP.

Замість ручного запуску PHP CGI часто використовується PHP-FPM. Він дозволяє створювати окремі пули процесів, призначати користувачів, обмежувати ресурси й керувати сокетами.

Проте базовий принцип залишається незмінним: вебсервер приймає запит, передає PHP-код окремому обробнику, а дані зберігаються в системі керування базами даних.

Підсумок

Зв’язка Lighttpd, PHP5 через FastCGI та MySQL дозволяла створити повноцінний вебсервер на CentOS 6.0.

Спочатку встановлювалася й захищалася база даних MySQL. Потім через додатковий репозиторій встановлювався Lighttpd, налаштовувався його автозапуск і, за необхідності, вимикалася проблемна підтримка IPv6.

Для виконання PHP встановлювалися FastCGI та PHP CGI, редагувалися php.ini і конфігураційні файли Lighttpd. Після перевірки через phpinfo додавалися модулі для роботи з MySQL, зображеннями, поштою, XML та іншими можливостями.

Хоча конкретні версії програмного забезпечення вже не підходять для нового робочого сервера, матеріал добре пояснює принципи встановлення легкого вебсервера, підключення PHP через FastCGI та організації взаємодії з базою даних.