Сегодня утром один из моих клиентов написал что всю ночь сайт не отвечает, а сейчас открывается по 20 секунд. Идем разбираться - с местом на сервер все в порядке, с настройками тоже, но загрузка всех ядер 100% и не думает падать. В логах очень много хитов, прямо таки аномально много, сайт не такой популярный) В итоге в логах вижу строчки огромной боли многих веб-мастеров - UserAgent: YandexBot 3.0. Бот прямо таки ненасытен - генерирует по 20-30 хитов в секунду. ЧТобы проверить действительно ли он "виновник происшествия" - блокирую в nginx все подключения с UserAget YandexBot. Для этого в блоке server конфигурации nginx прописываю:
if ($http_user_agent ~* (YandexBot)) {
return 403;
}
Нагрузка через некоторое время спадает, яндекс вебмастер начинает "плеваться" ошибками индексации в почту. Устанавливаю в панели Яндекс Вебмастер параметр "Скорость обхода сайта" на 1 запрос в секунду. УБираю блок в nginx. Загрузка снова растет до 100%, все ложится. То есть видимо параметр применится только на следующий обход. Смотрим что еще можно сделать чтобы умерить аппетиты Яндекса. На странице https://yandex.ru/support/webmaster/ro...obots.html нахожу еще одно решение - возвращать на все запросы код HTTP код 429. Прописываю в ini.php: http_response_code(429); Жду пару минут. Нагрузка спадает до нормальных значений. Но возвращать на каждый хит 429 как-то не правильно. То есть возвращать нам его нужно только когда высокая загрузка системы и возвращать только поисковым ботам. Реальному посетителю мы должны открыть сайт в любом случае с нормальными ответами. Набросал вот такой код и добавил в init.php:
Для определения мгновенной загрузки использую стандартную функцию sys_getloadavg. Так как на сервер 2 вычислительных ядра, нагрузка больше 2 это уже перегруз, в этом случае ничего не делаем и выдаем ошибку. Если же загрузка более 0.8 - просто выдаем код 429 и контент. В таком варианте работает сейчас. Значения порогов подбираете на вашем железе экспериментально.
Сейчас все чаще применяю блокировку на уровне nginx если есть доступ к конфигурации веб-сервера. Способ хорош тем что до выполнения PHP в этом случае дело даже не доходит и на отражение "атаки бота" ресурсов тратится кратно меньше. Для этого: 1) Создаем файл для кастомной блокировки /etc/nginx/vhosts-includes/custom_blocks.conf 2) В него прописываем примерно следующее:
### blocking bad bots (case insensitive).
if ($http_user_agent ~* (ClaudeBot|SemrushBot|AhrefsBot|Riddler|aiHitBot|trovitBot|Detectify|BLEXBot|LinkpadBot|Mozilla.*Indy|Mozilla.*NEWT|SeaMonkey|Acunetix|binlar|BlackWidow|Bolt\s0|BOT\sfor\sJCE|Bot\smailto\:craftbot@yahoo\.com|casper|checkprivacy|ChinaClaw|clshttp|cmsworldmap|Custo|Default\sBrowser\s0|diavol|DIIbot|DISCo|dotbot|Download\sDemon|eCatch|EirGrabber|EmailCollector|EmailSiphon|EmailWolf|Express\sWebPictures|extract|ExtractorPro|EyeNetIE|feedfinder|FHscan|FlashGet|flicky|g00g1e|GetRight|GetWeb\!|Go\!Zilla|Go\-Ahead\-Got\-It|grab|GrabNet|Grafula|harvest|HMView|Image\sStripper|Image\sSucker|InterGET|Internet\sNinja|InternetSeer\.com|jakarta|Java|JetCar|JOC\sWeb\sSpider|kanagawa|kmccrew|larbin|LeechFTP|libwww|Mass\sDownloader|microsoft\.url|MIDown\stool|miner|Mister\sPiX|MSFrontPage|Navroad|NearSite|Net\sVampire|NetAnts|NetSpider|NetZIP|nutch|Octopus|Offline\sExplorer|Offline\sNavigator|PageGrabber|Papa\sFoto|pavuk|pcBrowser|PeoplePal|planetwork|psbot|purebot|pycurl|RealDownload|ReGet|Rippers\s0|sitecheck\.internetseer\.com|SiteSnagger|skygrid|SmartDownload|sucker|SuperBot|SuperHTTP|Surfbot|tAkeOut|Teleport\sPro|Toata\sdragostea\smea\spentru\sdiavola|turnit|vikspider|VoidEYE|Web\sImage\sCollector|WebAuto|WebBandit|WebCopier|WebFetch|WebGo\sIS|WebLeacher|WebReaper|WebSauger|Website\seXtractor|Website\sQuester|WebStripper|WebWhacker|WebZIP|Widow|WPScan|WWW\-Mechanize|WWWOFFLE|Xaldon\sWebSpider|Zeus|zmeu|360Spider|CazoodleBot|discobot|EasouSpider|ecxi|GT\:\:WWW|heritrix|HTTP\:\:Lite|HTTrack|ia_archiver|id\-search|IDBot|Indy\sLibrary|IRLbot|ISC\sSystems\siRc\sSearch\s2\.1|LinksCrawler|LinksManager\.com_bot|linkwalker|lwp\-trivial|MFC_Tear_Sample|Microsoft\sURL\sControl|Missigua\sLocator|MJ12bot|panscient\.com|PECL\:\:HTTP|PHPCrawl|PleaseCrawl|SBIder|SearchmetricsBot|Snoopy|Steeler|URI\:\:Fetch|urllib|Web\sSucker|webalta|WebCollage|Wells\sSearch\sII|WEP\sSearch|XoviBot|YisouSpider|zermelo|ZyBorg)) {
return 403;
}
3) Перезапускаем nginx, радуемся... Но недостаток - нет получения текущей загрузки системы и возвращения 429 кода. Если есть джедаи nginx которые подскажут как такое можно реализовать - буду благодарен.
Сегодня узнал очень простой способ запустить сайт на Битрикс в режиме php-fpm (Когда из веб-сервера только nginx и php) для пользователей хостинг-панели ISPManager. Он поможет запустить, думаю, 95% сайтов на битриксе где используются стандартные роуты. Если роуты кастомные, конфиг уже придется дорабатывать. Для этого в панели ISPManager заходим в настройки нужного сайта и переключаем режим работы в FastCGI (Nginx+PHP-FPM). Далее в списке сайтов выделяем галочкой сайт который только что отредактировали и нажимаем на кнопку "Конфиг. файлы". В открывшемся редакторе ищем строку:
Сохраняем изменения и пересохраняем настройки сайта для применения изменений. Заходим на сайт проверяем что все работает. Если выдается ошибка "Forbidden" - в настройках сайта в секции "Индексная страница" указываем index.php.
Себе на память - что делать если при восстановлении из резервной копии выводится ошибка:
Ошибка! IP адрес клиента изменился, продолжение невозможно.
Самое простое решение это просто перезаписать файл restore.php свежезагруженным. Но если это в текущей ситуации неудобно, можно открыть существующий файл restore.php на редактирование и найти строки:
В первой строке файл записал ip адрес, с которого его первый раз запустили, во вторую строку - время первого запуска. Ошибки выдаются как при изменении ip адреса так и если прошло более суток с момента INIT_TIMESTAMP. Самое простое решение если нужно сохранить существующий файл но сбросить указанные значения - просто вписать туда плейсхолдеры по умолчанию:
Увидев такие плейсхолдеры скрипт при следующем запуске автоматически перезапишет их актуальными данными. Также можно вписать руками актуальный ip адрес и текущий timestamp - сработает аналогично.
Встала задача написания некой недоCICD для автоматичсекой раскатки стендов для разработчиков с определенной базовой системой на борту и автопуллом нужной ветки из Гита. И при разработке поймал себя на мысли, что ваять руками все процессы по созданию виртуального хоста и редактированию настроек как-то не правильно. То есть задача - найти способ через командную строку 1-2 командами создавать нужный допсайт на окружении, далее разворачивать нужную "эталонную версию" системы и делать пулл нужной ветки Git с выполнением невыполненных миграций. Со всеми процессами кроме первого особых проблем нет, главное заранее подготовить архивы "Эталона". А вот чтобы создать нужный хост, кроме как заходя в меню окружения - и никак больше - так говорил оооочень долгий поиск гугла и яндекса. Но при поиске случайно накнулся на вот этот пост на Яндекс Дзене https://dzen.ru/media/id/5b1a58b8eb269...ujenie-... То есть в окружении все таки есть возможность создать вхост одной командой.
Делается это следующим образом - в shell вводим:
/opt/webdir/bin/bx-sites -a create -s site.local-dev.ru -t kernel --charset UTF-8 --cron
Да, сайт создается, но не настраивается поддержка Push сервера, что крайне необходимо для доработок Битрикс24. Для этого открываем и "препарируем" блокнотиком файл /opt/webdir/bin/bx-sites, особенно образая внимание на блок (с 71 строки):
Здесь у нас описаны все доступные команды для добавления и редактирования сайтов, то есть если нужно создать вхост для Битрикс окружения с пуш сервером, команда будет выглядеть так:
Cоответственно если нам нужно удалить какой-то из сайтов, команда будет иметь вид:
/opt/webdir/bin/bx-sites -a delete -s site.local-dev.ru -t kernel -r /home/bitrix/ext_www/site.local-dev.ru
На вид вроде все просто - команду выполнили через PHP Exec (или откуда вы там решили управлять стендами) и поперли дальше. А не просто) В окружении есть встроенный планировщик задач, который при выполнении создает задачу на создание или удаление сайта. И если вы хотите правильно автоматизировать создание стендов - то сначала нужно дождаться выполнения этой задачи, а потом уже выполнять все последующие действия. Для этого нам пондобится узнать список текущих задач и их статус, поможет нам следующая команда:
/opt/webdir/bin/bx-process -a list
Она в виде построчных массивов с разделителем двоеточия выдает все текущие задачи, нам остается только убедиться янет ли задач в статусе running.
Очень часто при переносе резервной копии Битрикс с одного сервера на другой мы прибегаем к помощи небезизвестного скрипта restore.php. Обычно с ним проблем не возникает, но бывают "особенные" случаи. Мой случай: Клиент дал доступ только к админке. Проект развернут на сервере с доступом только по https, с сертификатом от другого домена. В итоге, когда начинаем делать до боли привычные действия, а именно, компируем ссылку на резервную копию в админке предоставленного сервера и вставляем в форму restore.php сервера куда переносим происходит:
Warning: stream_socket_client(): Peer certificate CN did not match expected
Если вывод ошибок выключен, не выведет даже этого - просто мол невозможно загрузить хотя ссылка правильная. Включить доступ по http или менять сертификат возможности не было, поэтому начал поиск других вариантов. Вариант был найден. PHP функция которая валится при попытке загрузить данные с HTTPS с некорректным сертификатом (на момент написания данного поста 2425 строка файла restore.php) имеет вид:
В переменной $context задаются настройки контекста функции stream_socket_client, которая собственно и инициирует подключение. Как ее заставить игнорировать неправильный домен сертификата - очень просто, нужно просто в контекст добавить:
Применяем эти изменения в restore.php и загрузка идет без проблем. Информация актуальна на 17.11.2019. ВНИМАНИЕ! Производя данные манипуляции с файлом restore.php вы отключаете механизмы проверки SSL. Это крайне негативно сказывается на безопасности. Делайте это только в том случае если понимаете что делаете.
Всем спасибо за внимание, возможно кому-то пригодится.
Начиная с момента введения известным удостоверяющим центром "Lets'Encrypt" лимитов на количество получаемых сертификатов, у всех клиентов, имеющих на одном сервере с Битрикс окружением более 5 сайтов, начались постоянные проблемы с получением новых сертификатов при добавлении к окружению нового сайта. Беглый анализ логов dehydrated показал следующую картину - при добавлении сертификата к каждому новому домену пере выпускаются сертификаты ВСЕХ доменов окружения, полученные в LE, даже те которые получены 5 минут назад и прекрасно работают. Далее ладно бы скрипт dehydrated если для какого-то домена нельзя получить сертификат - писал в лог ошибку и переходил к следующему домену. Если вывалилась ошибка лимита - процесс ПОЛНОСТЬЮ прерывается и не запускается даже для тех доменов, у которых лимит не исчерпан. Данный вопрос был задан пользователем https://dev.1c-bitrix.ru/community/web...ser/73692/ в теме форума https://dev.1c-bitrix.ru/community/for...sage651822 Ответ администрации не заставил себя ждать и был - "мы ничего не значем, так работает dehydrated, ждите дня когда лимит спадет". Феерично, не правда ли! То есть нужно тебе перенести больше 20 сайтов с сервера на сервер - ТЫ БУДЕШЬ ПЕРЕНОСИТЬ ИХ МЕСЯЦАМИ, СТРАДАТЬ, и молиться на LE чтобы лимит не закончился в неподходящий момент. При этом не забывая платить за 2 сервера и отмазываясь перед клиентом почему простая операция заняла такой дикий срок!
Как я решал данную проблему:из папки /home/bitrix/dehydrated/domains переносим куда-нибудь в другое место текстовые файлы всех доменов, которые уже получили сертификаты. Далее перезапускаем через меню окружения получение сертификата для нужного сайта. dehydrated отрабатывает только для нужного домена. После получения сертификата таким способом текстовики перенесенных из папки доменов нужно вернуть, чтобы обновление сертификатов проходило штатно. Надеюсь разработчики окружения все-таки посмотрят в сторону клиентов, и доработают логику получения сертификатов. Там не такие большие изменения нужны чтобы решить данную проблему.
Добро ночи! Сегодня обновлял клиенту BitrixEnv с 5 на 7 версию. И в очередной раз вылезла пресловутая и давно известная на форуме проблема с пакетом ansible, который теперь стал конфликтовать с пакетом bx-ansible из новой версии репозитория. Выкидывает целую кучу "страшных" ошибок, а решается проблема 3 строчками в консоли:
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».