Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
А можно узнать URL оригинальной статьи? Прошу прощения, если он где-то указан, но я не заметил.
ссылки в топиках-переводах — после иконок шаринга в социалка и до имени автора статьи/перевода. В нашем случае это ссылка на автора Vivek Gite. Это для данной статьи. В конце статьи-оригинала на cyberciti.biz такое же меню навигации по частям. Чего, тоже по русски ни фига не понимаете? Понимаю. Однажды установил с дуру русский фотошоп и заплакал.
В отдельно взятых случаях я бы еще подстраховал разработчиков и выставил дефолтный content-type как force-download:
Увы не могу ничего сказать на тему стабильности работы подобной схемы на Lighttpd, проверял работоспособность только на nginx. Наши реалии таковы, что зачастую разработчики не умеют и не хотят правильно работать с файлами, обычно от незнания специфики веб-серверов на которых работают/могут работать их разработки, отсюда и получаем что допускаются к загрузке расширения с пробелами в конце (очень частый случай, когда при проверке в какой нить функции IsImage делается trim/rtrim а при сохранении нет) или же загрузка файлов только с расширением (например .jpg — смертельный файл для проекта в связке nginx + клиент на IE), а отдача всей статики кроме разрешенной с force-download их от этого убережет.
[root@localhost conf.d]# cat /etc/lighttpd/conf.d/mime.conf | grep '""'
# "" => "application/octet-stream",
"" => "application/force-download",
Увы не могу ничего сказать на тему стабильности работы подобной схемы на Lighttpd, проверял работоспособность только на nginx. Наши реалии таковы, что зачастую разработчики не умеют и не хотят правильно работать с файлами, обычно от незнания специфики веб-серверов на которых работают/могут работать их разработки, отсюда и получаем что допускаются к загрузке расширения с пробелами в конце (очень частый случай, когда при проверке в какой нить функции IsImage делается trim/rtrim а при сохранении нет) или же загрузка файлов только с расширением (например .jpg — смертельный файл для проекта в связке nginx + клиент на IE), а отдача всей статики кроме разрешенной с force-download их от этого убережет.
да, я тоже не понял в чем сакраментальный смысл ставить lighttpd и прятать его за nginx, если сам nginx замечательно (вероятно что даже лучше) справляется со статическими файлами
Пофигу что там будет стоять, на сколько я понял замысел автора. Дело в сатанинском разграничении доступа к файлам этого vm05 на стороне vm05. И тюнинг этой vm05 будет происходить исключительно на vm05, по этому там стоит исключительно файловый сервис раздачи статики. lighttpd или nginx — пофигу. А верхний nginx — это точка входа для всех хостящихся наших проектов. Такой вот балансировщик сервисов.
Тут сделан большой задел с некоторой избыточностью для дальнейшего горизонтального масштабирования каждого из звеньев цепи.
На сколько я понял ваш вопрос: «нафига нам городить все эти виртулаки?» Исключительно атомарности ради, мониторинга для и дальнейшей секьюризации во имя.
Тут сделан большой задел с некоторой избыточностью для дальнейшего горизонтального масштабирования каждого из звеньев цепи.
На сколько я понял ваш вопрос: «нафига нам городить все эти виртулаки?» Исключительно атомарности ради, мониторинга для и дальнейшей секьюризации во имя.
нет, вопроса «нафига городить виртуалки» у меня не возникает — сами все крутим как раз в виртуалках
вопрос был «нафига использовать lighttpd и изначально закладывать его в архитектуру, если все равно в схеме уже используется nginx который с теми же задачами справляется лучше»? потому что добавление еще одной подобной (подобной тем, которые уже используются) технологии влечет за собой избыточное усложнение системы с точки зрения поддержки.
вопрос был «нафига использовать lighttpd и изначально закладывать его в архитектуру, если все равно в схеме уже используется nginx который с теми же задачами справляется лучше»? потому что добавление еще одной подобной (подобной тем, которые уже используются) технологии влечет за собой избыточное усложнение системы с точки зрения поддержки.
Во первых это перевод how-to, а не must-to. А во вторых, я бы рад был apache заменить на nginx + php-fpm, ну вот теперь представьте себе какой-нибудь 0day-эксплойт или специалиста по опрокидыванию nginx (то что мы с ними не знакомы — не означает, что их нет). И вот он пришел, а у нас — везде один и тот же софт, та же самая его версия. Он ломает верхний сервис, а все нижние — на такой же системе крутятся. А он пришел только ради каких-то файлов на vm05. В нашей схеме он хоть покорчится, какое-то время.
Про несовместимость легкости настройки и безопасности было сказано прежде в цикле этих статей. Смотрите, у г-на «дизайнера всея руси» Тютёмы Л. есть слоган: «Долго. Дорого. О-у-энно». Суть этого слогана в том, что в разработке сайтов есть три кита:
* скорость производства конечного продукта
* стоимость продукта и стоимость владения им
* качество
Суть заключается в том, что из трех китов заказчик может выбрать два. Не бывает быстро дешево и качественно, от чего-то заказчик должен отказаться или пойти на компромисы. Подобная модель, по заявлению российских и западных владельцев серверов, применима и к безопасности — там тоже есть какие-то киты. Я пока не могу их сформулировать, но они — есть. Два из них — легкость администрирования и безопасность. Третий, видимо, снова деньги. Может я и ошибаюсь.
А вы публично про свой проект не рассказывали на хабре? Помнится вы по комментам какой-то PHP-продакшен хаус с облаками и нагрузками. «Слейте», пжалста, в общих чертах, как решили свои задачи в вашей компании, если это не NDA. Если NDA — слейте в личку. ))
Про несовместимость легкости настройки и безопасности было сказано прежде в цикле этих статей. Смотрите, у г-на «дизайнера всея руси» Тютёмы Л. есть слоган: «Долго. Дорого. О-у-энно». Суть этого слогана в том, что в разработке сайтов есть три кита:
* скорость производства конечного продукта
* стоимость продукта и стоимость владения им
* качество
Суть заключается в том, что из трех китов заказчик может выбрать два. Не бывает быстро дешево и качественно, от чего-то заказчик должен отказаться или пойти на компромисы. Подобная модель, по заявлению российских и западных владельцев серверов, применима и к безопасности — там тоже есть какие-то киты. Я пока не могу их сформулировать, но они — есть. Два из них — легкость администрирования и безопасность. Третий, видимо, снова деньги. Может я и ошибаюсь.
А вы публично про свой проект не рассказывали на хабре? Помнится вы по комментам какой-то PHP-продакшен хаус с облаками и нагрузками. «Слейте», пжалста, в общих чертах, как решили свои задачи в вашей компании, если это не NDA. Если NDA — слейте в личку. ))
> И вот он пришел, а у нас — везде один и тот же софт, та же самая его версия. Он ломает верхний сервис, а все нижние — на такой же системе крутятся. А он пришел только ради каких-то файлов на vm05. В нашей схеме он хоть покорчится, какое-то время.
=)
вероятность поймать 0day-эксплойт в двух разных софтах в два раза вероятнее, чем в одном.
ну да ладно, это через шишки само прийдет
к сожалению пока это NDA. вероятно архитектура будет пересмотрена в ближайшее время и тогда можно будет в двух словах поделиться и проблемами и решениями.
PS: для статики сразу делайте отдельную внешнюю точку входа чтобы все обслуживалось с субдомена напрямую. тем более, что полшага для этого уже сделано
=)
вероятность поймать 0day-эксплойт в двух разных софтах в два раза вероятнее, чем в одном.
ну да ладно, это через шишки само прийдет
к сожалению пока это NDA. вероятно архитектура будет пересмотрена в ближайшее время и тогда можно будет в двух словах поделиться и проблемами и решениями.
PS: для статики сразу делайте отдельную внешнюю точку входа чтобы все обслуживалось с субдомена напрямую. тем более, что полшага для этого уже сделано
Слушайте, я тут переводчик или что? 8) Не совсем поняд про внешнюю точку. Всмысле спразу отдельную машину под статику или вы про imX.example.com?
переводчик конечно =)
сразу про static.example.com с отдельным ip. просто раз уж тут архитектура построения серверов тесно переплетается с архитектурой проекта, то лучше сразу закладываться на то, что вся статика живет на отдельном домене: по-началу (до упора в ширину канала) разница будет только в скорости подгрузки файлов браузером (даже если физически машина будет та же, что и балансер), а потом в принципе будет проще унести статику в CDN
а вот проксировать статику user->nginx->сервер-статики->файл ну совсем не комильфо: явно лишнее звено которое будет забивать канал
сразу про static.example.com с отдельным ip. просто раз уж тут архитектура построения серверов тесно переплетается с архитектурой проекта, то лучше сразу закладываться на то, что вся статика живет на отдельном домене: по-началу (до упора в ширину канала) разница будет только в скорости подгрузки файлов браузером (даже если физически машина будет та же, что и балансер), а потом в принципе будет проще унести статику в CDN
а вот проксировать статику user->nginx->сервер-статики->файл ну совсем не комильфо: явно лишнее звено которое будет забивать канал
Я вот об отдельном ip под статику не думал прежде. Мне казалось, что он (браузер) до такого не доходит и только переживал, как бы раскидывать на пару-тройку доменов static(1...×+1).example.com, что бы они продолжали кешироваться. А о переносе части картинок в CDN (у нас новостные ресурсы) полагал исходить из «возраста» файла изображения, т.к. CDN может и разорить.
Канал забивать не будет, это точно. Скорее в дисковую систему упремся, т.к. сейчас и до 7Мб/сек передача не дотягивает при дисковой «предельной» скорости, на сегодняшний день, большей в разы.
Канал забивать не будет, это точно. Скорее в дисковую систему упремся, т.к. сейчас и до 7Мб/сек передача не дотягивает при дисковой «предельной» скорости, на сегодняшний день, большей в разы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 5/6)