Алексей Мокрушин (Все сообщения пользователя)

Но сама возможность на вайлды у летсенкрипта уже есть

Эта проблема не из-за неверной настройки кэша, а проблема настройки кэша самой системой. И кэш этот МЕНЮ. Эта проблема тянется много лет. Я решал ее в 2 подхода, потому что у меня большой сайт и кэша тоже много и меню несколько уровней. Сначала по выработанному гайду я во всех компонентах меню добавил следующее:
"CACHE_SELECTED_ITEMS" => "N"
Это помогло лишь отчасти: в скорости забивания inodes, они ЧУТЬ медленней стали забиваться. Прошло время, я заколебался чистить их опять. Гуглил и ходил по параметрам настройки в хэлпе и нашел еще один параметр:
"MENU_CACHE_USE_USERS" => "N"
Он убирает кеширование прав, насколько я понял. После этого мои волосы стали шелковистыми, а сервер перестал неожиданно падать. Вот так у меня было: http://joxi.ru/n2YB7d7io35xZA

Отчего же? nginx по имени хоста будет определять какому сайту отправлять запрос

А как правильно в результате?

Интересно с 7.0 на 7.3.2 если перейти (5,5 и 7.02 mysql и php) Это сильно смертельно или лучше не шутить )

Потому что релоад не перегружает процесс полностью, а это важно

Отличное решение, добавляется в conf-файл в /etc/nginx/bx внутри блока server - который отвечает за ваш сайт

А у вас в секции server какие server_name?

server {    listen       443;
   server_name  example.org  www.example.org;
}

Может у вас там "_" стоит? То есть обрабатываются все запросы с любого хоста?

Можно сделать отдельную секцию для вашего IP и там уводить запрос в return 444 (закрытия соединения)

server {
listen      443;
   server_name "" 123.123.123.123;
   return      444;
}


Почитайте документацию http://nginx.org/ru/docs/http/request_processing.html  

Сделать лучше 301 редирект на тот адрес который вы считаете основным. По хорошему, у сайта не должно быть лишних зеркал, да еще и некорректных. Переадрессация в соответствующих секциях server в конфигурации nginx для http и https отдельно.

Где же его взять? )

Да не бойтесь, но не сразу на продакшен )


upd: в принципе, если есть чистая установка centos то я думаю что проблем вообще не будет. А Линукса бояться - в интернет не ходить )

У меня стояла версия BitrixEnv 3.0.5. Решил обновить до 4.1 - тем более там сразу PHP 5.3. надо было. Ну по инструкции удалил нужное через yum remove|erase и пошел ставить пакет. Ну были ошибки с perl-XML-SAX - удалил пакет и переставил вручную - ошибки прошли. В результате мне поставился почему то PHP 5.2, а я то ожидал 5.3... Начал руками переставлять, танцы с бубном, все такое (я наконец-то понял отчетливо почему про танцы это из Линукс-среды пошло ))) Тут все наглядно и виден весь танец ) Гугл мне в помощь - проапдейтил до 5.3.
Мониторинг запустился наполовину - Nagios заработал, а Munin ни в какую...конечно это не критично, но хотелось бы чтобы было понятно почему. При перезапуске мониторинга каждый раз Мунин перезаписывает пароль себе с логином (странно), однако под этими паролями мне не удается зайти выдает веб-окружение 403 ошибку (сайты еще не загружены) Я уж и каталог ему менял с /var/www/html/munin на то что было в конфиге и так и сяк - бесполезно. Не подскажете как же его запустить или заново проще переставить его? Должен же вроде из коробки. В Интернете подобная проблема у Убунтоводов только, но подобное у себя до конца не нашел или не доделал - не получилось.
Кстати Apache не сразу запустился не находил php5*.so - не потому пути искал, как выяснилось... )

И есть такие решение проблемы? У нас тоже самое....

Такая же проблема, в консоль заходит, а в этом диалоге нет, куда копать?