docker, php, fpm - не работает healthcheck

 В случае фпм нельзя сделать курл на fastcgi порт, и особенно на сокет.

На помощь приходит https://github.com/renatomefi/php-fpm-healthcheck

Хинт для убунты: вместо apk install fcgi нужно apt install libfcgi-bin

laravel: add sail

 Есть уже готовый пакет, который готовит docker-compose.yml. Но дальше есть нюансы..

groupadd: invalid group ID 'sail' 

Фикс:

echo 'WWWGROUP=1000

WWWUSER=1000' >> .env

https://stackoverflow.com/questions/67224488/laravel-sail-wont-build-on-ubuntu-20-04-groupadd-invalid-group-id-sail

Docker + php - что брать за основу?

 Из-за ряда особенностей alpine тут не лучший выбор (и см ниже), хотя и он будет работать.

1) FROM php:8.2-fpm и вариации

Плюсы: сообщество любит именно эти образы, как "оригинальные". При этом например FROM php:5.4 сам образ скачает, но что-то поставить туда уже не выйдет, всё дропнуто давно (впрочем, пока ещё можно взять centos:7 и там как раз 5.4 штатно, но об этом дальше)

Докерфайл под нужный движок гуглится за несколько минут

Минусы: 

- лютое неудобство писать докерфайлы, потому что какие-то модули уже стоят (mbstring) и попытка их собрать обламывается (нет модуля онигурама), но об этом надо или просто знать, или гуглить, сама установка требует чтения док на тему docker-php-ext-configure + docker-php-ext-install, то есть опять чтения доков что конкретно надо на каждый модуль... Конечно всё решаемо, но можно легко потерять несколько дней на полной ерунде.

- Нагугленные версии файлов часто не собирают, нужно править ошибки, например

docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr --with-webp-dir=/usr 

а потом оказывается что и путь не нужен, и -dir пропадает (--with-png), и один из with в принципе.. Иногда нужно -dev пакетов докидывать и так далее.

А ещё полно таких приколов:

&& git clone -b php7 https://github.com/phpredis/phpredis.git /usr/src/php/ext/redis && docker-php-ext-install redis \ ....

- если нужен не очень стандартный модуль - это начинается доолгий квест или с поиском такого в чужих докерфайлах, или чтение док. Проблема тут больше в том, что это нужно не один раз, а на каждый нестандартный модуль. Впрочем, фермошлёпы с типовыми решениями - не столкнутся.

2) FROM ubuntu:22.04, вариант debian:11 или вообще centos:7

Плюсы: если проект уже катили прямо на машину, то есть обкатанные процедуры, список версий давно подобран и проверен, написать с нуля докерфайл - минуты, и он почти гарантированно выдаст рабочую сборку.

Полнейшее единообразие с тем что собирается в режиме хоста, минимальное количество багов из-за смены платформы.

Возможность ставить конкретную версию, если оказалось что последняя версия нам что-то ломает, как минимум на время исправления нашего/их кода, возможность сделать фриз нужных пакетов

Минусы: штатно в дистрибутиве есть только одна версия, если нужно другую то нужно подключать того же Ondrej. Но при условии что платформа уже была где-то развёрнута - всё нужное и так известно. И даже нужные модули, собранные руками, просто копируем отдельным шагом и получаем тот же результат.

3) FROM composer:2

Подвид п.1, только на базе alpine, c docker-php-ext-install и подобным. Иногда вылезают косяки с заменой libc.

С другой стороны, очень хороший вариант, если сначала собрали все нужные модули, подготовили vendor/ итд, и потом COPY --from= перенесли только нужное в новый пустой альпин образ. Это будет меньше обычного и достаточно безопасно.

4) брать уже готовые образы, типа FROM octobercms/october-dev, но именно с октобером вообще прикол - у оф образа 4 звезды, а у "левого" aspendigital/octobercms - 41. И что брать? Хотя и тут понятно, у aspendigital последняя версия пхп 7.4, а уже желательно 8.0 и выше.

Итого: попытки поднять вопрос "что брать за основу" по чатам показали, что нет явного преимущества ни у одного метода. Обычно говорили про скорость сборки (вот только компиляция из п.1 конечно "быстрее" чем apt install уже собранного, да), размеры (именно в данном случае итоговый образ обычно выходит больше гигабайта в обоих случаях, и опять же, компилятор со всеми библиотеками никогда не будет занимать меньше места чем минимальная версия дистрибутива, куда сделали apt install --no-install-recommends), безопасность - но никто не смог объяснить в чём тут безопасность.. При этом помним важное правило безопасности - нужно брать именно проверенные слои в прод. И тут первый метод самый слабый, если в случае п.2 мы обнаружили проблему - можем явно указать рабочую версию и пересобрать контейнер, то в п.1 нужно зарываться в гит-версии и прочее, если мы свои промежуточные сборки не версионировали и всё было latest.

А если погрузиться в multi-stage builds, кэширование слоёв и прочее - всё становится ещё сложнее. И опять без какого-то значительного преимущества одного решения.

И я например с давних лет придерживаюсь политики "компиляторов в проде быть не должно", что исключает п.1 для меня. Сильно больше векторов атаки. Впрочем, п.3 при этом весьма неплох, пока нет деплоя в "мульти-окружения", то есть хост+докер, там я выбираю п.2

И да, можно взять php:8.2-alpine, доставить композер и см выше, но смысл если есть п.3?

Обновляемся до composer 2 на ubuntu

 https://coderteam.ru/blog/obnovlyaemsya-do-composer-2-na-ubuntu/

Немного о говнокодерах в убунте

 Есть обычная LTS убунта, никого не трогает, по apt install php ставится версия 7.4 (в 20.04). Но нам нужен пхп 5.6 ВТОРЫМ. Ок, ставим

sudo apt install software-properties-common

sudo add-apt-repository ppa:ondrej/php

Теперь по apt install php5.6 ставится 5.6, вроде всё хорошо... А нет.

# apt info php | grep Version

Version: 2:8.0+82+ubuntu20.04.1+deb.sury.org+1

# apt-cache policy php

php:

  Installed: 2:7.4+75

  Candidate: 2:8.0+82+ubuntu20.04.1+deb.sury.org+1

То есть теперь, если мы используем штатную версию 7.4, по условному apt install php-curl нам прилетит совершенно бесполезная версия 8.0. Что называется, ПРЕВЕД. При этом reconfigure не помогает

# dpkg-reconfigure php

#

# update-alternatives --config php 

это тоже чуть про другое, выбор версии из уже установленных.

Впрочем, это рукожопство лечится. Идём в /etc/apt/preferences.d/ и пишем файлик (какой? Синтаксис там совершенно мерзейший, типичный говнокод в действии - у того же центос прямо в .repo пишем что исключаем из данной репы и живём спокойно). Так что вариант - ppa поставили, нужное поставили, потом из /etc/apt/sources.list.d убрали/удалили.

ubuntu, php, xhprof

"XHProf был разработан Facebook и заброшен , когда они переехали в HHVM. Теперь есть fork проекта под названием Tideways , который обещает добавить поддержку PHP версий 5.6 и 7."

Хотя если перейти на http://pecl.php.net/package/xhprof то версия 2.2.3 там от конца 2020 года...

Итого: можно ставить так

apt install php-pear

apt install php-dev # phpize

pecl install -f xhprof

Build process completed successfully

Installing '/usr/lib/php/20190902/xhprof.so'

install ok: channel://pecl.php.net/xhprof-2.2.3

configuration option "php_ini" is not set to php.ini location

You should add "extension=xhprof.so" to php.ini

Вносим в /etc/php/7.4/mods-available/xhprof.ini

extension=xhprof.so
xhprof.output_dir="/tmp/xhprof"

и в /etc/php/7.4/cli/conf.d делаем ln -s /etc/php/7.4/mods-available/xhprof.ini 20-xhprof.ini

повторить для апача или fpm

или через tideways (веб версия - платно! Сам xhprof вроде нет, но там формат другой, нужно переписывать код)

https://tideways.com/profiler/xhprof-for-php7

https://github.com/tideways/php-xhprof-extension

https://github.com/tideways/php-xhprof-extension/releases

https://gist.github.com/snoek09/72d0563d350fcc9ea6117790eeb6e60f

GUI

https://github.com/perftools/xhgui

apt install mongodb

#pecl install mongodb

apt install php-mongodb

systemctl enable mongodb

grep bind /etc/mongodb.conf # обязательно проверяем что есть bind_ip и он не выставлен в 0.0.0.0 - это чревато! Должно быть 127.0.0.1

systemctl restart mongodb

echo 'extension=mongodb.so' > /etc/php/7.4/mods-available/mongodb.ini

и повторяем включения

apt install composer

composer install --no-dev

curl 127.0.0.1:8080/install.php

debian: php5 + apache2-mpm-worker

Суть в том, что это не работает.
https://serverfault.com/questions/772298/configuring-apache2-mpm-worker-with-php5

Ubuntu's PHP5 module will only work with the single-threaded mpm_prefork. In order to use the Apache module with the threaded mpm_worker, you will need to compile a threadsafe version of PHP yourself (which requires disabling all of the features and modules of PHP that are not threadsafe, which are a lot of them).

Instead of using libapache2-mod-php5 you should consider using FastCGI/php-fpm. There is a guide to the steps needed to install and configure libapache2-mod-fastcgi and php5-fpm here: https://askubuntu.com/a/527227 Part of configuring FPM is to create "pools" of php processes, each of which have their own limits and INI files, so you will need to be sure that the limits in FPM are reasonable for your site's expected load.

This arrangement will allow you to use the multi-threaded worker MPM in Apache while handing off the PHP requests to individual PHP processes handling a single request each.

Debian и xhprof

xhprof - довольно полезный профилировщик, который можно использовать в проде. Ставится (кусочек) так:
# apt-get install php5-xhprof

Осваиваем php-fpm

Все кому надо уже перешли, но мало ли... Ну и как обычно, хождение по граблям.

debian 8, apache, php: почта ходит только от рута

Довелось настраивать debian 8 + apache 2.4 (ITK) + php, штатный почтовик exim (и сразу - не забываем сказать dpkg-reconfigure exim4-config и выставить режим internet site), а дальше - есть скрипт-мейлер, от рута из консоли mail() возвращает true, а ровно оно же но через сайт отдаёт false. При этом в paniclog появляется строка
 unable to set gid=1000 or uid=0 (euid=0): forcing real = effective

По данной строке уже гуглится проблема и решение:

<IfModule mpm_itk_module>

LimitUIDRange 0 6000

LimitGIDRange 0 6000

</IfModule>

http://forum.ispsystem.ru/archive/index.php/t-28663.html

ну или так

echo "LimitGIDRange 0 2000" >> /etc/apache2/mods-available/mpm_prefork.conf

echo "LimitUIDRange 0 2000" >> /etc/apache2/mods-available/mpm_prefork.conf

service apache2 restart

https://aseev.im/ispmanager-plus-apache-mpm-itk/

(только с гидом не работает, надо uid+gid)

Кто-то набыдлокодил и выпустил это в мир, только непонятно кто именно.

Плюс кому-то также в exim надо вписать 

disable_ipv6 = true

И опционально в /etc/php5/apache/php.ini найти sendmail_path и выставить

sendmail_path = "/usr/sbin/exim4 -ti"

И немного доков

http://mpm-itk.sesse.net/

php 5.2 в конце 2014 года

До сих пор есть сайты, которые работают только под php 5.2, не выше. Почему не поправить их? Например, позиция владельца "я не буду платить, оно же работает!", а своих денег на программиста нет. Особенно если таких сайтов даже больше 10, а если счет идет на сотни и тысячи?
Или когда есть что-то кодированное (cms), тем же zend, и версия cms больше не на поддержке/той фирмы больше нет. Нужно переделывать сайт с нуля.
Надо ставить что требуется, и пусть официально оно уже не поддерживается...
Хотя и разработчики php тоже поступили по свински, серьёзно изменили некоторые вещи, сломав совместимость, но не стали делать 5.2-LTS версию. Лучи поноса в их сторону.

Отдельно хорошо было бы рассмотреть связку этих версий с ispmaanager, но пока нет возможности. В этом плане лучше всего работает система, где php только 1 версии.

Особенности обновления таймзон

Предисловие:
Рецепты для centos, debian, freebsd, небольшой такой сборник.
Не забываем обновить сначала порты/пакеты, у дебиана apt-get update, у freebsd через svnup или portsnap fetch update. Centos сам обновит.

Следующая версия PHP будет называться PHP 7

http://habrahabr.ru/post/231605/
В основу PHP7 ляжет PHPng. Многие из свежих предложений и патчей делаются уже на его базе — в том числе такие интересные вещи, как uniform variable syntax, native big integers и abstract syntax tree. Из-за изменений во внутренних API, многие сторонние расширения (например, xdebug, расширения для mongodb и memcached, php-protocolbuffers) должны быть переработаны, поэтому в PHP 5.7 PHPng войти уже не сможет.


И еще интересное "на почитать":
PHP 6 не будет, не осилили 
Суть в том, что 6 версия должна была содержать в ядре UTF-16, но "не осилили", и почти все плюшки кроме юникода пошли в 5.4

PHP Warning: Unknown: Failed to write session data (memcached). Please verify that the current setting of session.save_path is correct

Есть 2 php модуля: php5-memcache и php5-memcached, но они отличаются по функционалу и использованию. В частности, даже указание, что подключаем, несколько отличается, в случае memcache указывается префикс tcp://, а у memcached - нет.

session.save_handler = memcache
session.save_path="tcp://192.168.1.103:11211"

session.save_handler = memcached
session.save_path="192.168.1.103:11211"

Есть вариант через сокеты
session.save_path="/tmp/memcached.sock"

http://stackoverflow.com/questions/12112319/failed-to-write-session-data-php-and-memcached

и пример просмотра статистики
echo stats | nc -U /tmp/memcached.sock

remi: теперь 5.4

Новости примерно 1.5 года, но нам оказалось актуально. Для центоси 5 штатный пхп 5.2, а нам нужно было именно 5.3, причём старше чем 5.3.3, ибо ранее есть бага с max_input_vars, поэтому надо подключать remi или CentALT. Но и в реми теперь тоже 5.4, поэтому выход только 1 -- качать пакеты из архива, ссылки можно взять тут
http://rpms.famillecollet.com/enterprise/5/

или сразу тут
http://rpms.famillecollet.com/enterprise/5/olds/i386/
(это для i386)

PHP APC Potential Cache Slam Averted for Key

При использовании APC и его обновлении в логах могут появиться строки вида
[apc-warning] Potential cache slam averted for key

http://pecl.php.net/bugs/bug.php?id=16814
может возникать, когда пишется ключ который уже существует. Пока лекарства нет. Отключить можно так: в php.ini
apc.slam_defense = 0

debian: php 5.3 в версии от DotDeb

В debian 7 есть возможность поставить 5.3 из backports

http://dragonflybsd.blogspot.ru/2013/09/debian-7-downgrade-php-to-53.html

Но в этой версии есть достаточно неприятный баг для недоцмс типа битрикса, заключающийся в том что max_input_vars не меняется в конфигах и всегда равен 1000. В этом случае имеет смысл перейти на более свежую сборку, например от dotdeb

http:/reborns.info/установка-php-5-3-на-debian-7-wheezy/

php+debian: проблемы с max_input_vars

Очередная бага дебиляна:
http://stackoverflow.com/questions/19042734/is-there-a-limit-like-max-input-vars-in-versions-before-5-3-9
есть условный сервер с проектом на битриксе, к которому не покупалось поддержки и он не работает на 5.4, поэтому нужна версия именно 5.3. А в дебиляне это
PHP 5.3.3-7+squeeze17 with Suhosin-Patch (cli) (built: Aug 23 2013 15:06:16)
Все норм дистры позволяют обновиться до более поздних версий (5.4 не подходит), а тут - штатно без вариантов.

Суть бага: установка max_input_vars в  версиях ниже 5.3.9 не имеет значения, ограничение в 1000 прописано в коде, хотя даже по phpinfo всё выставлено верно.

Самый простой вариант - на dotdeb есть 5.3.9+ (5.3.25, 5.3.27...)
Установка php 5.3 на Debian 7 Wheezy
Не забываем ограничить "наглость" репы, иначе половину пакетов заменит, в том числе то что не нужно.

Вот 5.4 ставить лучше оф, если нет особой нужды именно в последних версиях - штатная конечно будет устаревшей, но относительно проверенной "миллионами хомячков".

Debian 7: downgrade php to 5.3

В дебиане штатный пых версии 5.4, но иногда требуется 5.3, как в 6 версии. Нужная нам плюшка называется oldstable, ставится так: в /etc/apt/sources.list дописываем
deb http://ftp.debian.org/debian/ squeeze main contrib non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free

apt-get update

Теперь 2 варианта: выставляем приоритеты пакетам
в /etc/apt/preferences.d/preferences (надо файл создать)
Package: php5*
Pin: release a=oldstable
Pin-Priority: 700

Package: libapache2-mod-php5
Pin: release a=oldstable
Pin-Priority: 700

Package: php-pear
Pin: release a=oldstable
Pin-Priority: 700

Package: php-apc
Pin: release a=oldstable
Pin-Priority: 700

Package: *
Pin: release a=stable
Pin-Priority: 600

ну и обновляем то, что уже стоит
PHP=$(dpkg -l|grep php|grep 5.4.4|awk '{print $2}')
apt-get install --reinstall $PHP

или просто ставим нужные версии руками через
apt-get install php5=5.3.3-7+squeeze14
версию вынесем в переменную
VERSION="5.3.3-7+squeeze14"
и чтобы не было конфликтов, ставим базу отдельно
1) apt-get install php5=$VERSION
2) apt-get install php5-common=$VERSION
3) apt-get install php5-cli=$VERSION
после этого доставляем нужные модули, зависимости уже подтянет само. Но это уже изврат, имхо. Да, и не забываем зафиксировать версии, чтобы не обновило на 5.4 (для 1 варианта неактуально!)
aptitude hold php5 php5-cli php5-common

линки
http://blog.wpkg.org/2013/06/20/downgrading-to-php-5-3-on-debian-wheezy-7-0/
http://rusadmin.biz/ustanovka-php-5-3-na-debian-7.html
http://forums.debian.net/viewtopic.php?f=17&t=104075

.htaccess и php_value mbstring.func_overload

Боян конечно, но мы только недавно столкнулись: в htaccess больше нельзя прописать php_value типа mbstring.func_overload (http://bugs.php.net/bug.php?id=47187&edit=1)

Достаточно простое решение без всяких fastcgi:

<IfModule mod_php5.c>
    php_value default_charset UTF-8
    php_admin_value mbstring.func_overload 2
    php_value mbstring.internal_encoding UTF-8
    php_admin_value realpath_cache_size "4096k"
</IfModule>