Евгений Смолин (Все сообщения пользователя)

Может проще на utf-8 перейти? Это не так сложно, а решает массу проблем сразу. К тому же что там дальше будет с cp-1251 одному богу известно.

bin-log нужен для репликации и восстановления данных в InnoDB-движке (при сбое). Если репликация не используется, незачем хранить binlog в несколько суток. Да и вообще, незачем его такой громадный хранить.

expire_logs_days = 2 - ограничить время хранения 2мя днями (сколько не жалко)
max-bin-log-size = 500M - ограничим размер в 500М (или сколько вам не жалко. Учитывайте, что InnoDB не сразу может писать данные в базу, т.к. является транзакионным движком. Но уж за пару минут-то запишет)

Еще можно попробовать добавить:
binlog-cache-size = 128K
max-binlog-cache-size = 100M - макс. размер кеша бинлога

Пробуйте.

Естественно, после добавления или изменения настроек, перезапустить сервер MySQL

Для своего случая (Debian 9, PHP 7.1.33, только Apache, кодировка нужного сайта CP1251, другие сайты - UTF-8  ) решил проблему так:
- проверяем установленные локали на сервере:
locale -a
C
C.UTF-8
POSIX

ага, нет cp1251

- запускаем  dpkg-reconfigure locales
 выбираем из списка:
ru_RU.CP1251 CP1251
ru_RU.UTF-8 UTF-8

на следующей странице по умолчанию выбираем ru_RU.UTF-8 UTF-8 (UTF-8 сайтов просто физически больше, да и дебиан настроен на UTF-8 в консоле)

дальше система все ставит и настраивает сама.

- в /bitrix/php_interface/dbconn.php добавляем:

setlocale(LC_ALL, 'ru_RU.CP1251');
setlocale(LC_NUMERIC,'C');

- перезапускаем веб-сервер (в моем случае только Apache): /etc/init.d/apache2 restart
(или service apache2 restart)

Проверяем: Тестирование системы -> Полное тестирование системы

Ошибка ушла!
При этом в системе все нормально работает и с UTF-8 сайтами в других каталогах

 

Честно, я не знаю как просто и быстро определить тип лицензии, кроме плясок с бубном

Хм, ну тогда читаем список модулей и на основе анализа определяем тип лицензии.
Список модулей, в зависимости от версии: https://www.1c-bitrix.ru/products/cms/license.php  

\bitrix\modules\main\classes\general\version.php определяет константу SM_VERSION с текущей версией системы и дату SM_VERSION_DATE

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

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

Посмотрите вот это : https://dev.1c-bitrix.ru/support/forum/forum6/topic29679/   - может поможет?

В robots.txt запрещаете индексирование  Disallow: /*&showall_1= и /*?showall_1=.
В header ставите <link href="https:// ваш_домен.ру/ваш_адрес_страницы" rel="canonical" />, тогда пусть хоть 1000 одних и тех же страниц с разными параметрами, поисковики будут индексировать только нужные версии.
Ну и совсем уж хардовый варианты - для "лишних" страниц ставьте в header <meta name="robots" content="noindex, nofollow" />
Все изменения в header придется писать самостоятельно - нет штатных механизмов.  

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

Это не битрикс. Какой то плагин в хроме на том компьютере стоит или вирусы. Проверяйте, чистите этот особый компьютер. Попробуйте adwcleaner запустить - почистит немного с последующей перезагрузкой.

Алексей Пустоутов, не слушайте ни кого, делайте, да воздастся вам благодарными пользователями! Уверен, спустя какое то время Docker-контейнеры будут уже стандартным дистрибутивом Битркса  

Только нагрузку создают, возможно, еще, парсят ваш сайт. Смотрите логи доступа access.log. Выбирайте ботов и баньте их в своем .htaccess.
Например:
# hacker
deny from 95.30.30.13
# Hetzner - подсетка
deny from 95.216.0.0/15

Или
# баним бота по части user-agent
RewriteCond %{HTTP_USER_AGENT} MJ12bot [NC,OR]
# баним бот по рефереру (реф-спам). Обратите внимение на последнее условие [NC] - оно последнее, перед действием, поэтому не [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://.*darodar\.com/ [NC]

RewriteRule ^.* - [F,L]

После этого такие посетители будут видеть 403 ошибку.
Только не забаньте ботов Яндекса и гугла

В реальности проблем будет куча, даже если все рекомендации Bitrix выполнялись. Например, у меня, при обновлении с 12.5 на 16 правильно не обновился двиг, в админке пропала куча функций (большое количество служебных *.js не обновилось автоматически). Лечилось копированием всех служебных директорий Битрикса из текущего дистрибутива, затем проверки, исправления БД штатными средствами. Так что нужно готовиться к проблемам. Лучше всего, обновить свой отладочный сервер, затем после всех исправлений выложить на рабочий.

Чем же вам не понравился TimeWeb? Вы просто не умеете его готовить: под большую нагрузку берется vps/vds или выделенный сервер. Если же вы взяли shared-хостинг, глупо рассчитывать на безотказную работу. Точно такая же ситуация будет и с другими shared-хостингами.

То же самое было. Еще хуже - в пути может быть только часть раздела (не все символы) и этот путь попадает в индекс Яндекса, а основной путь выбрасывается из индекса, как дубль.
Решал вводом meta canonical и модификацией компонент, которые теперь добавляют canonical в < hea der >

Обновлял Старт с 12.5 на 16.5 - 4 версии всего, но в админку не закачалось куча файлов с иконками и js-скриптами. Пришлось руками копировать разделы с рабочей версии 16.5 на обновляемую. Потом проверка сайта - исправление выявленных расхождений в структуре базы, которые автоматом не исправились, потом полная переиндексация. И это простенький сайтик на Старте. Так что  - готовьтесь к веселым событиям. Но да, сделать все можно, даже без обращения в тех.поддержку. В ТП сделают все это самостоятельно, предполагаю, все те же самые действия, только дольше по времени из-за медленного отклика.  

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

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

Подождите, у вас сервер падает? Если нет, то все нормально - *nix использует имеющуюся память под разнообразные кэши и буфера. Сам по первости пугался - память стремилась к 0, потом поизучал темы - так и должно быть.

Например, посмотрите статейки по запросам "unix что потребляет память", типа _https://www.it-rem.ru/linux-kto-sel-vsyu-pamyat.html

А у меня чуть сложнее:
- проверяю на наличие стоп-слов в сообщении (в том числе html теги <a href)
- проверяю на замену символов в слове на другом языке
- проверяю на количество точек в имени email
- проверяю на наличие стоп-email
- .htaccess на странице с формой со списком IP спамеров.

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

Кстати, очень хотелось бы получить google-капчу штатным способом (пока битрикс предлагает только свою капчу, которая уже давным-давно разгадывается ботами)

Да. Александр - в базе хранятся только данные файлов (ссылка на место на диске, его параметры и имя файла), сами файлы хранятся на диске.
По идее, битрикс должен удалять файл при удалении ИБ, но, на сколько я знаю, мусор из брошенных файлов остается. Поэтому, контролируйте этот момент самостоятельно: обработчики на удаление ИБ с заданным id. Легко проверяется - заведите ИБ, создайте файл, затем грохните ИБ и посмотрите наличие файла. Мне кажется - он останется. Давно не проверял, нарно с версии 12.5 еще.  

Инфоблоки, тип данных - файлы, множественное, доп.свойство - привязка к пользователю (хотя, можно сделать название элемента ИБ = id пользователя и дальше его везде использовать). Фактически, файлы будут храниться в обычных директориях, не а базе. В базе только их id. В базе хранить файлы, просто безумие.

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

У меня самого до сих пор есть несколько проектов на 12.5  версии, который не обновляю в силу ряда причин. Их не взломали, не сбрутили. Да и Битрикс уже давно очень и очень взломостоек. Так что, либо у вас ломанный хостер, либо украдены пароли с ftp/ssh/админки (возможно брутфорс).

По ссылкам, которые открывают страницы - смотрите логи, куда идет первоначальное обращение, куда делается редирект, смотрите файл .htaccess, смотрите файл urlrewrite.php, 404.php в корне. Но если система скомпрометирована, может быть все, что угодно, вплоть до модификации ядра. (Поэтому делайте все на локальной точной версии работающего проекта)

Да, производитель не обязан поддерживать систему без подписки на обновления. (Вы, правда, думаете, что кто то будет тратить силы/средства/время на поддержку устаревшей системы?) Покупая свою систему вы соглашались с этими условиями. Поэтому все претензии направляйте своей жабе и только.

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

P.s. вставка кода может быть и закодированным способом, типа eval(), в котором обфусцированный код. (Есть несколько файлов самого битрикса с таким кодом, но их единицы и они в ядре. Можете дистрибутив и сравнить эти файлы с вашими. Все остальные файлы с такими вставками будут уже подозрительными)

Никак. Битрикс можно определить ВСЕГДА. Даже на уровне защиты от копирования (посмотрите отпечаток в response header), название переменных в куках, название директории bitrix, директории uploads, bitrix/admin/ и т.д.). И эти признаки скрыть нельзя (весь двиг завязан на таких особенностях), а все сервиса определяющие использованные на сайте CMS с этими признаками прекрасно знакомы.
Да и с этической точки зрения, участвовать в мошенничестве по обману заказчика не хорошо (каждому воздается жизнью по его заслугам).