После переноса Битрикс24 из облака в коробку перебирали с клиентом разные SMTP для отправки почты. Среди кандидатов первым был Google: настроил Postfix, две недели почта летала "на ура". Позже обнаружилось, что закончился триальный период и GSuite уже полгода как платный в России. У клиента была действующая подписка office365, туда и решили переезжать.
Несколько часов c гуглом и ошибкой "550 5.7.60 SMTP; Client does not have permissions to send as this sender" не дали результатов. Симтоматика следующая: из shell почта ходит, из Битрикса - нет.
Причиной оказались почтовые шаблоны в которых был прописан адрес @bitrix24.ru из облака. Он соотвественно попадал в "mail from: " и сервер smtp.office365.com его справедливо резал. Странный факт, что в google такая почта ходит.
В настройке сервера для одного из достаточно нагруженных проектов пришлось применить кеширование фильтра на ajax средствами NGINX и директивы proxy_store. Фильтр вкупе с каталогом на полторы сотни тысяч предложений в тесте практически «укладывал» два отдельных физических сервера с репликами БД не доходя даже до средней расчетной нагрузки на проект.
Для веб-сервера была выбрана достаточно типичная для таких ситуаций архитектура: NGINX во фронте для статики и нашего кеша, для скриптов Apache+PHP. Всё как бы заработало: кеш создавался, только NGINX из хранилища кеша в браузер отдавал какой-то бред из непонятных символов. Налицо проблема с кодировкой.
Тут наступил OK’Google и эксперименты с кодировками в конфигах, на которые в общей сложности ушло безрезультатные несколько часов. Вскоре пришло просветление, что кеш от backend-сервера пишется в ФС в бинарном виде, в таком же и отдается NGINX’ом клиенту, итог — кракозябры в окне браузера.
Что же заставляет его записываться в бинарном виде? Ведь ответ Apache2 в большинстве случаев всегда, а в нашем случае всегда, должен иметь mime-type «text/html». Ответ на эту неочевидную проблему достаточно тривиален: он приходит в сжатом виде! За сжатие в Apache2 отвечает дефолтный модуль mod_deflate, с его отключением мы получили ответ backend-сервера в текстовом виде и немного снизили нагрузку (необходимости сжатия между Apache2 и NGINX нет).
Надеюсь кому-нибудь сбережет 2-3 часа, желаю меньше «граблей» в ваших серваках.
Каждый, кто когда-нибудь настраивал web-окружение для продуктов 1С-Битрикс знает о наличии в инструментарии CMS штатного инструмента проверки системы (/bitrix/admin/site_checker.php). Я обычно использую его как экспресс-тестер, т. е. тест на забывчивость. Есть еще, конечно, файлик bitrix_server_test.php, но он содержит несколько меньше тестов.
В это раз все пункты горели зеленым кроме одного: «Размер стека и pcre.recursion_limit». И тут «лыжи остановились». Прописать ulimit -s unlimit в initd-скрипт php5-fpm (в текущей конфигурацииphp подключен через FastCGI) оказалось недостаточно.
Прим.: По моему мнению, модификация init.d скриптов не самое благодарное дело, потому как обновление пакета может перетереть изменения незаметно для администратора сервера со всеми вытекающими.
Пришлось «доставать бубен» и несколько часов гуглить, читать рассылки и доки по ядру (теперь не жалко времени — узнал много нового). На следующий день у меня пришло прозрение: в Debian8 инициализирующим демоном стал systemd вместо устаревшего initd, а поддержка интерпретации управляющих команд initd типа service php5-fpm restart просто сыграло с моим сознанием злую шутку.
Итак, для всех любителей нового ПО (пути для Debian8).
Чтобы systemd принял изменения надо перечитать конфиги:
$ systemctl daemon-reload
Перезапускаем демон php5-fpm:
$ systemctl restart php5-fpm
Поздравляю, в тесте Битрикс «Размер стека и pcre.recursion_limit» загорелся зеленый фонарь!
Прим.: по фэншуй php5-fpm.service.d/limit.conf можно было разместить в /etc/systemd/system.
Хотел так же сказать о том, на что ушло 2 часа «ударов в бубен»: systemd не учитывает общесистемные лимиты определенные в /etc/security/limits.conf. Так что, что бы вы туда не написали, демон systemd будет запускать службы со своими лимитами. Тем-более по дефолту в Debian для интерактивных и не интерактивных сессий демонов pam_limits не подгружаются в /etc/pam.d.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».