Исходное сообщение
"На базе vsftpd создан легковесный HTTP-сервер" Отправлено nuclight, 25-Мрт-10 19:59
>[оверквотинг удален] >>> >>>http://www.google.ru/search?hl=ru&lr=&newwindow=1&client=fir... >>> >>>+ запуск по крону chown не на директорию, а на файлы. Можно >>>и по inotify :) >> >>И чем это проще банального ftp-сервера? > >Это безопаснее :) Ваш типовой админ никогда не почешется, что бы реализовать >схему безопасной, а тут схема изначально безопасна. Безопаснее?! Вы шутите. Схема с меньшим числом компонентов, как правило, будет не только проще, но и надежнее и безопаснее. Вы же предлагаете один компонент, vsftpd, заменить на ЧЕТЫРЕ - апач, интерпретатор PHP, приложение на PHP, самописные костыли админа в кроне и пр. (кто сказал, что он тут не наляпает?). Наглядная иллюстрация: идёте, скажем, на Секунию, и считаете количество дырок за историю продукта - вот у vsftpd только одна, а у одного лишь интерпретатора PHP было более 300 (http://secunia.com/advisories/vendor/24/ и просуммируйте). >>>>Ограничения: файлы(папки) заказчиком не могут быть удалены, не могут быть перезалиты взамен >>>>существующих (поверх). >>> >>>Proftpd уже поддерживает scp, + см. вариант выше. >> >>Опять-таки, Proftpd - это ftp-сервер. > >Уже не совсем :) ftp, как протокол, безнадежно устарел, и прямо сейчас >уже умирает. Вам так только кажется. И даже если в какой-то сфере он уходит, совершенно не повод выкидывать его из остальных. Особенно при предложенной замене на веб-решение с жутко кривым дизайном и таким количеством дыр в реализациях. Сравнение будет в пользу FTP даже с учетом всех его исторических проблем - главные из которых, кстати, говоря, это использование символов Telnet "Interrupt Process" и Telnet "Synch" и неуказание кодировок (что, впрочем, уже давно лечится поддержкой UTF-8 по RFC 2640) плюс отсутствие стандарта на формат листинга каталога - но вовсе не поносимые тут вторичные коннекты. Их любой приличный NAT давно умеет, не говоря уже о том, что "проблема дизайна" здесь вопрос философский - IPv6 никакого NAT не предусматривает, считая именно его проблемой дизайна, а не требование свободного connectivity у протоколов.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>[оверквотинг удален] >>>> >>>>http://www.google.ru/search?hl=ru&lr=&newwindow=1&client=firefox-a&hs=4CK&rls=org.mozilla:en-US:official&ei=-3OoS5DqIdvNjAf8idHfAQ&sa=X&oi=spell&resnum=0&ct=result&cd=1&ved=0CBYQBSgA&q=web+file+manager+permissions&spell=1 >>>> >>>>+ запуск по крону chown не на директорию, а на файлы. Можно >>>>и по inotify :) >>> >>>И чем это проще банального ftp-сервера? >> >>Это безопаснее :) Ваш типовой админ никогда не почешется, что бы реализовать >>схему безопасной, а тут схема изначально безопасна. > Безопаснее?! Вы шутите. Схема с меньшим числом компонентов, как правило, будет не > только проще, но и надежнее и безопаснее. Вы же предлагаете один > компонент, vsftpd, заменить на ЧЕТЫРЕ - апач, интерпретатор PHP, приложение на > PHP, самописные костыли админа в кроне и пр. (кто сказал, что > он тут не наляпает?). Наглядная иллюстрация: идёте, скажем, на Секунию, и > считаете количество дырок за историю продукта - вот у vsftpd только > одна, а у одного лишь интерпретатора PHP было более 300 (http://secunia.com/advisories/vendor/24/ > и просуммируйте). >>>>>Ограничения: файлы(папки) заказчиком не могут быть удалены, не могут быть перезалиты взамен >>>>>существующих (поверх). >>>> >>>>Proftpd уже поддерживает scp, + см. вариант выше. >>> >>>Опять-таки, Proftpd - это ftp-сервер. >> >>Уже не совсем :) ftp, как протокол, безнадежно устарел, и прямо сейчас >>уже умирает. > Вам так только кажется. И даже если в какой-то сфере он уходит, > совершенно не повод выкидывать его из остальных. Особенно при предложенной замене > на веб-решение с жутко кривым дизайном и таким количеством дыр в > реализациях. Сравнение будет в пользу FTP даже с учетом всех его > исторических проблем - главные из которых, кстати, говоря, это использование символов > Telnet "Interrupt Process" и Telnet "Synch" и неуказание кодировок (что, впрочем, > уже давно лечится поддержкой UTF-8 по RFC 2640) плюс отсутствие стандарта > на формат листинга каталога - но вовсе не поносимые тут вторичные > коннекты. Их любой приличный NAT давно умеет, не говоря уже о > том, что "проблема дизайна" здесь вопрос философский - IPv6 никакого NAT > не предусматривает, считая именно его проблемой дизайна, а не требование свободного > connectivity у протоколов.
	Введите код, изображенный на картинке: