Сформирован (https://www.lighttpd.net/2016/10/16/1.4.42/) релиз легковесного http-сервера lighttpd 1.4.42 (http://www.lighttpd.net). В новой версии:
- Переписан фреймворк аутентификации (mod_auth), обновлён модуль аутентификации в LDAP (mod_authn_ldap) и представлены новые модули для аутентификации через GSS API (mod_authn_gssapi) и MySQL (mod_authn_mysql). - В состав также включены новые модули mod_deflate, mod_geoip и mod_uploadprogress. - В mod_fastcgi добавлена поддержка авторизатора.- В mod_cgi реализована возможность запуска скриптов CGI, недоступных на чтение и обеспечен экспорт переменных окружения SSL_* для скриптов. - В mod_scgi добавлена поддержка протокола UWSGI для WSGI-бэкендов на языке Python.URL: http://blog.lighttpd.net/articles/2016/10/16/lighttpd-1.4.42.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=45328
Не сочтите за троллинг, но кто и зачем им пользуется?
Есть же nginx. Настройка по сложности у них одинаковая.
Для CGI не подходит nginx, например
ну, тут приходится выбирать: или 10k соединений, или cgi. nginx под первое создавался.
Ну у лайти с 10К соединений как-то тоже проблем нет. С этой целью и писался, собственно.
10к соединений с cgi? ну-ну
> 10к соединений с cgi? ну-нуГде-то в моём ответе написано «cgi»?
В смысле не подходит? Кто fcgiwrap отменил?
нам нужно выдерживать от до 500 в минуту, fcgiwrap - в этом месте начал загибаться.
> нам нужно выдерживать от до 500 в минуту, fcgiwrap - в этом месте начал загибаться.Запустите fcgiwrap ещё на одном сервере и с помощью nginx балансируйте нагрузку на эти два (три, четыре и т.д. по вкусу) сервера.
Можно ещё код вашего приложения оптимизировать.
Кому нужен nginx, когда есть старый добрый lighttpd?
> Кому нужен nginx, когда есть старый добрый lighttpd?ну, его похоронили, ветку 2.0 отменили, ветку 1.5 отменили, ветку 1.4 забросили, код из svn не собирался и никого это не интересовало
в таких условиях люди и начали переползать на nginx. потом, через несколько лет lighttpd ожил, но было уже поздно
Между тем ветка 1.4 работала, работает и будет продолжать работать. Кто там что отменял и забрасывал - как-то даже не особо волнует.
в определённый момент проект стал производить впечатление всеобщей запущенностипотом ожил, но было уже поздно
даже яндекс, который сам вёл собственную ветку lighttpd 1.5 - смотрю, плюнул на всё это, и теперь использует nginx :)
какая нафиг запущенность?! у вас что-то перестало работать на проде или что?
> какая нафиг запущенность?! у вас что-то перестало работать на проде или что?мдя, тяжёлый случай. такие, как вы, я полагаю, и титаник потопили
1. автор говорит *мы ща перепишем всё с нуля, и забабахаем 2.0*
2. автор говорит *чёт не переписывается, а ну его нафиг*
3. коммитов в свн нет, текущий код не собирается. понятия о том, что там с безопасностью - непонятно
4. новая версия с обновлениями/исправлениями не выходит практически год
5. nginx активно развивается, чинится, интерес к нему в среде разработчиков огромный. а на lighttpd пофиг даже его разработчикам
в такой ситуации самое дебильное, что можно сделать - это держаться за lighttpd, потому что *а что, что-то перестало работать*? у тебя, что, Debian 2.2 potato перестал работать? почему ты его не используешь?
А вот это, как раз и есть троллинг.
>> Не сочтите за троллинг, но кто и зачем им пользуется?..Не сочтите за троллинг, но кто и зачем пользуется Тоётой РАВ4???
Есть же Нисан Кстрейл???Зачем ваще нахерачили столько разных авто??? 2106 — ездит, чё ещё надо???
Зачем Форд? Зачем Саньё???
Потому-что 2106 кусок непонятно чего без правого зеркала, с ущербной подвеской, отсуствием шумки, карбюратором (добавь еще over500 косяков)?
> 2106 — ездит, чё ещё надо???2106 — кривой форк. Не надо тут вот это вот.
В конфигах можно писать скрипты на JavaScript как под nginx?
Слава ктулху, Нет!
Не славь меня без нужды!
Лучше переходи на JavaScript!
Ты избавишься от одного массивного и потребляющего целую уйму глюкозы и кислорода, я полакомлюсь свежатинкой, все довольны, всем хорошо!
>меняСпи давай, фтагн...
Конфиги могут инклюдить запуск любых программ (на практике это наверняка будут шелл/перл/питон/пхп-скрипты), которые должны генерить корректный фрагмент конфига lighttpd, который в свою очередь и вставляется в место инклюда. И вот возможности с этим открываются почти безграничные.Ну и у самих конфигов есть некоторый простенький синтаксис с блоками if, регекспами, переменными, etc.
> И вот возможности с этим открываются почти безграничные.Зачем нам такая полнота по Тьюрингу, если это всего-лишь конфиги? Это просто рай для "индусов", который потом разгребать и отлаживать.
В самих конфигах синтаксис ограниченый, такой полноты нет.
Инклюдами внешних скриптов пользоваться никто не заставляет.
Но мне например было удобно сделать автогенерацию почти всего конфига на лету, в зависимости от того что за хост, какие на нём сайты прямоздесь а какие надо реверс-проксировать, что у нас с HTTPS, ACL и прочими вещами. Таким образом конфиг на всех хостах один и тот же, но при этом ручные движения сведены к минимуму при миграции даже "сложных" сервисов между хостами, максимум нужен релоад веб-серверу.
а что хуже, питон или жабаскрипт?
> а что хуже, питон или жабаскрипт?Это сравнение очень хорошо описывает аксиома Эскобара.
> а что хуже, питон или жабаскрипт?Оба хуже. :)
Lua, если сильно надо.
А что там с 2.0? Как думаете, когда-нибудь его закончат?
> А что там с 2.0? Как думаете, когда-нибудь его закончат?пока определенной дорожной карты по версии 2.0 нет, разработка в этой ветке почти мало двигается. пока не будет большой интерес со стороны пользователей, версия 2.0 будет растянута на долго.
разработка и поддержка в основном ведется в основной ветке 1.4.*
nginx и php не умеет обрабатывать, и это лочично, nginx - web сервер, его задача в другом, а для php есть php-fpm, для cgi - fastcgi или uwsgi, которые прекрасно работают с nginx.
PHP вещь узкоспецефичная, а CGI - стандарт. На самом деле совсем не сложно обрабатывать пул CGI-процессов в nginx eventloop. Просто у Сысоева принципы. Ну и идет он на со своими принципами. Благо есть альтернативы. Тот же сабжCGI во многих случаях достаточен. И в некоторых случаях более разумен чем FASTCGI. Не всегда оправдано запускать FCGI-сервис ради простых действий типа смены IP или перезагрузки машины
Что же касается сабжа, при всех его недостатках, у него масса достоинств. Например он модульный. И не такой монструозный. Из недостатков сабжа: мне бы пригодилась тонкая настройка буферов и таймингов, websockets-proxy, и чтение тела POST во встроенном lua-обработчике
>На самом деле совсем не сложно обрабатывать пул CGI-процессов в nginx eventloop.И потерять возможность лимитировать это безобразие.
> Просто у Сысоева принципы.На самом деле штаны через голову тоже можно одеть, но одевают зачем-то через ноги.
Принципы видимо.> Например он модульный.
можно подумать ngnix не модульный ?
> И не такой монструозный.
Не осилил? так и скажи.
>>На самом деле совсем не сложно обрабатывать пул CGI-процессов в nginx eventloop.
> И потерять возможность лимитировать это безобразие.
>> Просто у Сысоева принципы.
> На самом деле штаны через голову тоже можно одеть, но одевают зачем-то
> через ноги.
> Принципы видимо.
>> Например он модульный.
> можно подумать ngnix не модульный ?
>> И не такой монструозный.
> Не осилил? так и скажи."На самом деле штаны через голову тоже можно одеть"
На самом деле штаны через голову надеть нельзя.
Видимо у предыдущего анонима они порваны.
> "На самом деле штаны через голову тоже можно одеть"
> На самом деле штаны через голову надеть нельзя.Зависит от местоположения ширинки.
> На самом деле совсем не сложно обрабатывать пул CGI-процессов в nginx eventloopкак показал mpm_event в apache 2.4 -- сделать это так, чтобы оно работало хорошо и стабильно, не столь просто как кажется. я видел в действии связку mpm_event + mod_wsgi, которая работает именно так и, пока она была жива, клиенты раз в сутки нажимали кнопочку "перезапустить apache, а то он завис". у passenger для nginx тоже были аналогичные проблемы, но менее выраженные.
я уже не помню, какие неразрешимые проблемы, кроме непоняток с будущим проекта, перевели меня с lighttpd на nginx. хотел даже обратно переметнуться, ибо если в owncloud 8 в openbsd в pkg_readme был кусок конфига *вставь и юзай*, то в девятом - ссылка на сайт... а я как-то ставил его вообще без интернета под рукой, а когда добрёл до интернета, то узнал, что оно бы мне вообще не помогло, потому что там простыня на два экрана, которые нужно адаптировать для openbsd-шных дефолтовв общем, в лучших чувствах я пошёл на сайт owncloud, чтобы поглядеть конфиг, и узрел:
Lighttpd is not supported with ownCloud, and some ownCloud features may not work at all on Lighttpd.
https://doc.owncloud.org/server/9.0/admin_manual/issues/gene...
обидно
да всё там работало на сабже в 7 и в 8.2 и 9 (и nextcloud 10), а вещи что в 8ых версиях до 8.2 в вебдав глючили - глючили и в nginx потому что виноват был код на php и немного клиент.
"не поддерживается" - значит кто то у них решил что ему вподляк заниматься тестированием и разбором проблем, или освоением синтаксиса конфига, возможно потому что не самый популярный, а не потому что плохой/кривой/убогий и написал втихаря отмазку, мол без гарантий.на память, в конфиге ничего экстрацспецифического и не требуется кроме в сам деле как:
Disable access to data folder:
$HTTP["url"] =~ "^/owncloud/data/" {
url.access-deny = ("")
}Disable directory listing:
$HTTP["url"] =~ "^/owncloud($|/)" {
dir-listing.activate = "disable"
}как сказано в доке к 7-ке
https://doc.owncloud.org/server/7.0/admin_manual/installatio...
ага, только там не много ниже "Recent versions of ownCloud make use of the HTTP PATCH feature, which was added to Lighttpd at version 1.4.32 while Debian stable only ships 1.4.31. The patch is simple, however, and easy to integrate if you’re willing to build your own package. Download the patch from ..."
не, ну может это кому-то и инетерсно патчи переписывать под новые версии lighttpd :(
ЗЫ. сам до последнего сидел до последнего lighttpd 1.4.41 и надеялся на чудо.
как пришла новая комманда - начилась свистопляска: начиная с lighttpd 1.4.31 они одно чинят, другое отваливается. последний прикол был всязан вебдавом, когда lighttpd сжирал всю память и свап, и было всем весело (через клиенты всё ништяк, а вот когда монтируешь как диск в систему, тут начинаются приколы).
расскажи что у тебя сломалось в [own|next]cloud] без HTTP PATCH feature на lighttpd ?
по хорошему вообще ничего не работает, пробывал и на 36 и на 38 и на 40, без патча собирал. аяксЕксплорер норм работает, ваще без проблем, но меня парят некоторые адские тормоза, ну то есть ворочеттся еле еле, особенно в админке, генерация линка шары - ооочень долго происходит.
owncloud - показывает содержимое рабочего каталога, но залить через вебб интерфейс или расшарить - невозможно.
поддержка PATCH добавлена в 2012 ещё,
1.4.32 на фряхе в портах с 2013года
в теперешнем stable Debian 8 всё давно уже есть.
недоволен консерватизмом 7 дебиан ? убунту в помощь - в 14.04LTS тоже есть (1.4.33)
> поддержка PATCH добавлена в 2012 ещё,
> 1.4.32 на фряхе в портах с 2013года
> в теперешнем stable Debian 8 всё давно уже есть.
> недоволен консерватизмом 7 дебиан ? убунту в помощь - в 14.04LTS тоже
> есть (1.4.33)до фряхи пока руки не дошли, развлекаюсь с слакваре. с 32 ушол - были какие -то глючные приколы с ним. да и очень хотелось http2 попробывать...
> В mod_cgi реализована возможность запуска скриптов CGI, недоступных на чтениеэто как?
Это значит, что бит-чтение снят (rw-)
> Это значит, что бит-чтение снят (rw-)Ну кто ж так умничает?
Надо так: (--x--x--x)
Всем бы хорош Lighty, но есть у него один серьезный косячище. Когда используешь его в качестве reverse proxy, ему пох, что клиент уже закрыл соединение, он удерживает соединение с внутренним сервисом бесконечно. В итоге рост количества этой туевой хучи конешно останавливается, только Lighty ведет себя как при DDoS.
Как бы я его не любил за простоту и скорость, ентот косяк заставил перейти на nginx.
а вообще, самый клёвый из серверов лёгкого класса - это OpenBSD httpd
А в арч можно поставить?
А оно кастомные хедеры умеет добавлять а-ля setenv.add-response-header в Lighty и OCSP?
оно дохрена чего не умеет. поэтому и легковесное и код мизерный :) но для своих целей - лучше не придумаешь
> А оно кастомные хедеры умеет добавлять а-ля setenv.add-response-header в Lighty и OCSP?в общем, вот
http://man.openbsd.org/httpd.conf.5
всё, что умеет - всё в мане есть
Посмотрел чуть раньше. На замену Lighty не тянет пока никак.