В новой записи я расскажу как я решил проблему с сохранением параметров сессии на Bitrix. Сайт располагался на VPS под Ubuntu (хостинг beget).
Авторизуемся на сервере и узнаём версию PHP через команду в консоли
Вам нужно авторизоваться под пользователем root. После авторизации в консоли пишем команду
php -v

Находим пути до файла с конфигурацией PHP на сервере (php.ini)
С помощью следующей команды, вы получите пути до файла php.ini. Данная команда выводит пути до всех файлов, вам нужны только файлы вашей версии PHP.
find / -name "php.ini"

Создаём директорию для файлов сессий
Для файлов сессии я создал директории по следующему пути /home/user/tmp/sessions
Проверьте чтобы все директории по указанному пути были созданы!
user может быть заменён на имя вашего пользователя.
Изменяем конфигурацию в файле php.ini для сайта Bitrix
Прописываем в значение параметра для session.save_path=/home/user/tmp/sessions
И строкой нижу пропишем — extension=session.so
Добрый день.
Сайт на битриксе, дебиан, nginx+phpfpm, bitrix vm не используется. Домен сейчас делигирован на яндекс, производим делегирование домена в другое место. И появилась проблема По старому адресу сессии работают нормально, при переключении на новый адрес сессии не сохраняются.
При попытке изменить тот же заказ получаю такую ошибку:
Ошибка обработки запроса. Наиболее вероятные причины: у пользователя недостаточно прав; проблемы с сохранением сессий PHP; часть данных POST-запроса обрезается PHP либо веб-сервером.
Что с этим делать не понятно. Специалистов по серверам у нас нет.
Техподдержка куда переводим делегирование на это дала такой ответ:
Вероятно при генерации куки всё же используется IP-адрес пользователя.
Ранее IP-адрес пользователя и IP-адрес устанавливающий соединение совпадали и IP-адрес пользователя вероятно брался из переменной remote_addr.
Сейчас IP-адрес пользователя и IP-адрес, с которого приходит запрос, не совпадают из-за того что запросы проходят через наши проксирующие сервера. IP-адрес может меняться и это вероятно вызывает затруднения с сессиями.
С вашей стороны необходимо или изменить передачу IP-адреса пользователя в битрикс (мы передаем IP-адрес пользователя в заголовке X-Real-IP) или не учитывать его в куки.
Но с технической стороны, что делать куда смотреть не понятно.
Если кто-то может подсказать помогите пожалуйста. Спасибо.
Столкнулся с проблемой: в битрикс не работают сессии. Функция bitrix_sessid() каждый раз выдает новую строку. В админке авторизация работает, но никакой ajax функционал — нет. Везде ошибка что сессия не верная, при этом проблема плавающая. То ошибка есть, то само по себе начинает работать.
Проблема оказалась просто в том, что на сервере закончилось свободное место на диске.
Чтобы долго не сидеть и не гадать в чем у вас проблема, выкладываю скрипт. Сохраните его в корень сайта, например с именем test.php и запустите из браузера:
<?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
if (! session_start()) {
die('can not start session');
} else {
echo '<pre>session start: ok' . PHP_EOL;
}
echo 'session_id(): ';
var_dump(session_id());
echo '$_COOKIE["PHPSESSID"]: ';
var_dump($_COOKIE['PHPSESSID']);
echo 'count($_SESSION): ';
var_dump(count($_SESSION));
echo '$_SESSION["a"]: ';
var_dump($_SESSION["a"]);
echo '$_SESSION["a"] = 1';
$_SESSION["a"] = 1;
Сессия должна стартовать, в session_id() должна быть какая-то строка, та же что и в $_COOKIE[‘PHPSESSID’]. При перезагрузке страницы id сессии не должно меняться.
После второй перезагрузки страницы $_SESSION[«a»] должно быть установлено в 1.
Вывод ошибок включен, если что — PHP напишет что не так. Я получил ошибку No space left on device (28), что говорит о том, что не хватает места на сервере.
Пожалуйста, оцените на сколько вам понравилась статья!
Итак, имеем чистую установленную CentOS 6
Обновляем систему, подключаем репозиторий EPEL, ставим минимально необходимый набор ПО:
# yum update # yum install epel-release # yum install mc bash-completion wget
Создаем пользователя с полными правами:
# useradd -m myadmin # passwd myadmin # vi /etc/sudoers
и добавляем строку чтобы получилось
root ALL=(ALL) ALL myadmin ALL=(ALL) ALL
Для CentOS 6 есть удобная штука Bitrix Enviroment — скрипт, который разворачивает весь набор ПО для Битрикса.
# cd /root # mkdir bitrix # cd bitrix # wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh # chmod +x bitrix-env.sh # ./bitrix-env.sh
После запуска необходимо подождать какое-то время пока все требуемое не будет загружено и установлено.
У Bitrix Enviroment есть одно неудобство: все настроено для работы с 1 сайтом, а если на сервере необходимо развернуть несколько инсталляций Битрикса и иных CMS — необходимо поработать руками.
Необходимо для работы каждого виртуального хоста под своими учетными данными
Ставим:
# yum install mod_ruid2
Необходимо подключить данный модуль, например скопировав его:
# cp /etc/httpd/conf.d/mod_ruid2.conf /etc/httpd/bx/conf/
В настройках виртуального хоста добавить строчку:
<VirtualHost 127.0.0.1:8888> ... RUidGid myuser mygroup ...
В файле mod_ruid2.conf можно найти полное описание директив и настроек.
Перезапускаем httpd, проверяем все ли работает — для этого создаем файл ruid2.php и открываем его в браузере
<?php print `id`; ?>
Должна открыться страничка с примерно такимответом:
uid=1002(myuser) gid=1000(mygroup) groups=1000(mygroup),33(bitrix)
Необходимо для работы каждого виртуального хоста под своими учетными данными
Предупреждение
Apache mpm-itk значительно медленнее prefork и event, поэтому на высокую оценку Битрикса рассчитывать не стоит (в меню Настройки → Производительность → Панель производительности плохие показатели будут в подсистемах «Среднее время отклика», «Файловая система» и как следствие «Конфигурация»). Лучше использовать вышеописанный mod_ruid2
# yum install httpd-itk.x86_64
Запускаем Apache в режиме mpm-itk: добавляем в /etc/sysconfig/httpd строку
HTTPD=/usr/sbin/httpd.itk
Правим настройки PHP: добавляем в файлы /etc/httpd/bx/conf/php.conf и /etc/httpd/conf.d/php.conf строки
<IfModule itk.c> LoadModule php5_module modules/libphp5.so </IfModule>
Добавляем в файл /etc/httpd/conf/httpd.conf строки (кол-во запускаемых серверов и обслуживаемых клиентов зависит от конкретного сервера, необходимо подбирать самостоятельно):
<IfModule itk.c> StartServers 1 MinSpareServers 1 MaxSpareServers 20 ServerLimit 50 MaxClients 100 MaxRequestsPerChild 4000 </IfModule>
В файле /etc/httpd/conf/httpd.conf заменяем строку
ServerTokens OS
на
ServerTokens Prod
Необходимо удостовериться что у пользователя под которым работает nginx есть права на чтение папок www
В файле /etc/nginx/nginx.conf настраиваем:
Корректируем число процессов под свою систему:
worker_processes 2;
Скрываем версию:
server_tokens off;
Fatal error: Call to undefined function mysqli_init() in /home/MYSITE/www/bitrix/modules/main/lib/db/mysqliconnection.php on line 48
Необходимо включить расширение PHP для работы с MySQL — оно называется mysqli. Опять же — если его включить ДО восстановления сайта из резервной копии то на третьем шагу восстановления (а именно базы данных) — получим симпатишный белый экран.
# cd /etc/php.d # mv 30-mysql.ini 30-mysql.ini.disabled # cp 30-mysqli.ini.disabled 30-mysqli.ini # service httpd restart
Альтернативный вариант заключается в отключении использования mysqli Битриксом: в файле bitrix/php_interface/dbconn.php исправляем строку
define("BX_USE_MYSQLI", true);
на
define("BX_USE_MYSQLI", false);
И в файле bitrix/.settings.php поменять
'className' => '\Bitrix\Main\DB\MysqliConnection'
на
'className' => '\Bitrix\Main\DB\MysqlConnection'
чтобы получилось
.... 'connections' => array ( 'value' => array ( 'default' => array ( 'className' => '\Bitrix\Main\DB\MysqlConnection', ....
Добавляем в /etc/hosts запись
127.0.0.1 mydomain.ru
В файле /etc/php.d/bitrixenv.ini меняем
pcre.recursion_limit = 14000
на
pcre.recursion_limit = 100000
В скрипте запуска сервера HTTP Apache /etc/rc.d/init.d/httpd изменить функцию «start()», добавив в нее одну строку (ulimit -s unlimited):
start() {
echo -n $"Starting $prog: "
ulimit -s unlimited
LANG=$HTTPD_LANG daemon --pidfile=${pidfile} $httpd $OPTIONS
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch ${lockfile}
return $RETVAL
}
и перезапускаем httpd
# service httpd restart
Решение для CentOS 7
Отсюда: http://host-consult.ru/pcre-recursion_limit-bitrix-centos7/
Создаем папку для дополнительного конфигурационного файла сервиса httpd:
# mkdir /etc/systemd/system/httpd.service.d
Внутри создаем файл, например recursion_limit.conf и в него пишем:
[Service] LimitSTACK=infinity
Перегружаем демона и сервис:
# systemctl daemon-reload # systemctl restart httpd
Существенное замечание
Снять ограничение на лимит стека, это рекомендация Битрикс. Скажем прямо не самая удачная, т.к. вы можете решив одну проблему заполучить проблему с постоянной нехваткой ОЗУ. И apache будет падать уже по этой причине. Поэтому лучше подобрать верхнее граничное решение, которое будет устраивать Битрикс. Вычислить его достаточно просто:
Обычно кэш равен 8 Мбайт, убедимся:
# ulimit -s 8192
Соответственно, нам нужно немного больше, пусть это будет 9 Мбайт: 1024*1024*9 = 9 437 184 байт
пишем в наш файл:
[Service] LimitSTACK=9437184
В файле /etc/php.d/bitrixenv.ini меняем
sendmail_path = msmtp -t -i
на
sendmail_path = sendmail -t -i
В файле /etc/php.d/bitrixenv.ini меняем
date.timezone = Europe/Moscow
на свою, например
date.timezone = Asia/Krasnoyarsk
Есть две причины для данной ошибки:
Хост не может разыменовать свое доменное имя
Добавляем в файл /etc/hosts строку
127.0.0.1 mydomain.ru
Веб-сервер не может сохранить файлы сессии
Путь в файловой системе куда сохраняются сессии прописан в файле /etc/php.d/bitrixenv.ini и по умолчанию там прописано следующее значение:
session.save_path = "/tmp/php_sessions/www"
Таким образом нужно удостовериться что данная папка существует, внутри нее так же есть еще две папки: www и www_ext и права установлены следующим образом:
# cd /tmp # ls -l drwxrwx--- 4 bitrix bitrix 4096 Sep 14 13:44 php_sessions # cd php_sessions # ls -l drwxrwx--- 2 bitrix bitrix 4096 Sep 14 13:44 ext_www drwxrwx--- 2 bitrix bitrix 4096 Sep 14 13:45 www
firewall-cmd --zone=public --add-port=25/tcp --permanent firewall-cmd --zone=public --add-port=80/tcp --permanent firewall-cmd --zone=public --add-port=443/tcp --permanent firewall-cmd --zone=public --add-port=5222/tcp --permanent firewall-cmd --zone=public --add-port=5223/tcp --permanent firewall-cmd --zone=public --add-port=8890/tcp --permanent firewall-cmd --zone=public --add-port=8891/tcp --permanent firewall-cmd --zone=public --add-port=8893/tcp --permanent firewall-cmd --zone=public --add-port=8894/tcp --permanent firewall-cmd --reload
Разработчики системы битрикс рекомендуют своим клиентам проверять конфигурацию сервера специальным скриптом bitrix_server_test.php. На этом этапе довольно часто возникают проблемы с конфигурацией сервера и скрипт помогает определить готовность конфигурации веб-сервера для развертывания проекта на битриксе. Некоторые сообщения в скрипте не совсем информативны, в том плане что найти по ним причину ошибки не просто.

Одним из таких сообщений является «Сохранение сессий без UserAgent». Вроде бы понятно, но в то же время не ясно куда смотреть. В конце концов, немного поискав на форумах, и не найдя ничего конкретного решил залезть в сам скрипт. Отыскав строку (примерно на линии 622), где происходит эта ключевая ошибка, нашел такую запись, которая собственно и подсказала точную причину ошибки.
$res = fsockopen(($port == 443 ? 'ssl://' : '').$host, $port, $errno, $errstr, 3);
Проблема была в том, что у функции fsockopen не удавалось подключиться к хосту, а само сообщение об ошибке помещалось в переменную $errstr. В переменной $errstr было следующее:
php_network_getaddresses: getaddrinfo failed: Name or service not known
Иными словами, не удалось получить имя хоста. Проблему удалось решить довольно просто, т.к. сервер поднимался на виртуальной машине под CentOS, то в конфигурационном файле /etc/host было достаточно прописать доменное имя сайта.
Открываем файл /etc/hosts:
vi /etc/hosts
Добавляем строку:
127.0.0.1 mydomen.loc
где mydomen.loc – доменное имя вашего сайта.
Описаны некоторые проблемы и способы их решения.
- Бизнес-чат в реальном времени – Функция работает частично неправильно, желательно устранить ошибки.
Для её решения достаточно посмотреть журнал проверки, в котором всё подробно описано. Настройки продукта-Настройки модуля-выбрать Главный модуль, раздел авторизация, убрать галки Продлевать сессию при активности посетителя в окне браузера и Продлевать сессию только для авторизованных посетителей. - Сохранение сессии без UserAgent.
Веб-сервер не может сохранить файлы сессии. Путь в файловой системе, куда сохраняются сессии, прописан в файле /etc/php.d/bitrixenv.ini и по умолчанию там указано следующее значение: session.save_path = “/tmp/php_sessions/www”. Таким образом, нужно удостовериться, что данная папка существует. Самым оптимальным способом будет вызвать функцию phpinfo() и проверить значение “session.save_path”, т.к. его могут перезаписать значения в .htaccess или что-то ещё. Владельцем директории под сессии с правами 0755 должен быть пользователь bitrix (или тот, от которого работает веб-сервер). - Интеграция с соцсетями, замечание:
В модуле социальные сервисы поставить галочку напротив Битрикс24.