В http-сервере Nostromo (nhttpd) выявлена уязвимость...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51716
Использую везде Apache. Стабильно, быстро, безопасно.
Пссс. Открою тебе секрет: Мало кто умеет готовить апчхач. Поэтому все эти неосиляторы орут, что он медленный, дырявый итд и срочно надо на nginx.Но чтобы приготовить апчхач надо всё-таки постараться, nginx работает более-менее удовлетворительно из коробки, реврайты в нём намного проще, чем у индейца. Да и проксирование организовать тоже намного проще в жинксе, чем у апача. Если не хочется терять время на раскуривание апача в проде, то берёшь nginx и раскуриваешь его.
Заминка в том, что если ты берёшь apache httpd, то про mod_{perl,python,php} надо сразу же забыть. А формально это то, ради чего и поднимают апчхач. Кроме того, .htaccess/реврайты тоже работает более, чем странно, когда у нас на приложение идёт проксирование, то есть он тоже отпадает. Это вторая киллер-фича апача, ради которой ставят апач. Остальное настраивается более сложно/странно, чем в случае с nginx-ом.
Собственно, если у тебя апач работает фронтом, кэширует или раздаёт статику и проксирует запросы в бэкэнд... то по скорости он +/- nginx, но, правда, по набору функций он победнее будет.
Если у тебя httpd работает бэкэндом, то его роскошное api можно использовать для написания приложений на c/c++ и это будет работать очень быстро, но.... есть различные либы, которые умеют в fcgi/http и мультиплексирование и на основе этого можно сделать отличное приложение и в таком случае апач нам не понадобится.
А с момента появления uwsgi-2.0.9 и nginx-unit апачовый passenger для рубей тоже отошёл в историю (в своё время это был единственный по-настоящему продовый в смысле предсказуемости поведения и производительности способ завести рубёвое приложение, но сейчас пассажир уходит в закат).
В итоге, конечно, можно задействовать апач на проде и он будет работать и работать относительно быстро и надёжно. Но это непрактично, так как операционные расходы на поддержку апача как правило (но не всегда) выше, чем у того же nginx-а.
> Поэтому все эти неосиляторы орут, что он медленный, дырявый итд и срочно надо на nginx.Медленный он при стоковой настройке динамики через mod_* и при работе со статикой (тут его даже IIS уделывает), дырявый он бывал неприлично часто при использовании mod_rewrite совместно с mod_proxy. Голый apache к которому прикручен fpm без одновременных rewrite и proxy использовать можно, затюнив под конкретную соплекуху, не понятно только зачем так мучать попy.
> Собственно, если у тебя апач работает фронтом, кэширует или раздаёт статику и проксирует запросы в бэкэнд... то по скорости он +/- nginx, но, правда, по набору функций он победнее будет.
Ну а это просто милота! Я бы еще понял, если apache там бы компоновал бы соплекухи через SSI, у nginx оно чуть-чуть отличается, придётся переписывать... но нет, перечислены самые слабые функции apache, которые не просто "+/- по скорости", они и у nginx в зависимости от того что там за сайт/приложение могут быть отвратительные по производительности и функционалу.
Если уж сравнивать reverse proxy в стиле старое vs новое, то привычно видеть HAproxy vs nginx. Apache в этой связи упоминают только аналитики с опеннета.Вам для образования. Если у вас есть разношёрстное высоконагруженное вебприложение на Linux, я бы вам рекомендовал не использовать nginx в режиме reverse proxy, пожалуй, никогда. Если же всё таки он нравится, то nginx придётся купить. Тот функционал, который обычно нужен крупному фронтенду у nginx платный.
Например, мониторинг (платно). У него нету вменяемого ACL с разным замедлением запросов в рамках очередей, то что есть слабое. Нету функционала TPROXY (платно), то что прокинет tcp коннект, но при этом сможет его терминировать на себе и применить ACL. У HAproxy тоже есть слабые места, но они специфические и им сложно придумать юскейс. Например, последняя версия HAproxy, которую я разворачивал в боевую всё еще не умела собрать несколько фронтендов в SNI, если все бэкенды всех фронтондов тоже используют SNI без использования промежуточных проксисерверов или без применения SSL Offloading, но, опять же, эту задачу можно и нужно решать иначе. По кэшу nginx проиграет вручную написанному конфигу Varnish под конкретное приложение.> Если у тебя httpd работает бэкэндом...
Вот его и используют на бекендах для запуска корпоративного легаси барахла, написанного как раз под его апи. Также его любят старые жадные хостеры. Писать под него что-то, тем более на сиси+ - это анекдот уровня аналитиков опеннета.
В общем идите со своим обслюнявливанием апача знаете куда... Кстати об этом, youporn apache не использует:
https://www.haproxy.org/they-use-it.html Они используют связку HAproxy+Varnish+nginx. При добавлении keepalived/ldirectord чисто для High Availability самого фронтенда получается решение, которое хватит всем тем кому не лень разбираться настраивать ради производительности и кто "умеет готовить".
> ... Apache. Стабильно, быстро, безопасно.:s/быстро/медленно, прожорливо/
А я использую где-то Apache, где-то lighttpd, на стареньком дохлом ноуте для дачи - cherokee, но чаще всего они стоят за nginx'ом.
Везде использую nginx, даже на стареньком ноуте на даче. Он стоит сам по себе и за nginx не прячется :-D
В nginx завезли проверку симлинков? Ась? Нет?..
Ну дык и не рассказывай сказки о его универсальности.
Апач не умрет. Если nginx допилят до функциональности апача, то получится еще один апач ;)
Где я говорил про смерть индейца? Ты там боярки перебрал что ли?
Просто индеец не нужен. Ты выдумываешь оправдания для использования этого монстра, а я его нажрался еще во времена 1.3 и с меня хватит, больше никогда.
А что за симлинки и зачем оно нужно? Можно пример
ищи symlink и hardlink
прошлый аноним некомпетентен, как и ты
Спасибо кэп, но вопрос в том, что не так у nginx с проверкой symlinks. Есть disable_symlinks if_not_owner.
А можно вкратце, что там не так с симлинками? (ну или что загуглить, а то поиск выдаёт или чушь то, что исправили ещё в 12-м году).
> В nginx завезли проверку симлинков? Ась? Нет?..Да, именно это останавливает победное шествие nginx на все сервера планеты :-)
напоминает багу ~20 летней давности в iis на оффтопик-ntразрабов нестрёма на лесоповал
да! Шикарная была тема! пидиси с открытой на нем же шарой и поднятым ииэсом... Мммм... )))Как говорится - был рад любому гостю и готов был отдаться ему немедленно!
Его доля составляет 0%, опасности подверглись 0 пользователей по всему миру. Ужас и кошмар!
Чужой который раз взял верх.
Да.
Я-то думал, что за дежа-вю? Вспомнил, спасибо.
нет, он там затаился... пока затаился...
> nhttpd is a simple, fast and secure HTTP server
> secure
> В http-сервере Nostromo (nhttpd) выявлена уязвимость
> secureОрнул
Что это за треш? Его даже в дебиановских репах нет.
В портах опёнка зато есть http://ports.su/www/nostromo
Назгул какой-то писал, судя по WWW
>nostromo-1.9.6 – simple, fast and secure HTTP server
>secure
openlitespeed рулит