Спустя 6 месяцев после выхода версии 1.4.19, анонсирован (http://www.lighttpd.net/2008/9/30/1-4-20-Otherwise-the-terro...) новый релиз - lighttpd 1.4.20. В новом релизе устранено около 60 ошибок, в том числе исправлено 4 уязвимости. Отдельно можно отметить обновление кода spawn-fcgi и изменение метода использования экранированных в URL символов в правилах модулей mod_rewrite и mod_redirect (отныне перед проверкой данные декодируются).
Исправленные уязвимости:- Из-за утечки памяти в функции "http_request_parse()", злоумышленник может (http://www.lighttpd.net/security/lighttpd_sa_2008_07.txt), наводнив сервер определенными запросами, исчерпать всю доступную в системе память, если объем выделяемой lighttpd памяти не лимитирован;
- Уязвимость (http://www.lighttpd.net/security/lighttpd_sa_2008_04.txt), позволяющая злоумышленнику удаленно оборвать активные SSL соединения;
- Отсутствие (http://www.lighttpd.net/security/lighttpd_sa_2008_06.txt) в mod_userdir прин...
URL: http://www.opennet.me/opennews/art.shtml?num=18163
Новость: http://www.opennet.me/opennews/art.shtml?num=18163
finally \o/
О, наконец то!P.S. что-то дыры не особо страшные какие-то.
А ты рад или опечален? Не понятно :)Хорошо что пофиксили. Я много где юзаю как фронт для всяких индейцев, джанг и пр. тяжести.
... хм - прикинул что уже чаще юзаю нжЫнкса :)
Но всё равно - лайти - хороший сервак!
>А ты рад или опечален? Не понятно :)Лично я - рад, хорошо когда хорошие проекты развиваются.
>Хорошо что пофиксили. Я много где юзаю как фронт для всяких индейцев,
>джанг и пр. тяжести.У меня в некоторых местах лайт без всяких индейцев через fastcgi или scgi работает (некритичные к нагрузке штуки могут и через CGI, но CGI - старый, тормозной и дурацкий на фоне fastcgi, строго говоря).Вроде нормально вполне.Ресурсов дофига не жрет, etc.
>... хм - прикинул что уже чаще юзаю нжЫнкса :)
Формат конфига у него зубодробильный малость, но в целом - тоже неплохой сервак с кучей интересных фич.Из минусов по сравнению с лайти я пока углядел менее богатый набор понимаемых CGI-протоколов, сразу видно заточеность на несамостоятельное существование (хотя fastcgi оно умеет, но лайти то умеет больше :P).
>Но всё равно - лайти - хороший сервак!
+1.Особенно весело читать на сайте апача гайд по оптимизации производительности.Мля, так и хочется добавить к этому гайду: "а если юзать лайт или нжинкс то греть мозг этим вопросом равно как и потреблением ресурсов просто не придется" ;)
вчера только читал письмо от рук. отдела нагр тестирования,
что apache2+mod_php показал производительностьб для одного сервиса
на 25% большую чем nginx+spawn_fast-cgi
так что красноглазая песня про nginx это спорно...>хочется добавить к этому гайду: "а если юзать лайт или нжинкс
>то греть мозг этим вопросом равно как и потреблением ресурсов просто
>не придется" ;)
"Вы просто не умеете их готовить.."
>на 25% большую чем nginx+spawn_fast-cgiА случаи бывают разные (с) анекдот.Вы тут ни звука не издали про то что тестировалось, как, на каком хардваре и прочая.В силу такого подхода совершенно фигня вопрос накопать примеров когда все будет как я написал.И таких случаев - есть.
>так что красноглазая песня про nginx это спорно...
Это все зависит от доступного объема ресурсов, характера нагрузки, радиуса кривизны рук и прочая.Без конкретики - вообще неконструктивно.
А вот на подумать: обычно оптимизация скорости работы сводится к устранению узких мест. С тем же нжинксом или лайтом например интенсивный кэшинг результатов работы да того же PHP или кого там еще может свести работу сервака по сути к отдаче статики, в чем лайт и нжинкс традиционно сильны а перегенережка страниц силами PHP (или что там еще) будет требоваться весьма редко, только по факту изменения контента а это намного реже просто отдачи страниц и файлов.Ну и удачи потом неповоротривым апачом лайт или нжинкс уделать.Хотя если взять очень_крутой_сервер (tm) c гигами оперативы на борту и кучей процессоров - даже можно попытаться.Только это не на халяву.А когда условия задачи - в ограниченных ресурсах на имеющемся железе или с использованием виртуализации получить максимум - апач тут ничем таким покозырять зачастую не может.Возможны и иные ситуации, скажем если результат всегда генерится динамически и всегда разный - тут уже надо смотреть, апач может и в плюсе оказаться но даже в этом случае логично поставить перед ним нжинкс проксей и отдавать статику им, потому что на отдаче статики апачу явно не светит уделать лайт и нжинкс кроме каких-то клинических случаев.
В общем как кто-то правильно заметил - вопрос в том кого и как готовить и вообще какие условия задачи.Например мне апача на относительно хилых серверах (виртуализованные окружения а также немолодой хардвар) готовить не понравилось абсолютно: приходится трахаться с проблемами которых у других просто нет как класса.Для начала туева хуча тредов или процессов выжирает всю память или если урезать из число - начинаются тормоза потому что очередной клиент долго ждет пока освободится тред или процесс.При том это как на генережке страниц так и на отдаче статики.
apache2 по своему подобию не сможет отработать более nginx. Так что расскажите об этом Сысоеву и Ко.