Показ дописів із міткою Apache. Показати всі дописи
Показ дописів із міткою Apache. Показати всі дописи

пʼятниця, 5 квітня 2013 р.

Другий екземпляр Apache: архівна схема SysV init та узгодження конфігурації

У квітні 2013 року виникла потреба запустити другий екземпляр Apache, використовуючи той самий виконуваний файл. Для незалежної роботи потрібно розділити конфігурації, адреси й порти прослуховування, PID-файли та журнали. Два процеси самі по собі не створюють відмовостійкого сервісу.

Нижче збережено початкові команди для середовища з SysV init та пояснено помилки в узгодженні шляхів. На сучасній системі спосіб керування службою слід узгодити з її пакетом і менеджером служб.

Окремі файли й журнали

Початкова схема спиралася на /etc/apache2/apache2.conf, /etc/apache2/ports.conf і /etc/apache2/envvars. Журнали задавалися директивами:

ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/other_vhosts_access.log vhost_combined

У старій системі копіювали init-скрипт та додавали його в автозапуск:

cd /etc/init.d
cp apache2 apache2_srv
update-rc.d apache2_srv defaults

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

PIDFILE=`. /etc/apache2/envvars ; echo $APACHE_PID_FILE`
if [ -z "$PIDFILE" ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars >&2
exit 2
fi

використовували окремий файл середовища:

PIDFILE=`. /etc/apache2/envvars_apache2_srv ; echo $APACHE_PID_FILE`
if [ -z "$PIDFILE" ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars_apache2_srv >&2
exit 2
fi
ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin APACHE_ENVVARS=/etc/apache2/envvars_apache2_srv"
cp /etc/apache2/envvars /etc/apache2/envvars_apache2_srv

У копії змінювали PID-файл:

export APACHE_PID_FILE=/var/run/apache2.pid

на:

export APACHE_PID_FILE=/var/run/apache2_apache_2.pid

Окремий файл портів у першій частині нотатки називався /etc/apache2/ports_apache_srv.conf і містив:

Listen 81

Для журналів наводилися такі команди:

touch /var/log/apache2/error_apache2_srv.log
touch /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:root /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:adm /var/log/apache2/error_apache2_srv.log
chmod 640 /var/log/apache2/error_apache2_srv.log

Передавання команд потрібному екземпляру

У старому init-скрипті був такий блок запуску; у тому середовищі кеш не використовувався:

start)
log_daemon_msg "Starting web server" "apache2"
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
fi
log_end_msg 0
else
log_end_msg 1
fi
;;

Початковий виклик:

APACHE2CTL="$ENV /usr/sbin/apache2ctl"

замінювали на:

APACHE2CTL="$ENV /usr/sbin/apache2ctl -f /etc/apache2/apache2_srv.conf"

Відповідно змінювали команди:

$APACHE2CTL -k start
$APACHE2CTL -k stop
$APACHE2CTL -k graceful
$APACHE2CTL -t

Документація Apache пояснює: -f вибирає конфігурацію, -k задає дію керування, -t перевіряє синтаксис. Потрібні саме узгоджені налаштування цільового екземпляра.

Пошук процесів: недолік старого підходу

Початок функції у старому скрипті:

pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=`pidof apache2` || true

пропонувалося замінити таким фрагментом:

pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=`ps aux | grep 'apache2_srv' | grep -v 'grep' | awk '{print $2}' | xargs` || true

Обидва уривки є лише початками функції. Пошук через grep залежить від тексту командного рядка й може вибрати не той процес. Загальний pidof apache2 також не розрізняє потрібні екземпляри. Для керування слід використовувати відповідну службу та її окремий PidFile.

Узгодження імен і перевірка запуску

Перша спроба в нотатці завершилася так:

/etc/init.d/apache2_srv start
Starting web server: apache2apache2: Could not open configuration file
/etc/apache2/apache2_failover.conf: No such file or directory
failed!

Помилка посилалася на apache2_failover.conf, хоча вище було задано apache2_srv.conf. Перед запуском потрібно виправити всі виклики, щоб вони посилалися на один обраний файл. У нотатці його створювали так:

cp /etc/apache2/apache2.conf /etc/apache2/apache2_srv.conf

Наприкінці наводилися:

CustomLog /var/log/apache2/other_vhosts_access_apache2_srv.log vhost_combined
ErrorLog /var/log/apache2/error_apache2_srv.log
Include /etc/apache2/ports_apache2_srv.conf

Тут є ще одна розбіжність: раніше файл портів називався ports_apache_srv.conf, без «2» після apache. Назва у Include має точно збігатися з реально створеним файлом. Перевірте також, чи не підключає новий конфіг спільні файли з конфліктними Listen, віртуальними хостами або PID-шляхами.

У початковому тексті згадувалися NameVirtualHost xx.xx.xx.xx:80 та VirtualHost xx.xx.xx.xx:81. Адреси й порти потрібно узгоджувати з Listen. У сучасній гілці Apache 2.4 NameVirtualHost вже не впливає на роботу.

Старий запис завершувався успішним запуском:

/etc/init.d/apache2_srv start
Starting web server: apache2.

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

субота, 29 січня 2011 р.

Оптимізація вебсервера: досвід 2011 року та сучасні уточнення

Перед придбанням додаткових серверів корисно виміряти, куди витрачаються ресурси наявної системи. У січні 2011 року я описав досвід оптимізації вебпроєктів «Корпорація 2»: кешування CMS, розподіл запитів між Nginx і Apache, роботу PostgreSQL через PgBouncer та кешування PHP-коду.

Цей матеріал зберігає історичний досвід і конфігурації. Команди для PHP 5, XCache, eAccelerator та APC наведено для розуміння старих систем; під час нового розгортання потрібні підтримувані компоненти й налаштування відповідної версії.

1. Кешування CMS і статичні сторінки

У власних давніх дослідах я спостерігав дуже велику різницю між видачею статичного файла та повною генерацією сторінки CMS; у початковій нотатці зазначено діапазон 1 000–10 000 разів. Без опису стенда, запитів і методики це не можна сприймати як універсальний коефіцієнт.

Практичним результатом стала переробка кешування «Корпорація 2»: із динамічного вмісту формували статичні сторінки. Це зменшило повторні обчислення та навантаження на сервер. Для змінних або персоналізованих даних потрібно окремо визначати, коли кеш оновлюється і кому можна показувати збережений результат.

2. Nginx перед Apache

У тодішньому середовищі використовували два рівні вебсервера. Nginx мав самостійно віддавати статичні ресурси й передавати Apache лише ті запити, які потребували його обробки. Мета — уникнути зайвої роботи другого рівня.

Сьогодні конкретний шлях запиту може бути іншим, наприклад із PHP-FPM. Вибір архітектури визначається застосунком. Для проксі-кешування Nginx має окремі директиви proxy_cache; їх не слід плутати з простим передаванням запитів або видачею статичних файлів.

3. PostgreSQL і PgBouncer

У 2011 році в нотатці зазначено понад 500 користувачів онлайн у нашому середовищі. Це опис конкретної експлуатації, а не гарантія такої самої пропускної здатності для іншої системи: кількість відвідувачів не дорівнює кількості одночасно активних запитів.

PgBouncer керує пулом з'єднань PostgreSQL. Режими session, transaction і statement pooling мають різні правила; транзакційний режим обмежує частину можливостей, пов'язаних із сесією. Перед зміною режиму перевіряйте сумісність застосунку.

4. Історичне налаштування XCache

Тоді після порівняння варіантів я обрав XCache. У матеріалі з hilik.org.ua наведено встановлення з портів FreeBSD:

cd /usr/ports/www/xcache/
make install clean
cp /usr/local/share/examples/xcache/xcache.ini /usr/local/etc/php/

Збережений приклад xcache.ini:

[xcache-common]

extension = xcache.so

#Включим админ интерфейс

[xcache.admin]

xcache.admin.enable_auth = On

xcache.admin.user = "admin"

#В качестве пароля укажем md5 хеш, создать его можно с 

#помощью команды md5 -s "ваш пароль"

xcache.admin.pass = "XXXXXX"



[xcache]

xcache.shm_scheme =        "mmap"

#Выделим для кеша 128 мегабайт

xcache.size  =                128M

xcache.count =                 1

xcache.slots =                8K

xcache.ttl   =                 0

xcache.gc_interval =           0

xcache.var_size  =            0M

xcache.var_count =             1

xcache.var_slots =            8K

xcache.var_ttl   =             0

xcache.var_maxttl   =          0

xcache.var_gc_interval =     300

xcache.test =                Off

xcache.readonly_protection = Off

xcache.mmap_path =    "/dev/zero"

xcache.coredump_directory =   ""

xcache.cacher =               On

xcache.stat   =               On

xcache.optimizer =            On



[xcache.coverager]

xcache.coverager =          On

xcache.coveragedump_directory = ""

У прикладі для кешу виділено 128 МБ. Значення XXXXXX — заповнювач, не готовий пароль. Стара нотатка пропонувала створювати MD5-хеш командою md5 -s "ваш пароль". Це частина історичного механізму XCache, а не рекомендація щодо сучасного зберігання паролів.

Тоді адміністративні файли копіювали з /usr/local/share/examples/xcache/admin до кореня сайту, щоб переглядати статистику. Службовий інтерфейс потребує обмеженого доступу; розміщення у відкритому вебкаталозі саме собою його не захищає.

У початковому переказі були дві неточності: кеш опкодів зберігає скомпільоване представлення PHP-коду, а не обов'язково результат кожного запиту; code coverage dumper стосується покриття виконання коду, а не запобігання переповненню пам'яті. Порівняння швидкодії XCache з іншими кешами без методики тесту також не є загальною гарантією.

5. Історичне встановлення eAccelerator

Наступний фрагмент стосувався PHP 5 та eAccelerator 0.9.6.1:

$ sudo apt-get install php5-dev build-essential



Далее получаем исходные тексты eAccelerator:



$ cd /tmp/

$ wget http://bart.eaccelerator.net/source/0.9.6.1/

eaccelerator-0.9.6.1.tar.bz2

$ tar xvjf eaccelerator-0.9.6.1.tar.bz2

$ cd eaccelerator-0.9.6.1

$ phpize

$ ./configure --enable-eaccelerator=shared

$ make

$ sudo make install

У збереженій команді wget адреса архіву розірвана переносом рядка. Її не слід виконувати як готову послідовність. Це давнє джерело HTTP-завантаження, а не перевірений спосіб установлення сучасного розширення.

Старі команди підготовки каталогу:

$ sudo mkdir -p /var/cache/eaccelerator
$ sudo chmod 0777 /var/cache/eaccelerator

Режим 0777 дає запис усім локальним користувачам. Цей рядок збережено для точності архіву; для робочої системи слід призначити потрібного власника та мінімальні права відповідно до способу запуску процесів.

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

# vi /etc/php5/apache2/php.ini

[PHP]

; Подключаем расширение

extension = "eaccelerator.so"

eaccelerator.enable = "1"

; Максимальный размер дискового кэша (Мб)

eaccelerator.shm_size = "64"

; Каталог для хранения кэша

eaccelerator.cache_dir = "/var/cache/eaccelerator"

; Включаем оптимизатор кода

eaccelerator.optimizer = "1"

; Перекомпилировать модифицированные скрипты

eaccelerator.check_mtime = "1"

; Отключаем режим отладки

eaccelerator.debug = "0"

; Кэшировать все файлы (пустой фильтр)

eaccelerator.filter = ""

; Неограниченный размер кэша в памяти

eaccelerator.shm_max = "0"

; В случае отсутствия места в кэше удалять объекты старше

1 часа (3600 секунд)

eaccelerator.shm_ttl = "3600"

eaccelerator.shm_prune_period = "0"

; Кэшировать данные и в памяти, и на диске

eaccelerator.shm_only = "0"

; Сжимать кэшированные данные с максимальным уровнем компрессии

eaccelerator.compress = "1"

eaccelerator.compress_level = "9"

Перенос усередині коментаря про 3600 секунд у старому фрагменті також потребує виправлення перед будь-яким використанням. Твердження про прискорення «у десятки разів» було оцінкою з тодішнього матеріалу; методику такого результату не наведено.

6. APC у матеріалах того часу

Огляд із phpcoder.ws/2009-02/apc-setup.html описував установлення через пакет Debian/Ubuntu або PECL:

sudo aptitude install php-apc
sudo pecl install apc
extension=apc.so

Після підключення розширення пропонували перезапустити Apache й переглянути статистику через apc.php. Для Debian наводили каталог /etc/php5/apache2/conf.d/. Діагностичні сторінки не слід залишати загальнодоступними.

У тому огляді повідомляли про приріст швидкості генерації сторінок на 40% для Joomla 1.5.9: 1 000 звернень до головної сторінки у п'яти потоках за допомогою ab2. Це результат конкретного старого тесту, який тут не відтворювався.

Зазначені там обмеження щодо FastCGI, mod_php, CLI та версій PHP відображають старий переказ і не утворюють точного універсального опису всіх випусків APC. Сторінка пакета APC нині повідомляє, що він не підтримується та замінений APCu.

Що перевіряти у сучасному середовищі

Для кешування байткоду PHP використовується OPcache: він зберігає попередньо скомпільований код у спільній пам'яті й зменшує потребу повторного розбору скриптів. Це окремий рівень від кешу даних і готових HTTP-відповідей.

Починайте з вимірювання часу відповіді, навантаження процесора, пам'яті, запитів до бази та частки влучань у кеш. Змінюйте налаштування поступово й порівнюйте результат на однаковому навантаженні. Так можна визначити реальне вузьке місце та обґрунтовано вирішити, чи потрібне потужніше обладнання.

вівторок, 17 березня 2009 р.

Помилка APXS під час складання старого PHP: архівний приклад

Ця нотатка з’явилася під час пошуку підтримки TTF-шрифтів і JPEG у тодішньому середовищі Ubuntu 8.10. Наведений нижче приклад походить зі старої інструкції та містить навіть ім’я архіву PHP 4; його не можна сприймати як команду для встановлення сучасного PHP.

Історичне джерело: http://ez.no/developer/articles/the_ez_publish_web_server_environment/building_and_installing_php. Адреса завантажень, на яку посилався оригінал: php.net/downloads.php.

Послідовність із первинної публікації

cd /usr/local/src
gunzip < /PATH/TO/php-4.x.x.tar.gz | tar xvf -
./configure --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/usr/local/apache/conf --with-mysql --enable-memory-limit --enable-mbstring --with-ttf --with-gd --with-jpeg-dir --enable-gd-native-ttf --with-png-dir --with-freetype-dir --with-zlib --with-dom --enable-exif
make
make install

Помилка APXS

Під час конфігурації з’являлося повідомлення:

Sorry, I was not able to successfully run APXS. Possible reasons: 
1. Perl is not installed; 
2. Apache was not compiled with DSO support (--enable-module=so); 
3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs 
The output of /usr/local/apache/bin/apxs follows 
./configure: line 4521: /usr/local/apache/bin/apxs: No such file or directory 
configure: error: Aborting

Останній рядок про відсутність /usr/local/apache/bin/apxs вказує насамперед на недоступний шлях до інструмента. Перелік вище містить можливі причини, а не доводить, що Perl обов’язково відсутній або що Apache неодмінно треба перекомпілювати.

В оригіналі також було наведено варіант без параметра APXS:

./configure --with-config-file-path=/usr/local/apache/conf --with-mysql --enable-memory-limit --enable-mbstring --with-ttf --with-gd --with-jpeg-dir --enable-gd-native-ttf --with-png-dir --with-freetype-dir --with-zlib --with-dom --enable-exif

Прибирання --with-apxs змінює спосіб інтеграції з Apache; це не просто «збірка без потреби в Perl» і не рівнозначне встановленню того самого модуля вебсервера.

Для сучасного середовища звіряйте параметри GD та інструкцію PHP для Apache 2. Старі прапорці на кшталт --with-gd, --with-jpeg-dir та --with-freetype-dir залежать від покоління PHP; починаючи з PHP 7.4 для відповідних можливостей використовуються інші параметри.

Історичне складання PHP з GD, FreeType та JPEG: Ubuntu 8.10

Ця нотатка з’явилася під час пошуку підтримки TTF-шрифтів і JPEG у тодішньому середовищі Ubuntu 8.10. Наведений нижче приклад походить зі старої інструкції та містить навіть ім’я архіву PHP 4; його не можна сприймати як команду для встановлення сучасного PHP.

Історичне джерело: http://ez.no/developer/articles/the_ez_publish_web_server_environment/building_and_installing_php. Адреса завантажень, на яку посилався оригінал: php.net/downloads.php.

Послідовність із первинної публікації

cd /usr/local/src
gunzip < /PATH/TO/php-4.x.x.tar.gz | tar xvf -
./configure --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/usr/local/apache/conf --with-mysql --enable-memory-limit --enable-mbstring --with-ttf --with-gd --with-jpeg-dir --enable-gd-native-ttf --with-png-dir --with-freetype-dir --with-zlib --with-dom --enable-exif
make
make install

Помилка APXS

Під час конфігурації з’являлося повідомлення:

Sorry, I was not able to successfully run APXS. Possible reasons: 
1. Perl is not installed; 
2. Apache was not compiled with DSO support (--enable-module=so); 
3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs 
The output of /usr/local/apache/bin/apxs follows 
./configure: line 4521: /usr/local/apache/bin/apxs: No such file or directory 
configure: error: Aborting

Останній рядок про відсутність /usr/local/apache/bin/apxs вказує насамперед на недоступний шлях до інструмента. Перелік вище містить можливі причини, а не доводить, що Perl обов’язково відсутній або що Apache неодмінно треба перекомпілювати.

В оригіналі також було наведено варіант без параметра APXS:

./configure --with-config-file-path=/usr/local/apache/conf --with-mysql --enable-memory-limit --enable-mbstring --with-ttf --with-gd --with-jpeg-dir --enable-gd-native-ttf --with-png-dir --with-freetype-dir --with-zlib --with-dom --enable-exif

Прибирання --with-apxs змінює спосіб інтеграції з Apache; це не просто «збірка без потреби в Perl» і не рівнозначне встановленню того самого модуля вебсервера.

Для сучасного середовища звіряйте параметри GD та інструкцію PHP для Apache 2. Старі прапорці на кшталт --with-gd, --with-jpeg-dir та --with-freetype-dir залежать від покоління PHP; починаючи з PHP 7.4 для відповідних можливостей використовуються інші параметри.

субота, 14 лютого 2009 р.

Динамічні URL в Apache/PHP: чотири історичні підходи та виправлення

У лютому 2009 року я зберіг нотатку про формування зрозумілих URL для динамічних сторінок Apache/PHP. Джерелом був матеріал woweb.ru/publ/36-1-0-336. У ньому розглядали чотири підходи: обробник помилки 404, MultiViews, ForceType і mod_rewrite.

Нижче збережено початкові фрагменти коду як історичні приклади. Вони залежать від конфігурації Apache та способу підключення PHP; некоректні конструкції окремо пояснено.

1. Обробник ErrorDocument

ErrorDocument 404 script.php

Старий підхід пропонував обробляти вигаданий URL у скрипті, викликаному замість відсутньої сторінки. Наведений рядок не є готовим маршрутизатором: значення ErrorDocument має відповідати синтаксису Apache. Для наявної сторінки та справді відсутнього ресурсу потрібні різні результати обробки й HTTP-статуси.

2. MultiViews

Options Multiviews

У нотатці припускали, що шлях на кшталт /one/two/three буде зіставлено з файлом one.php, а залишок обробить скрипт. Насправді MultiViews належить до узгодження вмісту: добір варіанта залежить від розширень і налаштувань. Це пояснює документація Apache. Такий механізм не є універсальною заміною маршрутизації.

3. ForceType та обробник PHP

<filesmatch index="">
      ForceType application/x-httpd-php
</filesmatch>

Цей блок у збереженому HTML мав некоректний запис секції FilesMatch, тому його не можна копіювати як чинну конфігурацію. ForceType задає тип вмісту; використання спеціального MIME-типу для запуску PHP залежало від історичної поведінки модулів. Apache рекомендує уникати такого покладання на «магічні» типи та налаштовувати обробник явно. Для PHP-FPM потрібна конфігурація відповідного способу підключення.

4. Правила mod_rewrite

RewriteEngine On
Options +FollowSymlinks
RewriteBase /
RewriteRule ^index/(.*)$ /index.php/$1

Модуль переписує шлях index/... у /index.php/.... Це не обов'язково зовнішнє перенаправлення браузера: переписування може бути внутрішнім. Контекст правила й прапорці визначають результат; дивіться mod_rewrite. Директива RewriteEngine сама собою не обмежує правила лише поточним каталогом.

У джерелі було й комбіноване налаштування:

RewriteEngine On
RewriteBase /
RewriteRule ^index/(.*)$ /index.php/$1
<filesmatch index.php="">
      ForceType application/x-httpd-php
</filesmatch>

Воно містить таку саму проблему запису FilesMatch. Приклад із сайтом webshops.ru пояснював задум: запит /index/webshops обробляє index.php, який визначає потрібну сторінку за URI. Це ілюстрація маршруту з давнього матеріалу, а не перевірена конфігурація цього сайту сьогодні. Замість старої змінної $REQUEST_URI у сучасному PHP зазвичай використовують $_SERVER['REQUEST_URI'].

HTTP-заголовки та дата зміни

Початковий матеріал пропонував такі рядки:

Header("HTTP/1.0 200 OK"); //строка нужна только для п. 1
Header("Last-Modified: ".gmdate("D, M d Y H:i:s",filemtime("index.php"))." GMT"); //строка пригодится в любом случае

header() потрібно викликати до фактичного виведення вмісту. Не варто безумовно повертати 200 для будь-якого невідомого URL: відсутній ресурс має залишатися помилкою, інакше можливий soft 404.

Час зміни файла index.php не обов'язково відповідає часу зміни даних усіх сторінок, які він формує. Крім того, у форматі дати старого фрагмента переплутано порядок дня та місяця. Для HTTP-дати потрібен порядок на кшталт D, d M Y H:i:s у GMT; значення Last-Modified має описувати саме відповідне представлення ресурсу — дивіться RFC 9110.

Відносні адреси зображень

У віртуальних каталогах старий матеріал пропонував абсолютні адреси або елемент base у секції head:

<base href="http://ваш_сайт.ru/"></base>

Домен у цьому рядку — заповнювач. За стандартом HTML елемент base не має закривального тега; він впливає на всі відносні URL документа. Після зміни маршрутизації перевірте зображення, стилі, скрипти, форми та звичайні посилання.

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

середа, 6 лютого 2008 р.

Установлення Magento: як я розв’язав проблему відображення кирилиці

У лютому 2008 року я нарешті знайшов час установити Magento для тестування. Інсталяція загалом пройшла без проблем: знадобилося додати модулі Apache й налаштувати права доступу. Однак замість кирилиці браузер показував некоректні символи. Я спробував ввести текст — і знову проблема. Спочатку навіть подумав, що рушій недопрацьований.

Рішення в тому середовищі

Після пошуку на форумі Magento я додав у .htaccess рядок:

AddDefaultCharset utf-8

Додав — і в моїй конфігурації все запрацювало: браузер правильно визначав UTF-8, текст відображався коректно. Тоді я зміг повернутися до знайомства з Magento.

Що саме змінює директива

За документацією Apache, AddDefaultCharset задає параметр charset для відповідей типу text/plain і text/html. Вона не перетворює фактичне кодування байтів і сама собою не виправляє дані в базі. Отже, результат цього випадку не доводить універсальності рішення для всіх помилок кирилиці.

Перед застосуванням потрібно узгодити реальне кодування сторінки, заголовок відповіді та налаштування застосунку. Apache радить задавати спільне кодування так лише для ресурсів, про які відомо, що вони мають однакове кодування.

неділя, 23 грудня 2007 р.

Firebird у PHP 5 та Apache 2 на Ubuntu: історичне налаштування

У 2007 році я налаштовував доступ із PHP 5 до Firebird в Ubuntu з Apache 2. У конкретному середовищі потрібного пакета не було серед установлених компонентів, тож я знайшов окремий пакет розширення.

Пакет і конфігурація 2007 року

Використовувався файл php5-interbase_5.2.1-1_i386.deb розміром 37,0 КБ. Історична адреса: http://launchpadlibrarian.net/7557695/php5-interbase_5.2.1-1_i386.deb.

dpkg -i php5-interbase_5.2.1-1_i386.deb

Після встановлення я перезапускав Apache. У знайденій інструкції також пропонувалося створити файл /etc/php5/conf.d/interbase.ini із таким вмістом:

# configuration for php interbase module
extension=interbase.so

Потреба в окремому ini-файлі залежала від того, як пакет налаштовував модуль. Назва пакета з i386 стосувалася конкретної архітектури; переносити його на сучасну систему як універсальне рішення не можна.

Відмінність від сучасного PHP

За документацією переходу на PHP 7.4, розширення Firebird/InterBase було винесено з основного постачання до PECL починаючи з PHP 7.4. Для доступу до Firebird також є драйвер PDO_FIREBIRD. Вибирайте спосіб підключення за версією PHP, клієнтської бібліотеки й середовища.

Firebird та InterBase — окремі продукти. Походження та розвиток Firebird описані на сайті самого проєкту.

неділя, 9 вересня 2007 р.

Регулярні зупинки Apache: як у 2007 році помітили закономірність

У вересні 2007 року на сервері нашого порталу nerusoft.com з’явилася дивна закономірність: щонеділі приблизно між 7:30 та 8:00 припиняв працювати Apache. Причина залишалася незрозумілою, зате час повторювався надто чітко, щоб ігнорувати його.

Що ми вже знали

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

Через такі зупинки портал міг не відкриватися приблизно з 7:30 до 8:10. Я сподівався згодом знайти причину. Принаймні закономірність уже вдалося помітити — це була відправна точка для подальшого пошуку.

Як досліджувати подібну періодичність

У схожій ситуації варто зіставити точний час зупинки із записами журналу помилок Apache та системними подіями. Потім перевірити завдання за розкладом, резервування й ротацію журналів. Це напрями перевірки, а не встановлена причина нашого випадку.

В офіційній документації Apache 2.4 про журнали журнал помилок описано як перше джерело діагностики проблем запуску й роботи сервера. Документація про зупинку та перезапуск допомагає розрізняти ці операції. Сам збіг часу ще не доводить, який саме процес зупинив сервер.

K2 відкрила курс з ERP: 61 урок, практика й сертифікат

Перший день у новій ERP часто починається з пошуку потрібної кнопки. Наступний виклик складніший: зрозуміти, що зміниться після натискання. ...