Во-первых домен ip-123-456-789.eu свободен, а значит никакого поддомена ns123456.ip-123-456-789.eu быть не может.
Если у вас по нему что-то там открывается, то это уже вопрос в совершенно другой плоскости.
Но если в общих чертах, то всегда надо делать основной "заглушку". Чтоб при обращении по ip (или любому привязанному к этому ip домену) открывался не первый сайт из конфига, а эта заглушка.
Ну про злоупотребления - это скорей редкость, чем постоянно так происходит. И да, ограничить память можно уровнем выше, пусть хоть сколько угодно ставят memory_limit.
В любом случае, всем же не навязываю, у вас своя политика, у меня своя - чем меньше ограничений, тем лучше для конечного клиента. А с теми редкими случаями нагления лучше решать вопрос индивидуально, чем из-за них резать все подряд всем.
Да, auth_socket и по-сути да, авторизация конечно никуда не пропадает, а просто чуть упрощается. И да... возможно насчет какого-то ускорения это я загнул 😀
Просто была мысль попробовать, но застопорилось на проблеме скриптов типа phpmyadmin в открытом доступе.
Основная идея скорей была в упрощении. Т.е. добавляя новую базу, нужно бы было от пользователя только имя базы и все. Момент с логин/паролями вообще упразднить. И чтоб в скриптах своих логин/пароли на базу они могли использовать любые. К примеру перенес с другого хоста и сразу заработало, без правки конфигов.
Суть в том, что если что-то (например php скрипт) уже запущен от имени какого-то пользователя, то смысла еще авторизоваться по паролю к mysql нет никакого. Если это скрипт злоумышленника, то также не составит труда этим скриптом открыть любой файл конфига и там взять этот пароль.
Авторизация нужна если доступ к сокету mysql есть у всех (в случае одной общей mysql например) или, что еще хуже, mysql открыта портом в интернет.
А когда у нас все заперто в рамках одного пользователя (mysql, apache/php, все файлы), то эта доп. авторизация mysql вообще не несет ценности. Самое главное это не запускать опасный код из под себя. А если уж запустил, то все... никакая авторизация не спасет.
Если в двух словах, то да - именно запуск нескольких демонов от разных пользователей.
И да, любителям по 1000 юзеров пихать на сервер врядли подойдет т.к. памяти потребуется сильно больше. А для около-vip тарифов почему нет?
Но у меня к примеру на самом загруженном сервере нет и сотни аккаунтов. Несколько месяцев назад решил попробовать в качестве эксперимента.
Особо минусов не замечено и сейчас так сделано на всех серверах, даже на самых дешевых тарифах - все отлично.
Плюсы очевидны - выбор версий. Хош mysql, хош mariadb любой версии - не проблема.
Персональные my.cnf (как и php.ini у персональных апачей) у каждого. Правда конечно никто из клиентов всеми преимуществами пока не пользуется 😐 А ведь можно например если только innodb используются, то больше памяти ей отдать, урезать myisam или наоборот, вкл/выкл/настроить кэширование и т.д. При желании можно под свои сайты подтюнить свою mysql, чего на обычных шаредах конечно невозможно сделать. А главное, соседские более посещаемые сайты не вытесняют менее посещаемые из памяти. Даже если у сайта 3 захода в неделю, то вовсе не обязательно чтоб каждый был "холодным стартом", все должны работать максимально быстро. Ну и какие-то проблемы/падения одной чьей-то mysql вообще не повлияют на других. Сейчас везде ведь как, кому нужны эти преимущества, тем приходится переходить на vps, а там уже выше цена... за меньшее количество ядер процессора, и другие минусы.
Еще хотел было реализовать одну уникальную фичу - доступ к mysql без авторизации. Это в теории дало бы еще каплю ускорения если убрать проверку логин/пароля при каждом запросе.
С персональными mysql это сделать не проблема, но возникает повышенное требование к сознательности пользователей. К примеру закинет он себе adminer.php в корень или phpmyadmin/ и без авторизации это прямо дырища в безопасности. Но может позже еще и реализую опцию типа вкл/выкл авторизации и жирное красное предупреждение о возможных последствиях если будут в открытом доступе на сайте какие-то инструменты управления базами. Если не этот нюанс, то используя обычные cms проблем с mysql без авторизации вроде быть не должно. Наоборот только небольшой плюс к производительности и к примеру можно не париться если вдруг wp-config.php уведут (нормально же сделать архив сайта и просто скинуть его в корень или другое общедоступное место, да? 😀). Паролем этим просто ну никак не удастся воспользоваться, или вообще там можно будет вписать любой набор букв.
перечитал еще раз - нет, не понятно по первому посту, что стоит только апач. вполне можно предположить nginx+apache, потому собственно и упомянул.
да и вообще смутно представляю у кого еще остался чисто апач на фронтэнде. хотя и не исключаю таких уников конечно.
там даже не понятно идет ли речь про shared или vps.
показалось, что в принципе что-то имеете против nginx редиректов.
то что не дают в nginx лазить на шаредах - это да, но это уже совсем другой вопрос.
и опять же, если всеж речь про vps, то кто/что мешает? сам по себе редирект сразу на фронте это правильней, чем обвешивать бэк лишними плагинами или разводить еще больший бардак в htaccess.
почему речь вообще завел, потому что у меня на шареде уже не первый год именно это и используется - можно выбрать для каждого сайта как именно nginx'ом делать редиректы и делать ли вообще.
можно хоть вообще два независимых сайта иметь на http и https
нет, конечно именно напрямую править nginx конфиги юзерам давать нельзя. он ведь общий на всех и если споткнется на чьем-то кривом конфиге и сляжут все сайты, это ж не дело.
но простые вещи типа редиректов или выбора что nginx будет сам отдавать, а что и как передавать на бэк - почему нет, это можно и не сложно.
SeVlad, пишите в личку, сделаю аккаунт и бесплатно до конца года поюзаете, хоть посмотрите каким может быть shared хостинг. может хоть подобреете, а то видимо ютитесь по ширпотребным "крупнякам" и чувствуется раздраженность :)
само название mod_php говорит о том, что php в этом случае является составной частью апача, таким же модулем как mod_rewrite к примеру.
и все обращение апача к php происходит внутри одного процесса. во всех остальных случаях (даже nginx + php-fpm) происходит взаимодействие уже между процессами, через сокет, порт, т.е. самую малость, но сложней.
вот именно здесь и рождаются споры.
те самые 5-50% можно с микроскопом обнаружить лишь в определенных условиях. например при очень большом количестве запросов, что и делают бенчмарками... и понятно что к реальности это мало относится. либо на очень медленном железе.
дальше кто-то начитавшись пробует изменить у себя и конечно же не видит ни 5, ни тем более 50% прироста скорости.
все потому что на собственно php скрипты и mysql запросы уходит куда больше работы. и заметить на глаз микроразницу в режимах работы php нереально. скорей куда больше будет заметен переход с php5 на 7. и то не всегда.
так кто же прав? все правы по своему.
да, mod_php лучше и если нет противопоказаний, то почему б его и не использовать?
да, у всех разные ситуации и кто-то ту же проблему разграничения доступа решает через fastcgi, а не apache-itk (например панель только так может)
все равно куда большим тормозом будут продолжать оставаться скрипты, базы, мало памяти, диски, 2ггц процессоры и т.д.
и от смены fastcgi на mod_php не изменится вообще ничего.
но в то же время у кого-то другого может быть все наоборот - очень легкие скрипты и очень много траффика. те возможно и заметят даже на глаз переход на mod_php... все может быть.
мое мнение, что если есть что-то более быстрое, то нужно только его и использовать независимо от того какие сайты, быстрые/тормознутые, с траффиком/без.
от apache-itk отказался несколько лет назад в пользу независимых процессов apache/mod_php под каждого пользователя (а с недавнего времени и с mysql так же сделано).
плюсы очевидны - вся память и кэши принадлежат пользователю и не вытесняются другими, в случае каких-то падений/зависаний у одного, это вообще не влияет на других.
из минусов пожалуй лишь очевидно больший расход памяти, но то такое... докупное :)
и кстати спор fastcgi vs. mod_php можно спроэцировать и дальше.
например mysql локальный через сокет или удаленный по сети.
дисковое хранилище локальное или удаленное.
тоже, одни будут с пеной у рта доказывать что это медленно, а у других могут быть свои весомые причины использовать тот более медленный вариант.
но правда всегда одна - чем короче путь, тем быстрее он проходится. заметно/незаметно - это уже зависит от конкретного применения.
как правильно сделать редирект ОЧЕНЬ зависит от настроек.
самое правильное что можно сделать, выше сказали - обратиться к хостеру. лучше него никто тут не подскажет.
хотя если у вас например vps без администрирования, то да... надо будет самостоятельно вникать.
суть в том, что apache должен как-то понять по http сайт был открыт или https.
как именно - индивидуально. т.к. может быть просто апач, может nginx+apache.
и к примеру если https заведует nginx, а к апачу обращается по http, то тот может не правильно понимать как же все таки был открыт сайт. отсюда и возможные зацикленные редиректы.
короче нужно понимание по какому критерию ваш htaccess хочет определять http/https, например по номеру порта 80/443 или по наличию переменной HTTPS=on, или может еще как-то. ну и настроить связку nginx-apache уже под это дело.
либо еще лучше - сделать редирект на уровне nginx безо всяких htaccess'ов.
пока без понимания как у вас там все настроено ничего конкретного советовать невозможно.
пишите хостеру.
так и раньше же можно было это настроить. только не в nginx конфиге, а в openssl.cnf
однако AES128 убирать ради 100ки в ssllabs не стоит как по мне. он ведь чуть быстрей.
пока его не помечает там желтым, пусть лучше включен. плюс без него больше неподдерживаемых девайсов.
если уж загоняться, то можно и key exchange до 100 довести, увеличив размер ключа с 2048 до 4096. но опять же, в ущерб скорости :(
я делаю приоритет aes128, следом aes256 (чтоб баллы не терять в ssllabs), потом chacha для без-aes клиентов. остальное все убрано.
https://www.ssllabs.com/ssltest/analyze.html?d=vovk.com
вот:
https://habr.com/ru/news/t/524870/
в комментариях народ тоже бомбит от фейковости всех этих современных nvme дисков.
но в который раз повторюсь, это касается лишь дешевых моделей.
есть и такие, где потенциал раскрывается полнее и отличие от sata будет куда заметней.
