Денис Шаромов (Все сообщения пользователя)

Спасибо за сигнал. Всё поправили!
Начните процесс заново, скрипт обновит сам себя исправленной версией.

Если установлено значение innodb_strict_mode=ON, MySQL делает дополнительные проверки запросов, что в ряде случаев приводит к проблемам. Мы сталкивались с ситуациями, когда работающий проект переносится с одной установки на другую и перестаёт работать из-за этого.

Например, ошибка блокирует выполнение запроса и парализует работу:
При этом она не связана со архитектурными ограничениями MySQL, это вопрос "синтетического усиления" правильности. Вопросы формирования SQL должны решаться на уровне приложения, а не базы. Здесь это приводит к проблемам.

Ежедневно десятки тысяч сайтов на битриксе успешно обновляются, этот процесс хорошо налажен, работает не один год. Очевидно, что-то не так именно с вашей установкой. Я нашел ваше обращение №2450169. Мы выясним детали и разберемся. Не переживайте.

Антон, приветствую.

Вижу, что там начали работать по вопросу, но на первом уровне не смогли его решить. Сейчас вопрос в очереди у старшего инженера, постараемся в ближайшее время разобраться с ним.

Андрей, спасибо. Если что-то еще будет всплывать, пишите, пожалуйста.

Кейсистемс, буду признателен, если скинете несколько примеров, чтобы понимать, где что подправить. Вот эти редкие случаи плохих решений могут сильно портить общее впечатление.

Андрей, а вы сообщали в техподдержку о проблемах после переноса? Если что-то появляется, мы стараемся оперативно решать проблемы.

С загрузкой локального файла действительно была ошибка, спасибо, поправим!

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

Сейчас поддержки MSSQL и Oracle нет. Нет совсем.

Это значит, что классы для работы с этими БД не поставляются пользователям. Но даже если бы каким-то невероятным образом удалось транслировать все запросы, которые идут к MySQL, на одну из этих баз, работать не будет из-за различий в SQL.

Нельзя делать публичные сайты на лицензии Битрикс24, Mikhail Kryachek в этой теме дал ссылки на лицензионное соглашение.

Когда пишете технический вопрос в техподдержку, технический специалист даёт вам ответ. Я посмотрел ваши тикеты, вы везде спрашиваете по-разному и немного о разном. С технической точки зрения возможно сделать то, что вы спрашиваете, но когда речь идёт о лицензировании, в обращении 1686979 менеджер отдела продаж ответила четко:

Добрый день.


Поддержка никуда не делась, работаем на пределе, стараемся всем отвечать вовремя. Просто сейчас лето, период отпусков и горячая пора у нас. Если вопрос требует консультации у разработчика, это занимает больше времени.

Пожалуйста, извините за задержки. В ближайшее время ответим по сути или постараемся сориентировать по срокам решения.

Лучше в таких случаях публиковать ответ, чтобы другие тоже могли им воспользоваться

Передаю ответ наших разработчиков. Чтобы избавиться от ошибки "ngx_slab_alloc() failed: no memory", необходимо увеличить память для модуля push&pull в /etc/nginx/bx/conf/im_settings.conf.

Параметр push_stream_shared_memory_size, значение по умолчанию 256М. Увеличивайте этот параметр постепенно до тех пор, пока не уйдет ошибка: nginx сразу резервирует эту память.

Обратите внимание, что доступная память не может быть больше, чем допустимый размер shared памяти, установленная в системе (опция kernel.shmmax в /etc/sysctl.conf)

Извините, пропустил важный вопрос.
Из клиентских тикетов.

Если говорить про вирус, делается ботами массово, ftp - это самый простой путь, подбирать пароли и организовывать модификацию файлов через панель битрикса гораздо более трудоёмко и менее эффективно. Базовая защита в виде капчи при неправильном вводе блокирует перебор паролей.

Когда речь о взломе, это совсем другая ситуация. Тут уже ручная работа, это обычно или соседние сайты на разделяемом хостинге, или свой софт в виде дополнительного визуального редактора, phpMyAdmin и пр.

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

Взлом - это троянская программа или другие следы хакерской атаки, здесь наша задача исключить вариант взлома через наш продукт, поэтому берем информацию чтобы выяснить, как бэкдор попал на сайт, потом ищем причину. Если в логах веб-сервера нет следов, значит взлом был через ftp или банальную утечку пароля. Например, были ситуации, когда пользователь просто авторизуется под админом, загружает бэкдор и уходит. Через месяц(ы) появляются странные вещи на сайте.

Судя по имени, этот бэкап сделан не нашей системой, а, вероятно, хостером. Значит восстанавливать его через restore.php не то что не надо, а противопоказано!

Я бы распаковал руками из командной строки через tar, потом импортировал базу через mysql. Если вы никогда не делали ничего похожего, лучше обратиться к тому, кто знает.

Олег, с учетом того, что мы поддерживаем платформу, не конкретный проект, у нас в основном консультативные вопросы, не требующие моментальной реакции. Соответственно, мы работаем не круглосуточно, а стандартный рабочий день.



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

Как правильно заметил Сергей Ларин, в квадратных скобках пишется текст ошибки. Если его нет, значит системные функции не вернули информацию об ошибке. Значит, вероятнее всего, это проблема уровня сервера, ответ надо искать в логах MySQL.

А использовали нашу систему резервного копирования - восстановления? Если нет, попробуйте её. Там учитывается много вариантов хостинга.

https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=35&CHAPTER_ID=02014&LESSON_PATH=3906.4492.4496.2...

Улыбнуло

Мантис, конечно, заявки не прячет, но выделить какую-то заявку среди прочих непросто.

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

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

Логично, что в первую очередь правятся наиболее критичные для сайта/портала проблемы, затем востребованные наибольшим числом пользователей. Рядовые заявки закрываются в период межрелизья, когда идет плановая работа по закрытию багов. Соответственно, может получиться, что один тикет будет решен завтра, а другой - через пол года.

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

Мы все миримся с какими-то глюками мобильных телефонов, ведь так? Что-то мой андроид повис, возьму любимую нокию 3310 с кнопками и чб экраном, там всё работает

Коллеги, вопросы сертификатов и форума, пожалуйста, обсуждайте на партнерском форуме. Сообщения не по тебе удалил.

Проще сделать иначе.
Поправьте файл .access.php в корне портала, заменив
на
Это откроет доступ на чтение портала для всех.

Потом авторизуйтесь под администратором через $USER->Authorize(1); и поправьте.access.php обратно.

Спасибо за сообщение. Эта ошибка уже исправлена в обновлении главного модуля 15.0.1, которое доступно в бете. Пожалуйста, обновитесь.

Коллеги, простите, флуд пришлось удалить.

Олег, мне пришлось удалить цитирование переписки с техподдержкой: сообщения из техподдержки адресованы лично вам, исходя из вашей ситуации. Другим пользователям они могут только усложнить ситуацию.

Что касается самой проблемы, нужно понимать, что настройка доставки почты связана с настройкой сетевой инфраструктуры. Т.е. нельзя сделать инструкцию, которая будет работать всегда и для всех. Эту задачу должен решать ваш системный администратор. Не совсем правильно требовать решение этой задачи от техподдержки битрикса.
Мы со своей стороны постарались максимально упростить задачу, установив msmtp, который транслирует почту на внешний почтовый сервер (интернет провайдера). Обычно это хорошо работает. У него есть свой лог, где можно понять причину ошибки.

Postfix работает по-другому, при своей кажущейся простоте он достаточно сложен. Если вы никогда не настраивали MTA, вам лучше будет вернуться к msmtp.

Скрипт restore.php обновляется автоматически, для верности можете скачать его напрямую с нашего сайта: http://www.1c-bitrix.ru/download/scripts/restore.php

Что касается ошибки восстановления .settings.php, мы знаем о ней и уже исправили. Обновление restore её не решит, т.к. неправильный файл .settings.php попадал в архив резервной копии.

Мы понимаем, что это неудобно и просим извинить за это. В самом ближайшем обновлении ошибка будет исправлена.

Но сейчас обойти проблему очень просто: надо в этот файл в начало дописать код:

Создайте обращение в поддержку, укажите там свой старый ключ.
Мы предоставляем дистрибутивы старых версий по запросу при наличии ключа.

Чего только не прочитаешь на форуме!

Михаил правильно ответил: ничего компилировать не надо, настройка определяется в php.ini.
Только не забудьте перезапустить веб сервер, а потом открыть страницу phpinfo и убедиться, что настройка применилась.