А я вот сейчас исправлю все втихаря, и все будут над вами смеяться. На самом деле это я с горяча подумал, что так — легче прочитать правильно «ЭнДжинкс», а не «нгинкс» или «энджинекс», как я слышал в разговорной речи. На самом деле пожалуй надо исправить и пусть каждый сам за себя. А кроме литературных замечаний/вопросов? Сам не свой до конструктивных пистонов в комментариях.
Для таких комментариев у автора найдется жена, а все эти советы из разряда «если бы у меня была твоя голова, я бы» — они не состоятельны. Обычно таких, как хватают владельцы маленьких производств и они делают вот такие штуки. Надо просто помочь сдать автора поста в добровольное высокооплачиваемое рабство.
Недорогие системы для аудиофилов? Недорогие покупают люди не искушенные, а Hi-End — не так просто продать, потому что творцы и продавцы — это две большие разницы.
ссылки в топиках-переводах — после иконок шаринга в социалка и до имени автора статьи/перевода. В нашем случае это ссылка на автора Vivek Gite. Это для данной статьи. В конце статьи-оригинала на cyberciti.biz такое же меню навигации по частям. Чего, тоже по русски ни фига не понимаете? Понимаю. Однажды установил с дуру русский фотошоп и заплакал.
Запретить .htaccess в папках? На сколько и зачем? All, None, AuthConfig, FileInfo, Indexes, Limit, Options?
А вот на счет Options Indexes — нужно не лениться класть во все папки index-файлы. Хотя, Options Indexes можно переопределить в .htaccess. По какой-то причине, обычно, хостинги этого не делают. Хотя, вот именно во втором случае я с вами соглашусь.
Смотрите, я часто встречаю выражение о NAS «double the cost for half the performance» в сравнении с DAS. Но в нашем конкретном примере конфигурации это не чистый NAS, а пара-NAS, т.к. речь идет не то что об одной шине, а о физически том же диске. Неужели такие потери связаны с сетевым протоколом, что в 2-3 раза падает производительность? Даже если исключить кеширование файлов в память на этом embeded-NAS, откуда такой пессимизм?
Ну, допустим вы уже «трогали» живые цифры. Представьте себе новостной сайт, где чуть ли не 95% трафика приходится на главную страницу, а архив материалов — за десять лет. Условно нарисую число запросов к файлам и материалам по годам:
Ну и вот нафига мне в DAS нужны 90% файлов на которые приходится 2-4% всех просмотров? По хорошему, выпнуть бы это все в облака за те же деньги, что стоит поставить еще один диск архива. Не говоря уже о еженедельном бэкапе длинной в 8 часов (не я настраивал).
Я пытаюсь найти за вас аргументацию «против» этого решения, но может быть я изначально не верно понимаю ваш посыл? Вы подкинете какую-нибудь пищу для размышления, что бы мой гипотетический отказ я мог сопроводить умным взглядом и цифрами.
По поводу падения производительности: думаю если речь идет о чем-то серьезном (напомню, что у нас самый недорогой веб-сервер у хецнера с 200k посетителями и трафиком в 350Gb ежемесячно), то уж не столь ощутимо падение в производительности чтения файлов. Запись/удаление — надо смотреть на реальных задачах. Но вы говорите, что это вторично, так что же первично?
1. Если не скомпрометирован сервер приложения, то маловероятно, что мы дадим ломиться на машину с БД человеку извне. Если наше приложение — «говно дыряво», то пиши-пропало, на каком бы оно порту не весело. Либо делать пользователя БД «SELECT-only» с репликацией из сторонней админской базы. Ну это вообще я от балды сейчас говорю, так как не вижу вариантов защиты.
2. Не представляю организации подобного в рамках классических open-source движков CMS. Или же это получится бредовариант из пункта №1 с зеркалированием «тайного сервера из бункера гитлера».
3. Интересное замечание. Надо думать, как это провернуть с «динамическими разработчиками».
4. Мне уже страшно подумать о том, какой оверхед и latency обретет такая система. А какие-то best-practics на эту тему есть почитать?
Вы только не прощайтесь, разговор-то какой получился положительный. ;) А то я уже на шизофреника стал похож, рассуждая сам с собой, как можно это все поломать и защитить. «Сам себе пентест». ))
Цитирую одного пользователя, очень он из интернета похож на приличного администратора, я потревожил его вопросом о качестве «построяемой» авторами туториала системы:
«В статье фигня какая то, ну скомпроментировал я ваш сервер с исходниками сайта и апачем, ну посмотрел я пароли к mysql и кешу, ну написал простой скрипт и сделал дамп все себе на почту, какой-то защиты я там не вижу.
Разделение на виртуальные машины хороший прием, так как позволяет распределять нагрузку, и более четко контролировать сервисы, а защитой от компрометации это не является, хотя и является шагом для её реализации. А вообще сложные пароли, хороший код, обновление по и защита по ip довольно хорошо защищают».
Первый шаг. Хорошо, что не «последнее дело». Значит нужно искать второй шаг. 8) Хорошим топиком считаю те, где есть хорошие комментарии. Так что затея уже удалась и спасибо за участие, 0Lexx0.
Запрещаем использование .htaccess во всех папках.
Разрешаем его использование в /var/www/html/ и ниже
А вот на счет Options Indexes — нужно не лениться класть во все папки index-файлы. Хотя, Options Indexes можно переопределить в .htaccess. По какой-то причине, обычно, хостинги этого не делают. Хотя, вот именно во втором случае я с вами соглашусь.
— Пасаны, пишем «Options -Indexes».
Ну, допустим вы уже «трогали» живые цифры. Представьте себе новостной сайт, где чуть ли не 95% трафика приходится на главную страницу, а архив материалов — за десять лет. Условно нарисую число запросов к файлам и материалам по годам:
Ну и вот нафига мне в DAS нужны 90% файлов на которые приходится 2-4% всех просмотров? По хорошему, выпнуть бы это все в облака за те же деньги, что стоит поставить еще один диск архива. Не говоря уже о еженедельном бэкапе длинной в 8 часов (не я настраивал).
Это исследование за 2008 мохнатый год.
А вот тут вас обозвали малазийцем. ;)
storagegaga.com/tag/nfsv4/
Я пытаюсь найти за вас аргументацию «против» этого решения, но может быть я изначально не верно понимаю ваш посыл? Вы подкинете какую-нибудь пищу для размышления, что бы мой гипотетический отказ я мог сопроводить умным взглядом и цифрами.
По поводу падения производительности: думаю если речь идет о чем-то серьезном (напомню, что у нас самый недорогой веб-сервер у хецнера с 200k посетителями и трафиком в 350Gb ежемесячно), то уж не столь ощутимо падение в производительности чтения файлов. Запись/удаление — надо смотреть на реальных задачах. Но вы говорите, что это вторично, так что же первично?
www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-nfs.html#s1-nfs-how
2. Не представляю организации подобного в рамках классических open-source движков CMS. Или же это получится бредовариант из пункта №1 с зеркалированием «тайного сервера из бункера гитлера».
3. Интересное замечание. Надо думать, как это провернуть с «динамическими разработчиками».
4. Мне уже страшно подумать о том, какой оверхед и latency обретет такая система. А какие-то best-practics на эту тему есть почитать?
Вы только не прощайтесь, разговор-то какой получился положительный. ;) А то я уже на шизофреника стал похож, рассуждая сам с собой, как можно это все поломать и защитить. «Сам себе пентест». ))
Цитирую одного пользователя, очень он из интернета похож на приличного администратора, я потревожил его вопросом о качестве «построяемой» авторами туториала системы:
«В статье фигня какая то, ну скомпроментировал я ваш сервер с исходниками сайта и апачем, ну посмотрел я пароли к mysql и кешу, ну написал простой скрипт и сделал дамп все себе на почту, какой-то защиты я там не вижу.
Разделение на виртуальные машины хороший прием, так как позволяет распределять нагрузку, и более четко контролировать сервисы, а защитой от компрометации это не является, хотя и является шагом для её реализации. А вообще сложные пароли, хороший код, обновление по и защита по ip довольно хорошо защищают».
Первый шаг. Хорошо, что не «последнее дело». Значит нужно искать второй шаг. 8) Хорошим топиком считаю те, где есть хорошие комментарии. Так что затея уже удалась и спасибо за участие, 0Lexx0.
syslog-ng+MySQL+Net Source
отказоустойчивый веб-сервис
сервер дома