Основные моменты, на которые мы обратили внимание, это команда Cron задания. Выполнение обязательно от пользователя bitrix, так как по умолчанию мы работаем под root пользователем.
Дальше, убедившись, согласно логам Cron, что задание исполняется, проверили настройки почтовой системы. Пункты 6, 4 в меню окружения были проделаны изначально, проверили конфигурацию .msmtprc Отправляем почту из админ панели, на произвольный адрес функцией mail(); и почта исправно доходит. Итак, задание выполняется, почта работает.
Проверили почтовые события и соответствующие им шаблоны, чтобы адреса почты были корректны и почтовые шаблоны активны.
Остается удостовериться в работоспособности агентов.
Запускаем Cron задание в консоли сервера.
Вот тут и были получены ошибки, которые как оказалось, возникают благодаря поврежденным модулям, установленным ранее, на которые перестали обращать внимание, типа обновление курса валют, Яндекс.Маркет и т.д.
Отключили эти агенты и отправка системных сообщений, уведомление о новых заказах, изменение статуса заказа, и т.д стало отправляться.
У меня настроены почтовые события "Новый заказ" "Новый быстрый заказ"
Для которых в настройке "Почтовых событий" в закладке "Шаблоны" указаны привязанные шаблоны. Данные шаблоны имеют статус Active, привязку к сайту S1 и заполнены поля адресом отправителя и адресом получателя.
Это достаточные условия для получения системой сигнала об отправке почтового события, оформленного почтовым шаблоном. Таким образом, устанавливая работоспособность почтовой системы, а это проверенный факт, в логах сразу пишется, когда идет "Проверка системы", отправка проверочного письма на bitrixsoft
И в окне выполнения скриптов PHP функция mail(); успешно отправляет сообщение, которое успешно доставляется.
Значит, почтовая система работает, события и агенты проверяются по Cron заданию, активные почтовые события выполняются и почтовые шаблоны обязаны формировать письмо для отправки с полями "От кого" и "Кому" ибо таковые заполнены.
Используем BitrixENV. Согласно меню по пунктам 6, 4, настроено использование SMTP Яндекса. Проверка системы в панели управления успешно отправляет сообщения, сообщения больше 64 Кб, и рапортует об исправном выполнении агентов.
Просьба к знающим специалистам, подскажите где возможно еще подправить настройки, чтобы в почтовые шаблоны правильно подгружались адреса "От кого" и "Кому"
Системные сообщения возвращают ошибку:
Код
Jun 26 12:28:02 host=smtp.yandex.ru tls=on auth=on user=ru*****or@yandex.ru from=bitrix recipients=bitrix smtpstatus=501 smtpmsg='501 5.1.7 Bad address mail
box syntax. 1656235682-I1gnRbXKRM-S2MSZHlR' errormsg='envelope from address bitrix not accepted by the server' exitcode=EX_DATAERR
Обращался в поддержку почты Яндекса, они сказали, что почта не уходит, потому что "От кого" и "Кому" некорректно указано from=bitrix recipients=bitrix
Почтовое событие "Новый заказ" Почтовый шаблон "Новый заказ" Указываю адрес отправки #DEFAULT_EMAIL_FROM# Адрес получателя #SALE_EMAIL# Адрес отправителя в настройках главного модуля совпадает с адресом аккаунта в настройках почтовой системы. Использую SMTP сервер Яндекса.
В логах cron исправно выполняется ежеминутно задание, как описано в статье "Запуск агентов из cron -> Обобщенное решение"
Лог /home/bitrix/msmtp_default.log
Код
Jun 26 14:56:02 host=smtp.yandex.ru tls=on auth=on user=ru***or@yandex.ru from=bitrix recipients=bitrix smtpstatus=501 smtpmsg='501 5.1.7 Bad address mail
box syntax. 1656244562-lytLGQ6wdt-u2MCoEB4' errormsg='envelope from address bitrix not accepted by the server' exitcode=EX_DATAERR
Откуда он берет данные для отправки "От кого" - bitrix? И отправки "Кому" - bitrix
Конфиг прописан в .settings_extra.php и эта конфигурация успешно работала на том сайте, который я восстанавливаю.
Цитата
Уверены что прописали все конфигурации, у вас нет конфликта по правам подключения (например memcached настроен на сокет, а вы по порту пытаетесь подключиться).
В файле конфигурации memcached указаны настройки для подключения по порту 11211 localhost Telnet подключается по 127,0,0,1 11211 успешно
В документации два варианта кода, один для использования с портом, другой для использования с сокетом. Автор статьи Роберт Басыров рекомендует запускать в режиме сокетов, так будет быстрее, но хочется сначала увидеть, что заработало, потом тюнинг наводить. А раньше работало.
Проблема: Отказывается запускаться тип кеширования memcache Файловое кеширование отлично запускается. Настройки по умолчанию в .settings.php срабатывают Настройки memcache в файле .settings_extra.php
Сайт работал на окружении BitrixENV По инструкции веб окружения настроен сервер memcached и сайт прекрасно работал.
Сейчас восстановлен из резервной копии на новом сервере Ubuntu 20.04 Версия PHP 7.3.13 + Memcached в настройках PHP успешно показывает. Telnet в консоли успешно связываетс с сервером memcached
Но картина в "Панели производительности" одно и то же, все бубны перепробовал. cacheenginenone
При этом стоит отключить файл .settings_extra.php тут же включается файловое кеширование.
Зависает restore.php Восстановление из резеврной копии на новом сервере., Восстановление сайта из резервной копии на другом сервере скриптом restore.php замедляется и больше 25% не идет
Кстати, мож кто мне подскажет, как ловить блох с memcache А то Env избаловался где при помощи цифрового меню кеширование Memcached подключается автоматически.
Здесь в информации о настройках PHP Memcached подключен, есть информация о версии и константах.
Однако-же в производительности кеширование отсутствует.
Зависает restore.php Восстановление из резеврной копии на новом сервере., Восстановление сайта из резервной копии на другом сервере скриптом restore.php замедляется и больше 25% не идет
Мне достаточно было задать innodb_buffer_pool_size согласно рекомендациям mysqltuner.pl
И база весом 3 Гб успешно восстановилось минут за 10.
Преимущества использования панели управления перед BitrixEnv
Автоматическое обновление сертификата , на Окружении приходилось бесплатный сертификат Lets Encrypt обновлять Автоматическое подключение HTTPS средствами сервера. Поставил галочку "Принудительно HTTPS" и все! Без всяких бубнов с танцами вокнуг Env Автоматическое подключение Переадресация WWW на без WWW. Просто галочку поставил и все.
Возможность легкого управления дополнительными сайтами, на одном сервере можно поставить еще несколько сайтов.
Легко менять версию PHP, хочешь 7.1 Хочешь 7.3 за три секунды, через Веб-интерфейс панели управления
Ну и самое главное, все это делается на Debian ветке
4 Ядра и SATA диск гоняет Bitrix интернет-магазин как по маслу.
Сейчас, когда сравнил тест производительности, на прежнем сервере 4 Ядра, 8 RAM SSD BitrixENV Результат 35 Кеширование memcache
Здесь, 4 Ядра 16 RAM Диск SATA Ubuntu Результат 53 Кеширование файловое.
Сейчас разбираюсь почему кеширование memcache крутит мне пальцем у виска. ?
Зависает restore.php Восстановление из резеврной копии на новом сервере., Восстановление сайта из резервной копии на другом сервере скриптом restore.php замедляется и больше 25% не идет
Рискнул поднять Ubuntu 20.04 с целью запуска сайта на Битрикс Воспротивился решению BitixENV и обрел много вопросов.
Суть в том, что запуск скрипта restore.php успешен! Бодренько импортирует архив резервной копии по ссылке, отлично! Распаковывает аж винтики скрипят на сервере, Взлет!
Но потом начинается самое невообразимое.
Переход к следующему шагу: "Восстановление базы данных из резервной копии"
Начинается восстановление так же бодренько, резервы сервера, вычислительные мощности задействуются почти на 90% по мониторингу в консоли в программе Htop Все замечательно.
Позже, к 18% весь бодрячок спадает, все потихоньку вянет, и начинается "Закат Солнца вручную"
Как вы думаете, что подкрутить и где смазать? Ждешь, ждешь, доходит до 25% и очень медленно все происходит. Процессор на 2 - 3% задействуется.
И заканчивается все Bad Gateway 504
Все настройки сервера согласно скрипту проверки сервера
bitrix_server_test.php
Установлены в зеленый.
Пришлось выполнить невыполнимое, даже STRICT_TRANSPORT_SECURITY отключить в режиме MySQL
Но мы это сделали.
Хотели видеть удовлетворительный результат, восстановление сайта из резервной копии.
Но видимо только 504 Bad Gateway каждый 1,5 часа после запуска restore.php
Спасибо заранее!
Мир Всем, Счастья и Весеннего Настроения.
С Праздником Светлой Пасхи Христова Воскресения! Христос Воскресе! С Уважением,
Ваш сайт работает на BitrixVM/BitrixENV по теме ветки вероятно. Тогда: Разработчиками окружения предусмотрено решение соответствующее утверждению: "Если подключен сертификат, то сайт должен работать только по HTTPS"
Нужно ОТКЛЮЧИТЬ_ПРОТОКОЛ_HTTP - И все Здесь это трактуется так: Зайти в окружение (на сервер и запустить menu.sh - автозапуск при входе)
"6. Configure pool sites -> 5. Change a site's https settings"
Система спросит: "Отключить доступ по HTTP?" Подтверждаете, и спокойно все работает
Сайт отзывается по HTTPS, переадресация автоматически site.ru -> https://site.ru
Так же легко отключается головная боль www.site.ru -> https://site.ru (Переадресация с www на домен без www) в панели управления Админке.
Здравствуйте, уважаемые коллеги и братья по разуму
Вот у меня какой вопрос, подскажите пожалуйста. Назначили ответственным по настройке сайта на BitrixVM В процессе оптимизации СЕО сайта обнаружилось, что по большому количеству поддоменов отдается один и тот же контент. Оказалось, поддомены были созданы и направлены в корень. Для чего это было сделано, по разумению или по оплошности, остается только гадать. Проблема эти поддомены удалить. Удаление через окружение сразу удаляет основную базу. Тупик.
Следующий шаг. Удаление записей в конфигурационных файлах, так бы подумал каждый. Идем по инструкции. Если поддомены создавались при помощи окружения, то создается дополнительный каталог EXT... Дополнительные каталоги в папке с ядром системы отсутствуют.
Далее, конфигурационные файлы. Должен быть создан файл в директории etc/nginx/bx/site_ext_enabled Файл конфигурации по этому пути отсутствует.
В стандартных файлах конфигурации NGINX прописаны include /etc/nginx/bx/
Итого удалить через окружение поддомены тупик. Стандартная последовательность действий удаляет вместе с поддоменом основную базу.
Нужно искать выход отредактировать конфигурационные файлы.
Уважаемые коллеги, подскажите пожалуйста, где можно управлять настройками, позволяющими спокойно отдавать содержимое основного сайта при обращении к серверу по имени поддоменов.