FastNetMon

Показаны сообщения с ярлыком PHP. Показать все сообщения
Показаны сообщения с ярлыком PHP. Показать все сообщения

воскресенье, 3 октября 2010 г.

Установка Apache 2.2 с поддержкой PHP 5.3.2 на FreeBSD 8.1

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

Установка Apache 2.2

cd /usr/ports/www/apache22
make install clean

Когда будет выведено окно настройки конфигурации, то оставляем там все без изменений - стандартная конфигурация довольно оптимальна.

Добавляем запуск Apache при запуске системы:
echo 'apache22_enable="YES"' >> /etc/rc.conf

Запускаем Апача:
/usr/local/etc/rc.d/apache22 start

Либо вот так покороче и поудобнее:
service apache22 start

Теперь открываем в баузере страницу: http://ip_вашего_сервера и там в случае корректной работы Apache мы должны увидеть надпись "It works!".

Конфиг Апача находится по адресу /usr/local/etc/apache22/httpd.conf, а стандартная папка для сайтов /usr/local/www/apache22/data/.

Подключение PHP 5 к Apache 2.2 в режиме mod_php

cd /usr/ports/lang/php5
make install clean

После этого при конфигурировании флагов сборки ставим галочку на "APACHE Build Apache module".

Теперь нужно собрать часто исползуемые расшрения:
cd /usr/ports/lang/php5-extensions
make install clean

При конфигурации ставим галочки (те, что уже стоят, не трогаем) на CURL, FILEINFO, BCMATH, GD, FTP, IMAP, MSTRING, MCRYPT, MYSQL, OPENSSL, SOCKETS, XMLRPC, XSL, ZIP, ZLIB.

Все остальные окошки конфигурации оставляем без изменения (их будет море, угу).

Теперь открываем конфигурацию Апача:
vi /usr/local/etc/apache22/httpd.conf

И добавляем следующее:
# возможно, эта строка уже будет добавлена, если она есть, повторно добавлять не нужно
LoadModule php5_module libexec/apache/libphp5.so
<IfModule mod_php5.c>
DirectoryIndex index.php index.html
</IfModule>
<IfModule mod_php5.c>
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
</IfModule>

Теперь перезапускаем Апача для применения изменений:
service apache22 restart

Убеждаемся, что PHP был корректно подключен к Апачу:
apachectl -M | grep php5
Syntax OK
php5_module (shared)

Создаем тестовый PHP скрипт:
echo "<? PHP echo 'Hello from PHP!'; ?>" > /usr/local/www/apache22/data/index.php

И теперь открываем веб-страницу: http://ip_вашего_сервера/index.php и там мы должны увидеть текст Hello from PHP!, который повествует о том, что связка Apache2.2 и PHP 5.3.2 корректно настроена.

По материалам: http://www.freebsd.org/doc/handbook/network-apache.html

суббота, 25 сентября 2010 г.

Fatal error: Call to undefined function finfo_open() или установка fileinfo для PHP на Debian 5

Это дополнительное расширение и его нужно ставить из PECL:
apt-get install -y libmagic-dev libmagic1
cd /usr/src
pecl download fileinfo
tar -xf Fileinfo-1.0.4.tgz
cd Fileinfo-1.0.4
phpize
./configure
make
make install
echo 'extension="fileinfo.so"' > /etc/php5/conf.d/fileinfo.ini

Все, после этого проверяем, подключилось ли расширение:
php -m | grep file

пятница, 17 сентября 2010 г.

ISPManager + Debian + PHP + виртуальный хостинг = мириады файлов в папке mod-tmp/bin-tmp

Не проходит и недели, чтобы вопрос о том, как победить эту напасть, хоть кто-то не задал на Серче (searchenegines.ru). Итак, вопрос - какого фига они создаются и не удаляются автоматически? Ранее, я поднимал одну из сторону этого вопроса (сколько именно должна храниться сессия) http://phpsuxx.blogspot.com/2010/04/php-debian.html, но там я упустил из виду ряд деталей.

Благодаря одному из наших клиентов (если он меня читает, передаю искреннюю благодарность) я обнаружил такой вот параметр работы PHP сессий:
session.gc_probability = 1

Этот параметр является числителем дроби, которая высчитывает вероятность запуска удаления старых файлов сессий при данном запуске PHP интерпретатора, вся дробь выглядит так:
p = session.gc_probability / session.gc_divisor

То есть, если при данном запуске PHP требуется удалять старые файлы сессий с вероятностью 1/100 (оптимальное дефалтное значение), то значения параметров должны быть 1 и 100 соответственно. Чтобы в свою очередь запретить удаление старых сессий, нужно задать session.gc_probability равным нулю.

Что же мы имеем в стандартной конфигурации свеже установленного Debian с панелью ISPManager? А вот что:

php -i | grep session.gc_
session.gc_divisor => 100 => 100
session.gc_maxlifetime => 1440 => 1440
session.gc_probability => 0 => 0

Внимание вопрос из начала поста - какого хрена? А вот такого (/etc/php5/cgi/php.ini):
; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_divisor,
; e.g. 1/100 means there is a 1% chance that the GC process starts
; on each request.

; This is disabled in the Debian packages, due to the strict permissions
; on /var/lib/php5. Instead of setting this here, see the cronjob at
; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below.
; php scripts using their own session.save_path should make sure garbage
; collection is enabled by setting session.gc_probability
;session.gc_probability = 0
session.gc_divisor = 100

Иными словами, в связи с особенностями системы безопасности в Debian PHP gc был полностью отключен. А что за "strict permissions /var/lib/php5" ? А вот что:
su www-data
domain:~/v001049/data$ ls -la /var/lib/php5
ls: cannot open directory /var/lib/php5: Permission denied
v1:~/v001049/data$ ls -la /var/lib/php5/sess_ffae85888b2698c46af74bcbb36a534f
-rw------- 1 www-data www-data 89 2010-09-17 04:31 /var/lib/php5/sess_ffae85888b2698c46af74bcbb36a534f
domain:~/v001049/data$ cat /var/lib/php5/sess_ffae85888b2698c46af74bcbb36a534f
current_language|i:0;vote_completed|a:0:{}gids|a:1:{i:0;s:4:"1897";}counts|a:1:{i:0;i:1;}v1:~/v001049/data$
domain:~/v001049/data$
domain:~/v001049/data$ rm /var/lib/php5/sess_ffae85888b2698c46af74bcbb36a534f

То есть, в данной папке gc PHP даже теоретически работать не может - ему запретили запрос листинга каталога. Поэтому, сессии удаляются спец-скриптом /etc/cron.d/php5, который пускается от рута по CRON и проблем с правами не имеет.

Но ISPManager ведь создает отдельные папки для сессий клиентов и дает им там полную власть (листинг каталога разрешен!), следовательно, PHP gc будет там работать отлично, поэтому, опцию session.gc_probability можно смело (по крайне мере, если PHP для клиентов работает в режиме FastCGI) приводить в вид:

session.gc_probability = 1

После подобной перенастройки strace по всем PHP процессам легко показывает, что сессии мочатся:
strace -s 1024 -e trace=unlink -f $(pidof php5-cgi | sed 's/\([0-9]*\)/\-p \1/g')
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_fb03780fa60f20c40a9a3a8a653f0a48") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_a6b769c2e42878be628e9eebcff644e1") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_72db961a3a0c427dd2ca206801822eb3") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_2cd999481257e8ddf8fdc564e9b35655") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_81a55680deea55890219ad3ce0e098aa") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_1f00aa57e21437ea859d476da63e4a3c") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_735c6fbe4e76df9cb2aacc704580f934") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_1a5261a2dd852d14c1760efc7315b43d") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_c5e5cff56c2fc56f087e9bfc96c2ae0a") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_74d6c37033f2372b7187f1bffccbda78") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_456c347c477a694f9e85bfdd8cb78919") = 0
[pid 1381] unlink("/var/www/v001218/data/bin-tmp/sess_da4e80b181f5518c282f40c1de2dc3e0") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_ebe77e387b01e9de16f82aa6c35676f3") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_916646b0ed54757bd2c64a2852430af5") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_d2039dbed4dc17b7ad34b93a8820f6cf") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_7563c763ca1e997ff418d40bb945b91b") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_92f0d552abf944226e3c86e1837167b1") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_07a81fe5c04ebedfe2f48a4d55064e9b") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_23af29de2594d854b4264eee09723141") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_7856d53ddb52613410e01495a49d2381") = 0

Вот такая вот проблемка, вот такое вот решение :)

P.S. да, Миш, ты был прав, тут я накосячил поверив чужому аудиту кода PHP.

пятница, 20 августа 2010 г.

Быстрое удаление папки bin-tmp при использовании ISPManager

cd /var/www/username/data

yum install -y screen # или apt-get intstall -y screen
install -d -g `stat -c "%G" bin-tmp` -o `stat -c "%U" bin-tmp` -m 700 bin-tmp2
mv bin-tmp bin-tmp-old
mv bin-tmp2 bin-tmp
/etc/init.d/apache2 restart
screen
rm -rf bin-tmp-old

понедельник, 31 мая 2010 г.

Как научить eAccelerator не работать c shm/sysvipc памятью, а переключить его на mmap

Имеем: eAccelerator + shm валит сервер с ошибками:

eAccelerator: shmmax should be at least 2MBPHP Warning: [eAccelerator] Can not create shared memory area in Unknown on line 0
PHP Fatal error: Unable to start eAccelerator module in Unknown on line 0
eAccelerator: Could not allocate 33554432 bytes, the maximum size the kernel allows is 1048576 bytes. Lower the amount of memory request or increase the limit in /proc/sys/kernel/shmmax.


При его сборке есть следующее:

checking for sysvipc shared memory support... yes
checking for mmap shared memory support... yes
checking for mmap on /dev/zero shared memory support... yes
checking for anonymous mmap shared memory support... yes
checking for posix mmap shared memory support... no
checking for best shared memory type... sysvipc


То есть, есть выбор между различными хранилищами, так как мой баг явно связан с sysvipc / shm, то логично будет его заменить на... на кого? В коде posix map явно указан как NOT TESTED, так что он отпадает.

Далее в configure можно найти кой что интересное:
5365 echo $ECHO_N "checking for best shared memory type... $ECHO_C" >&6; }
5366 if test "$mm_shm_ipc" = "yes"; then
5367
5368 cat >>confdefs.h <<\_ACEOF 5369 #define MM_SHM_IPC 1 5370 _ACEOF 5371 5372 msg="sysvipc" 5373 elif test "$mm_shm_mmap_anon" = "yes"; then 5374 5375 cat >>confdefs.h <<\_ACEOF 5376 #define MM_SHM_MMAP_ANON 1 5377 _ACEOF 5378 5379 msg="anonymous mmap"



Отсюда следует, что shm_mmap_anon (он же MM_SHM_MMAP_ANON) следующий в списке предпочтений.

Так что делаем следующее:
vi configure


Накатываем патч:

- 5366 if test "$mm_shm_ipc" = "yes"; then
+ 5366 if false; then


Потом перезапускаем configure и получаем все, как надо:

checking for sysvipc shared memory support... yes
checking for mmap shared memory support... yes
checking for mmap on /dev/zero shared memory support... yes
checking for anonymous mmap shared memory support... yes
checking for posix mmap shared memory support... no
checking for best shared memory type... anonymous mmap


То есть, теперь он будет собран с anonymous_mmap и, возможно, прекратит сваливать сервер.

суббота, 29 мая 2010 г.

Установка APC (Alternative PHP Cache) на Debian 5 Lenny

Офсайт проекта: http://pecl.php.net/package/APC

Установка APC из стабильного репозитория

APC в отличие от eAccelerator есть в в пакетном менеджере (версия 3.0.19-2 как раз стабильная из pecl):
apt-get install -y php-apc


После установки будет создан полу-пустой конфиг:
vi /etc/php5/conf.d/apc.ini


И мы получим стандартные настройки APC:

php -i | grep apc
/etc/php5/cli/conf.d/apc.ini,
apc
apc.cache_by_default => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => Off => Off
apc.enabled => On => On
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => no value => no value
apc.num_files_hint => 1000 => 1000
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.shm_segments => 1 => 1
apc.shm_size => 30 => 30
apc.slam_defense => 0 => 0
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 0 => 0
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 0 => 0
apc.write_lock => On => On


И настройки компиляции:
APC Support enabled
Version 3.0.19
MMAP Support Enabled
MMAP File Mask no value
Locking type pthread mutex Locks
Revision $Revision: 3.154.2.5 $
Build Date Dec 17 2008 18:21:28


Тут стоит обратить внимание на apc.stat, он обязательно должен быть включен, иначе кэш не будет обновляться при обновлении файлов, а также на apc.shm_size, это размер shm сегмента в памяти.


Баги
При установке на Debian 5 + PHP FastCGI + IonCube + Zend Optimizer + APC получаем кучу мусора в dmesg:
[1218697.911671] php[28066]: segfault at e9 ip 00007fac6f561569 sp 00007ffff4066360 error 4 in ZendOptimizer.so[7fac6f4fe000+184000]


А в error.log апача:
[Sun May 30 21:32:36 2010] [notice] mod_fcgid: process /var/www/xxx/data/www/xxxx.ru/index.php(28238) exit(communication error), get unexpected signal 11


При этом сами сайты через раз выбрасывали 500ую и ругались на Cannot found function null (или что-то в этом роде).

Так что, нужно что-то с этим делать.

Установка из исходников

Будем ставить самую новую версию.

cd /usr/src
pecl download apc-3.1.3p1
tar -xf APC-3.1.3p1.tgz
cd APC-3.1.3p1
phpize
./configure # все стандартно
make
make install


Создаем конфиг:
echo "extension=apc.so" > /etc/php5/conf.d/apc.ini


Результат: тот же самый баг. Мораль - PHP FastCGI + APC + ZendOptimizer 3.3.9 несовместимы. Вот еще багрепорт.

Некоторые фичи на тему APC + PHP FastCGI + SHM память + расшаривание одного кэша между всеми процессами. APC это не умеет, вот фич риквест: http://pecl.php.net/bugs/bug.php?id=11988

Источник: http://www.debian-administration.org/articles/574

пятница, 21 мая 2010 г.

php-fpm будет (возможно) интегрирован в PHP 5.4

Updates
Mar 17, 2010
Antony Dovgal says PHP-FPM will not be in PHP 5.3.3, but looks like PHP 5.4. Read here.

Dec 04, 2009
Antony Dovgal announces PHP-FPM has been put into a SVN branch in PHP core. This is an exciting development. It will be a while before it hits production status, but this is a great move for the future.


http://php-fpm.org/

среда, 5 мая 2010 г.

Установка syck из PECL

При попытке поставить это достижение зарубежного кодопрома:
pecl install syck-0.9.3


Вываливается облом:

checking for syck support... yes, shared
checking for syck files in default path... not found
configure: error: Please reinstall the syck distribution
ERROR: `/tmp/pear/temp/syck/configure' failed


А фича в том, что спецовая либа libsyck-dev (не либа, набор файлов) была в etch:

apt-cache search libsyck
libyaml-syck-perl - Fast, lightweight YAML loader and dumper
libsyck0-dev - YAML parser kit -- development files


Но в Ленни ее нету.

Тянем либу c офсайта http://github.com/indeyets/syck/downloads:


apt-get install bison -y
cd /usr/src
wget http://github.com/downloads/indeyets/syck/syck-0.70.tar.gz
tar -xf syck-0.70.tar.gz
cd syck-0.70
./configure --prefix=/opt/libsyck
make
make install



cd /usr/src
pecl download syck-0.9.3
tar -xf syck-0.9.3.tgz
cd syck-0.9.3
phpize
./configure --with-syck=/opt/libsyck
make
make install


Устанавливаем:
echo 'extension="syck.so"' > /etc/php5/conf.d/syck.ini


Спасибо на том, что либа не совсем либа, а кусок кода:
ldd /usr/lib/php5/20060613/syck.so
linux-vdso.so.1 => (0x00007f4073c21000)
libc.so.6 => /lib/libc.so.6 (0x00007f40736ae000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4073c22000)



P.S. поубивал бы.

вторник, 4 мая 2010 г.

Суперскоростное хранилище для PHP

Недавно узнал, что у акселератора APC (кэшера опкода) есть возможность хранения данных на время жизни процесса. Крайне удобно, я считаю :)

пятница, 30 апреля 2010 г.

Debian, PHP и Suhosin Patch

Всем известно, что PHP в Debian не простой, а с претензией на безопасность (прошу прощения за сумбурное смешение слов "безопасность" и "PHP"). Но далеко не всем известно, что работает он "молча", то есть если он и исправляет какие-то проблемы, то делает это молча, без записи в логи. Также есть ряд скриптов, которые ломаются от Сухосина и это никак не отражается в логах.

Для того, чтобы Suhosin начал писать в логи необходимо в php.ini добавить следующее:
; suhosin looging enabled
suhosin.log.sapi = 511


А вот примеры его записей в логи (взято из кода):

zend_suhosin_log(S_MEMORY, "possible memory corruption detected - unknown llist destructor");
zend_suhosin_log(S_MEMORY, "linked list corrupt on efree() - heap corruption detected");
zend_suhosin_log(S_MEMORY, "canary mismatch on " MFUNCTION " - heap overflow detected");


Вот ссылочка с описанием всех параметров:
http://www.hardened-php.net/suhosin/configuration.html

суббота, 17 апреля 2010 г.

Debian, конфигурация PHP, max_execution_time и папочка conf.d

Допустим, есть конфиг /etc/php5/cgi/php.ini и в нем задана опция:

max_execution_time = 90


и есть файл:
/etc/php5/conf.d/my.ini

в нем этот параметр перекрыт:

max_execution_time = 91


То какое значение примет PHP?

Вот такое:
php5-cgi -i | grep max_exec
max_execution_time 91

Причем, у PHP как модуля Apache подход в точности такой же.

А CLI же версии решительно на всех пофигу:
php5 -i | grep max_exec
max_execution_time => 0 => 0


Иными словами, больший приоритет имеет то, что находится в папке conf.d, а не в родном php.ini.

вторник, 13 апреля 2010 г.

PHP FastCGI + php_admin_value, php_admin_flag, php_value, php_flag

Как известно, эти команды указываются в .htaccess и должны поидее читаться модулем PHP для Апача, но когда последний не используется, а используются, скажем, PHP FastCGI / CGI, то эти директивы будут просто-напросто проигнорированы и эффекта не возымеют.

Но есть проблема - есть фикс! Вот что говорят ребята из Zend: http://kb.zend.com/index.php?View=entry&EntryID=259

А именно:

Using htscanner - htaccess support for PHP
Description: Allow one to use htaccess-like file to configure PHP per directory, just like apache's htaccess.
It is especially useful with fastcgi.


А вот ссылка на этот самый HTScanner: http://pecl.php.net/package/htscanner

Краткое описание от авторов этого самого мегаэкстеншена:
Allow one to use htaccess-like file to configure PHP
per directory, just like apache's htaccess. It is especially useful with fastcgi (ISS5/6/7, lighttpd, etc.).
This package was originally developed by Bart Vanbrabant. Old versions are available
from: http://files.zoeloelip.be/htscanner


Еще есть фича - если у Вас используется FastCGI, но при этом подключен PHP как модуль Апача, то все будет ок - php_* директивы будут проигнорированы, а вот если используется только FastCGI и PHP модуль в принципе отключен, то будет ошибка :) Но тут приходит на модуль модуль mod_fakephp, который подавляет выдачу ошибок при обнаружении опций PHP в .htaccess: http://www.dmi.me.uk/code/apache/mod_fakephp/

За наводку огромный респект arp`у: http://highloaded.blogspot.com/2010/04/htaccess-phpflag-with-fastcgi-on-debian.html и вот еще отличная статья с интересным подходом: http://dromok.ru/?p=104

Вот мой мануал по настройке этого чуда: http://phpsuxx.blogspot.com/2010/04/php-htscanner-debian-phpflag-htaccess.html А вот мануал в моем блоге: http://phpsuxx.blogspot.com/2011/01/modfakephp-debian.html

пятница, 2 апреля 2010 г.

Очистка файлов сессий PHP в Debian, через какое время это делать?

На долго работающих системах образуются папки /tmp или mod-tmp (либо bin-tmp) в случае использования ISPManager размером в миллионы и десятки миллионов файлов с файлами PHP сессий sess_тут_длинный_код, которые служат для временного хранения сессий от пользователей. То, что это наносит ущерб производительности файловой системы - однозначно (попробуйте пролистать такую папку ls ом или хотя бы удалить), поэтому их надо удалять. Возникает вопрос - как часто их можно удалять, чтобы не повредить работе приложений их использующих?

В комментариях к конфигу в Debian 5 Lenny сказано следующее:

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440

; NOTE: If you are using the subdirectory option for storing session files
; (see session.save_path above), then garbage collection does *not*
; happen automatically. You will need to do your own garbage
; collection through a shell script, cron entry, or some other method.
; For example, the following script would is the equivalent of
; setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
; cd /path/to/sessions; find -cmin +24 | xargs rm


Как можно понять из текста, за время жизни файлов сессий отвечает переменная session.gc_maxlifetime, которая стандартно выставлена в 1440 секунд или 24 минуты. Также для определения этого промежутка на основе значений, заданных в системных php.ini, в Debian есть служебный скрипт:

/usr/lib/php5/maxlifetime
24


Все хорошо и прекрасно. Да, отчасти. А что будет, если кто-то из авторов CMS написал такую систему авторизации пользователей, которая работает на таких вот сессиях и, например, именно по ним проверяет залогиненость пользователя? Правильно, его вышибет. Думаете никто так не сделает? Ошибаетесь: http://php.net/manual/en/ref.session.php

Итого, резюмирую - лично я эту папку чистить буду не чаще раза в 2 недели (ну по крайней мере GMail и Yandex.Mail меня примерно через это время выкидывают и заставляют повторно авторизироваться), это самый безопасный путь. Других нету, увы.