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

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

Тот openapi-sandbox.kucoin.com выдает вам ответ 401 Unauthorized

И Invalid KC-API-SIGN - что бы это ни значило.

Т.е. со скриптом все ок, но не ок со взаимодействием с тем сторонним хостом. Уж не знаю что и как там должно быть.

Во-первых домен ip-123-456-789.eu свободен, а значит никакого поддомена ns123456.ip-123-456-789.eu быть не может.


Если у вас по нему что-то там открывается, то это уже вопрос в совершенно другой плоскости.


Но если в общих чертах, то всегда надо делать основной "заглушку". Чтоб при обращении по ip (или любому привязанному к этому ip домену) открывался не первый сайт из конфига, а эта заглушка.

<fieldset>
<legend>Capture</legend>
</fieldset>

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

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


Да, auth_socket и по-сути да, авторизация конечно никуда не пропадает, а просто чуть упрощается. И да... возможно насчет какого-то ускорения это я загнул 😀

Просто была мысль попробовать, но застопорилось на проблеме скриптов типа phpmyadmin в открытом доступе.

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

Суть в том, что если что-то (например php скрипт) уже запущен от имени какого-то пользователя, то смысла еще авторизоваться по паролю к mysql нет никакого. Если это скрипт злоумышленника, то также не составит труда этим скриптом открыть любой файл конфига и там взять этот пароль.

Авторизация нужна если доступ к сокету mysql есть у всех (в случае одной общей mysql например) или, что еще хуже, mysql открыта портом в интернет.

А когда у нас все заперто в рамках одного пользователя (mysql, apache/php, все файлы), то эта доп. авторизация mysql вообще не несет ценности. Самое главное это не запускать опасный код из под себя. А если уж запустил, то все... никакая авторизация не спасет.

locoye1191 #:
Украинцы делают хостинг и сразу сливаются. Больше года не хватает. Это уже 3 хостинг который сделал так. Похоже у них это нормально.

Попросил бы не обобщать.

Вы сами умудрились заплатить непойми кому, а теперь все виноваты?

Самое первое что нужно смотреть это кто такие, где находятся, офф регистрацию проверять и т.д.

Вот у вас претензия образовалась к ним и дальше что? Кому предъявлять? Нужно было об этом думать ДО оплаты.

Там где анонимность, там высокий % жулья.

Если в двух словах, то да - именно запуск нескольких демонов от разных пользователей.

И да, любителям по 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 локальный через сокет или удаленный по сети.

дисковое хранилище локальное или удаленное.

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

но правда всегда одна - чем короче путь, тем быстрее он проходится. заметно/незаметно - это уже зависит от конкретного применения.

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

если vps, панель какая-то, то придется самому вникать как она там все настроила.

и в случае если nginx+apache, не понял упрека, чем плох редирект на уровне nginx конфига?
просто решаем какой вариант принимать за основное зеркало сайта (http или https, www или без) и все остальные редиректим на него. все, никакой больше мороки ни с чем. сайту/cms вовсе не обязательно в этом участвовать.
какие минусы не пойму?

как правильно сделать редирект ОЧЕНЬ зависит от настроек.

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

хотя если у вас например vps без администрирования, то да... надо будет самостоятельно вникать.


суть в том, что apache должен как-то понять по http сайт был открыт или https.

как именно - индивидуально. т.к. может быть просто апач, может nginx+apache.

и к примеру если https заведует nginx, а к апачу обращается по http, то тот может не правильно понимать как же все таки был открыт сайт. отсюда и возможные зацикленные редиректы.

короче нужно понимание по какому критерию ваш htaccess хочет определять http/https, например по номеру порта 80/443 или по наличию переменной HTTPS=on, или может еще как-то. ну и настроить связку nginx-apache уже под это дело.

либо еще лучше - сделать редирект на уровне nginx безо всяких htaccess'ов.


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

пишите хостеру.

Всего: 501