Евгений Крупченко

Евгений Крупченко
Рейтинг
178
Регистрация
27.09.2003
Интересы
хостинг без тормозов

Забавно что у вашего hosting-russia точно та же история. Первый заход очень долго, а последующие уже кэш работает и быстро.


Говорит лишь о том что очень медленный процессор или очень тяжелые скрипты/запросы к базе... либо и то и то сразу.

Остается лишь в настройках кэш-плагина посмотреть что там с таймаутами и повысить, смотря как часто меняться что-то будет на сайте. Но с пониманием что это костыль и иногда все равно будут моменты когда кэша нет и страница будет генерироваться несколько секунд.

mod_access - значит скорей всего apache не пускает, т.е. где-то в .htaccess всеж блок стоит по какому-то признаку.

в htaccess корневом стандартно все, а в самом wp-admin нету случайно?

/wp-admin/ обычно редиректит на /wp-login.php - если сюда просто напрямую зайти, тоже 403?

Минутка занудства для тех кому не все равно.

Что ж это за 3 циферки такие?

1 - права для пользователя (который обращается к данному файлу или папке)

2 - права для группы (в которую может входить/не входить этот пользователь или другие)

3 - права для любого пользователя.

Цифра - это комбинация трех галочек:

Чтение, запись и выполнение (запуск исполняемого файла или perl скрипта к примеру, либо поиск внутри каталога).

Кроме этого, у всех файлов и каталогов есть еще и владелец с группой (owner/group).

Пара примеров:

070 и пользователь не входит в группу - доступа нет.

700 и пользователь входит в группу - доступ есть.

004 и root:admins (владелец:группа) и пользователь user не входит в группу admins - доступ есть, но только для чтения.

000 - ни у кого доступа нет кроме root (у него есть при любом владельце и правах).

И в таком духе... нужен просто опыт чтоб быстро ориентироваться в этом всем.


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

Конкретных вариантов может быть множество.

К примеру, самое простое - у вас vps/сервер с одним сайтом. Вы конечно вправе иметь лишь одного root и все запускать от него. Все будет работать, но надо понимать что в случае допустим взлома лишь сайта, будет получен доступ ко всему серверу. Поэтому принято из под root'а запускать что-то только когда действительно иначе никак. И соответственно все службы запущены от других, ограниченных пользователей. Обычно это какой-нибудь www-data пользователь, от которого запускается apache. Чтоб в случае если кто-то получит доступ на запуск, то только от этого пользователя, т.е. доступ ограничен лишь этим пользователем.

Также может быть что web-сервер работает от www-data, а фтп сервер от какого-нть ftp юзера. Таким образом загружая по фтп файлы, они создаются с владельцем ftp и www-data доступа не будет иметь. Надо либо кого-то в какую-то группу добавлять, либо тупо открывать доступ "для всех" (последняя цифра). Именно отсюда растут ноги у советов ставить бездумно на все 777, 755 и т.п., т.е. чтоб наверняка заработало... и плевать на то как там все настроено и на безопасность 😐

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

Если на shared'е вы загружаете по фтп файл, ставите у него последнюю цифру 0 и у web-сервера пропадает доступ к нему - это очень плохой признак. Скорей всего там все настроено по принципу:


По-хорошему и ftp и web-сервер должы работать от имени вашего пользователя и без проблем иметь доступ если последняя цифра 0 в правах на файлы/каталоги.

Запускать же что-либо на таком хостинге в принципе не должно быть нужно обычно и цифру 7 на файлы ставить не нужно, 4-5-6 должно быть достаточно. Только если это perl/cgi скрипт, тогда да... но я даже не вспомню когда они и где последний раз вообще использовались. Но просто для понимания, что на файлы не надо ставить 7'ку (если только это не .pl или .cgi файл), иначе потенциально вам в cms например могут загрузить какой-то исполняемый файл под видом .jpg и браузером запустить его.

На папки да, 5 или 7 можно и нужно ставить, иначе не будет доступа на поиск внутри этой папки, т.е. не получится в нее войти этому пользователю.


У меня допустим давно и везде ставится всегда по-умолчанию user:user и 770 на папки, 660 на файлы. И очень раздражаюсь когда народ своими кривыми скриптёнками или копипастом дурных советов из интернетов тулят куда-попало 755 или 777. 👎

Есть пользователь и только он должен иметь доступ к своим папкам/файлам, и никаких "для всех". Ftp, web, mysql - все это работает от его имени и нормально имеет доступ куда ему нужно, не надо ничего трогать.


Как конкретно настроено что-то на конкретном хостинге - известно лишь его админам. Но если на бегете том же с правами 700 все работает нормально, то скорей всего не надо ничего трогать, пусть себе работает. Разве что (если нет perl скриптов) на файлы я б поставил всеж 6'ку

Sultan #:

меня пугает что поисковик как будто не может сканировать сайта.

Highly likely? Или есть доказательства? Ошибки в "поисковике" есть, в логах, в браузере что-то не открывается?

Если нет, то и проблема высосана из ничего, можно тему закрывать.

Так на файлы+папки или только файлы? или только папки?
Что именно пугает, 7 или 0?

Ну чтож, 25е число и PHP 8.1 полноценно вышел в свет.


https://php8.pp.ua/phpinfo.php

Из того что успел проверить:

Все расширения что были под 8.0, собираются и под 8.1 без проблем.

Ioncube для 8.1 по-прежнему нет, как и для 8.0.

phpMyAdmin 5.1.1 сперва плюнулся deprecated сообщениями, но скрыв их, вроде все работает:


Wordpress 5.8.2 не захотел устанавливаться:


Однако установив под 8.0, потом переключил на 8.1 и порядок на первый взгляд:


Естественно никого не призываю, и конечно же будет еще долго гора проблем с темами и плагинами. Но просто факт, сам WP работает под 8.1


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

https://www.phoronix.com/scan.php?page=news_item&px=PHP-8.1-Benchmarks-Perf-Early

У себя лишь заметил на вот этом скрипте:

https://github.com/php/php-src/blob/master/Zend/bench.php

Под 8.0 был лучший результат в районе 0.069-0.070, сейчас под 8.1 наблюдается частенько 0.067-0.068

https://php8.pp.ua/bench.php

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

totamon #:
при чем тут IP?

Вначале вроде четко сказано - " если сайт открывается по домену левому какому-нибудь".

Это возможно если сайт открывается по своему ip, т.е. он default'ный там.

Один из вариантов уже выше показали на примере djkcklfllrlrlllf.fgh, прописав в hosts 78.140.180.145 searchengines.guru.

Вот если searchengines.guru не захочет чтоб их сайт открывался по djkcklfllrlrlllf.fgh им и может понадобится либо вышеуказанный .htaccess, либо как вначале сказал - надо сделать default виртуальный хост с редиректом на searchengines.guru.

Кроме hosts это может также быть например если сайт переехал на выделенный ip, который ранее был в использовании и возможно даже какие-то домены все еще на него указывают. Т.е. по этим "левым" доменам будет открываться этот сайт.

Хотя если это будет не случайность/ошибка, а целенаправленное проксирование, то сервер все равно будет получать правильный домен в http_host и ничего никаким htaccess'ом действительно не средиректить.


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


p.s. упс, проверил, searchengines.guru отдает Bad Request - Invalid Hostname если по ip или другому домену, значит с djkcklfllrlrlllf.fgh там было не hosts, а проксирование... ну не важно :)

И кстати вот эта штука должна работать:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^domain\.ru$ [NC]
RewriteCond %{HTTP_HOST} !^www\.domain\.ru$ [NC]
RewriteRule ^(.*)$ https://domain.ru/$1 [L,R=301]

RewriteCond: bad flag delimiters - это скорей всего где-то лишний пробел в строчках RewriteCond

Проверьте. У себя проверил - работает. Захожу по ip, оно понимает что http_host не равен ни домену, ни www.домену и делает редирект.

Т.е. все изначально правильно, зря только уже на 2 страницы соплей развели.

Vladimir #:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{SERVER_PORT} ^443$ [OR]
RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ https://domain.ru/$1 [R=301,L]
</IfModule>

Стесняюсь спросить, что сие есть? Где тут проверка "левости" домена?

И я уж молчу про вариант nginx+apache когда apache на каком-нть 8080 порту висит и будет всегда думать что он на не-443'м. Ну и включать ssl на апаче в такой схеме тоже нет смысла, т.е. еще и HTTPS переменная никогда не будет on.

Если это shared хостинг, то по левому домену сайт никак не откроется, будет открываться default виртуал хост - обычно заглушка какая-то.

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

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

Всего: 623