|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alex Korchmar 2:5020/400 17 May 2006 10:07:03
To : Andrew Dolgov
Subject : Re: ftp charset
--------------------------------------------------------------------------------
Andrew Dolgov <Andrew.Dolgov@p1.f1022.n5030.z2.fidonet.org> wrote:
AD>>> что мешает _раздавать_ дерьмо по http?
AK>> необходимость установки сложного и труднонастраиваемого предмета под
AK>> названием "http сервер".
AD> ой и чем же это http сервер принципиально сложнее ftp сервера?
достаточно, на мой взгляд, сравнить количество параметров конфигуры у
апача и у пусть мега-навороченного proftpd. Размеры и степень внятности
конфигов тоже несколько отличаются.
Протокол, собственно, тоже сложнее на порядок, при этом для передачи файлов
изначально вовсе не заточен.
AK>> (кстати, работа с русскими именами файлов в котором - отдельная пестня)
AD> зато решается средствами протокола. в отличие от ftp, который о кодировках
AD> ничего не знает.
так ведь криво решается-то. (средствами...далее по тексту).
http://www.kayakschool.msk.ru/zvv/%eb%c5%cc%c1%d3%d5%d2%c9.jpg
- это вот исключительно "средствами". (по некоторым причинам
морально-этического характера переименовывать нельзя)
русский апач c RecodeFilenames - это уже не средства, а подпорка довольно таки
кривая. Причем в обратную сторону все равно перекодировать надо самостоятельно.
AK>> разьве http-сервера так тривиальны по безопасности?
AD> за апачем нет такой истории бесконечных, уходящих в десятилетия,
AD> remote root дырищ. которые есть по моему за всеми фтп серверами,
ему и лет поменьше будет. Дыр, тем не менее, было. И dos'ов тоже было и есть.
AD> разве что за исключением vsftpd.
неуловимый джо никому нах не сдался? Мне не нравится vsftpd. Я не очень верю,
что он bullet-proof. Файлообменник на нем, замечу, довольно геморроен - в виду
малофункциональности сервера.
wu-ftpd с -DPARANOID тоже достаточно безопасен (по-моему кроме syslog() в нем
за семь лет не было проблем), но задачу создания файлообменника он не решает.
Как и publicfile (в этом вот может и правда нет дыр, ну так и к употреблению
он, как и все поделки автора, непригоден)
AD> опять проблемы с логикой. свой нефигово прохаканный ftpd
AD> сравниваем с неким apache из коробки.
1. похакал не я. Похакал преимущественно DerMouse в 95-м году,
результаты исследования вполне себе public. Я просто собрал в кучу
чужие патчи методом избирательной селекции.
2. апач у меня тоже мягко говоря не из коробки.
При этом он таки ненадежнее и сложнее чем ненадежный и сложный
ftp-сервер 92-го года издания. (начнем с защиты от DoS атак)
AD> apache, кстати, тоже сервер с весьма нетривиальной
AD> функциональностью. большую часть которой можно нахрен отключить при
AD> ненадобности. а остальное поломать... ну в общем, вперед с песней.
угу. только я на такой подвиг не способен.
AK>> проблем с безопасностью практически не имеет,
AD> это пока тебе не устроят remote root ты такое говоришь.
за десять лет почему-то не устроили.
AD> за тебя поручится тот процент серверов, на которых в интернете работает
AD> апач. это у нас на фрюниксах интересно сколько получится, процентов 90?
ну да. Пять-шесть писем в день "сервер в вашей йопаной сети шлет
спам/пытается нас поиметь/уже поимел" от роботов и не очень. Под жалобные
вопли ламеров "нас самих поломали, не отключайте, очень-очень-важный-сервер,
да, как только админ выйдет из запоя переставим систему, только еще день
простоять и ночь продержаться!"
Да, виноват не апач по преимуществу, а кривые скрипты (только вот
файлообмен без аналогично кривых скриптов тоже невозможен). Хотя
remote root в нем самом было на моей памяти как минимум два и червяк
тоже был.
Серверов поломанных через ftp я что-то не припоминаю.
AK>>>> С удовольствием возьму что-то другое, но где? (наколеночные ифолдеры не
AK>>>> предлагать - это дорогое в плане обслуживания решение)
AD>>> www.apache.org, еще как вариант DAV.
AK>> и ты считаешь это решение a) общедоступным
AD> уж никак не менее общедоступно чем ftp.
давай задумаемся над тем, как этим средством сделать нечто подобное типичному
сценарию использования anonymous ftp. (любому из типичных).
Держа в уме, что второе мы получаем в общем-то в комплекте любой вменяемой
системы, настройки часто можно свести к chmod ~ftp/incoming (или rmdir)
AK>> b) более простым
AD> <Location /blah>
AD> Dav on
AD> </Location>
опять таки - а дальше? Любой типичный файлообменниковый сценарий, плиз.
(всем можно все - нетипичен. Поскольку нетипичны бездонные каналы,
бездонные диски и bullet-proof хостер плюющий на склад детской
порнографии и контрафактной аудиопродукции, автоматом образующийся
на таком сервере через неделю.)
AK>> и безопасным нежели ftp-сервер?
AD> ну, идешь на багтрак и сравниваешь количество дыр в своем dav
AD> сервере и ftpd за выбранный промежуток времени. сильно подозреваю
AD> что в ftpd дыр будет больше.
ну, будет нечем заняться, сравню. Куда отнесем дыру вида "пришел сканер/
многопоточная говнокачалка и уложил сервер (не демона, а сервер)", кстати?
(иными словами - почему на проекте "места хватит" используется не
апач а меганавороченная система с самописными кусками, регулярно
вызывающая недовольство пользователей? Замечу, что у конкурентов тоже далеко
не апач с dav.)
AK>> c) более удобным в обслуживании чем оный же?
AD> да еще как. никакой бесконечной фигни с портами во все стороны, какими-то
AD> идиотскими костылями вроде conntrack_ftp, дебелыми активными и пассивными
идиотские костыли придуманы в общем-то из-за идиотов, не умеющих настроить
файрвол. Используй active ftp only, и тебе не будут нужны костыли.
С другой стороны - conntrack_ftp давно написан и работает (по преимуществу).
так что эту проблему за тебя давным-давно решили. apache maintenance совсем
другая затея.
> Alex
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
