<script type='application/ld+json'> { \"@context\" : \"https://schema.org\", \"@type\" : \"WebSite\", \"name\" : \"".$название_что_хошь." - ".$девиз_что_хошь."\", \"url\" : \"https://".$_SERVER['SERVER_NAME']."\" } </script>
Вместо $переменная мжно ручками текст. Вставлять достаточно только на главной.
Механизм блокировки РКН мною не изучался никогда, ибо незачем. Но я краем уха знаю, что он сегодня достаточно сложен и учитывает множество факторов, в том числе - редиректы. Поэтому, если говорить об использовании любых прокси, включая CF, с целью обхода блокировки, я уверен - что не сработает.
У ТС и вообще в этой теме проблема другая и очевидная - сбои NS-серверов провайдера. И эти сбои никак нельзя исправить с нашей стороны, это только хостинг-провайдер рулит. Поэтому проблема решается на 100% использованием ДРУГИХ NS серверов, благо это бесплатно и просто, и даже не приводит к временной недоступности сайта. Испольовать можно любые DNS-хостинги, например
CloudFlare - под ним почти 30% интернета, недостаток - он впаривает свои улучшалки, которые на саомом деле нет, от них надо отмахиваться, но в ЛК они все равно будут висеть немым укором. Но этот недостаток ничтожный.
DNS хостинг от Яндекса. Дерьмо, как все от Яндекса.
Selectel - он хорош тем, что интегрируется с моей любимой FastPanel но есть жалобы на стабильность.
У меня победил CF.
У тебя если тоже в мониторинге есть ошибки " Невозможно определить IP по указанному адресу." это тоже проблема DNS а никак не блокировки РКН. Проверить просто - возьми да по одному из доменов смени на CloudFlare, это легко обратимая процедура.
Смешно.
Это сейчас серьезно?
В контексте темы этой ветки - не поможет ничем.
Вот это оно. Какие у тебя NS-сервера используются?
Его.
Лечится переносом DNS-хостинга например в CloudFlare (ТОЛЬКО ДНС! Никаких там прокси и всяких других улучшателей, которые они будут впаривать), это бесплатно и просто.
Я сам позавчера это сделал, ибо проблема была ровно как у тебя, и виноват в этом был хостинг-провайдер, и сделать больше с этим ничего нельзя.
Это неважно. Должно быть не "в большинстве" а "везде без исключения" кроме случаев "точка мониторинга недоступна".
Афигеть, сколько лишних денег у людей. Ну или обортистые ребята просто... Что за ничего платите :-)
Есть большая разница PHP-FPM и FastCGI (просто CGI не имеет смысла, устарел). В PHP-FPM не работает .htaccess - если у тебя там редиректы, то их надо переносить в конфиг NGINX, причем не в основной, который любая панель имеет обыкновение перезаписывать, а в какие-нибудь include.
А в целом ISPmanager фтопу тебе надо, судя по вопросам :-)
Не дает править собственный пост... Поправка: выполнение скрипта под fastuser позволяет дробить только локальные бэкапы (созданные им же), то есть если внешние льются под другим юзером, то нужно:
1. Залогиниться под root и в файл /etc/sudoers добавить под строчкой "root ALL=(ALL) ALL"
fastuser ALL=(ALL) NOPASSWD: /var/www/fastuser/data/www/SplitArchive.sh
Это даст fastuser-у привилегии root но только на один скрипт, тот, что нужен. Не знаю, важно ли - но в sudoers как и в скрипте строки только с LF, без CR
2. В планировщике добавить sudo
sudo /var/www/fastuser/data/www/SplitArchive.sh
Все, теперь точно работает.
Странное поведение и странные рассуждения, никто в здравом уме не выберет такую "компанию друзей", на рынке куча предложений, где все понятно и прозрачно и есть нормальные реквизиты.
Ничего странного. Если есть чего скрывать. Например, если хочешь изначально кинуть людей. Или токсичная юрисдикция.
Если ИП на УСНО 6% без сотрудников, то бухгалтерия вообще не нужна. Достаточно бесплатной версии "Бизнес Пак" для выставления счетов и формирования закрывающих документов и раз в год "Налогоплательщик ЮЛ" для налоговой декларации.
В теории нужна КУДИР (книга доходов и расходов) но ни одна налоговая никогда ее не потребует с упрощенца 6%. А даже если случится чудо и потребует - то слабать ее на коленке можно за полдня задним числом.
