Вот меня всегда интересовало, а какой дурень придумал протокол FTP?
Это каким местом нужно было думать, чтобы додуматься до ЭТОГО?
У меня такое ощущение, что изобретатели основных интернет-протоколов (и не только сабжа) думали не головой, а одним местом.
Здравствуйте, quwy, Вы писали:
Q>Вот меня всегда интересовало, а какой дурень придумал протокол FTP?
Так это было в 70-х годах прошлого века. Предполагалось, что им пользоваться будут иногда ручками через терминал. Всё удобнее чем telnet. Он же не думал, что через столько лет найдуться дурни, которые им будут пользоваться, и тем более что будет столько дурней! Автор FTP думал, что мы уже создадим первую колонию на Марсе и освоим управляемый термоядерный синтез к 2010-му году. Вместо этого по фтп к 2012 году уже перекачаны 100500 тысяч экзобайтов всякого хлама.
Здравствуйте, ononim, Вы писали:
O>Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю.
... и по причине лёгкого абуза запрещена по умолчанию везде, кроме особо закрытых сетей.
Здравствуйте, avpavlov, Вы писали:
N>>В пассивном режиме к нему подключиться нереально — ему не хватает портов всем отдать. А в активном — отдаёт на ура. A>а разве для отдачи порт не нужен?
Вы тоже путаете порт и сокет.
Я как-то на это отвечал
Здравствуйте, ДимДимыч, Вы писали:
O>>Не зная протокола ? Я так не могу. ДД>Все UPS'ы, что мне встречались, работали как communication device, т.е. обычный виртуальный COM-port.
Тебе, наверно, только хорошие встречались, или одной фирмы.
На рынке дешёвых — куча таких, которые только через HID, причём конкретные сообщения нигде не документированы.
BTW, Victron'ы (они же GE) до сих пор принципиально не держат USB. Или RS-232, или SNMP коробочка.
Здравствуйте, quwy, Вы писали:
Q>Здравствуйте, Arsen.Shnurkov, Вы писали: AS>>А в чем проблема? Q>А в том, что по-хорошему негоже клиенту сервером прикидываться
что на счет SMB? что на счет кучи других протоколов для чатов и обмена файлов, которые приницпиально не работают за фаером или натом, потому что их разработчики об этом не думали?
> (а т.н. "пассивный режим" -- очередной костыль, который прикрутили сбоку в надежде,
да-да. у IM's костыль еще круче -- через 3rd сервер. это просто супер умное решение. у ftp как раз все продумано.
> Какая нафиг секьюрность?
если вы намекаете на то, что можно авторизоваться путем открытой передачи пароля по сети, который можно прописать ftp://user:pass@host/dir/file, то из этого ничего не следует. а вот с SMB в этом смысле все намного хуже.
> Пень через колоду просто с архитектурной точки зрения.
какой протокол вы считаете образцом для подражания с архитектурной точки зрения? ой, извините, забыл, что у вас все протоколы кривые. весь мир бардак и все бабы поэтэссы и солнце долбанный фонарь. только это не архитектура. с этим к психиатру.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
идеальный протокол вместо ftp — это WebDAV over https
1. можно обходить каталоги (вглубь и как угодно)
2. потенциально поддерживает версионирование
3. есть шифрование
4. возможно сжатие при передаче
5. поддерживается в интерфейсе windows (web-folders называется)
Здравствуйте, netch80, Вы писали:
N>Что именно не нравится?
Так написали же. Проблемы с кодировками; наличие двух каналов связи, один из которых изначально устанавливался от сервера к клиенту; пассивный режим, требующий дополнительных портов и сокетов.
N>Отдельным каналом для данных? SCTP не было.
Отдельный канал не нужен при обычном TCP (и даже UDP).
N>Авторизация? Не было ни причины ни идей придумывать что-то сложнее. N>ARPAnet тогдашних времён был нацелен на полное доверие и выживание при любой возможности, и решения были соответствующие. N>Например, в SMTP-серверах до середины 90-х не было защиты от релеинга чужих писем. Потому что не было спама.
Защиту никто не критикует, это как раз понятно, что теперешних проблем с секьюрити тогда никто не предполагал.
Здравствуйте, ononim, Вы писали:
Q>>Ну если про NAT это еще можно сказать, то firewall -- извините, это не хак. Arpanet разрабатывалась как военная сеть и предположить тот факт, что не на всех машинах будут доступны все порты, можно было. O>"Недоступность портов" это ваще идиотская фишка файрволлов я считаю. Как и файрволлы сами по себе. IDS еще куда ни шло.
Если доступ к какому-то ресурсу в принципе недопустим с определённых адресов, то зачем надеяться на IDS?
Q>>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21? O>Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует.
Однократные токены.
O>Философская причина: новая команда FTP — новая сущность, зачем? Мне всегда эстетически нравились архитектуры в которых базовым набором команд делаются все необходимые операции как конструктором, и не нравились где каждая команда — суть пользовательская операция.
Проблема именно в авторизации действия по такому соединению к кому-то другому.
Хотя если бы её хотели решить конструктивно — решили бы. Например, вводится передача в команду PASV проверочного приветствия и своего пароля, и протокол, который гарантированно непохож ни на один существующий и который предусматривает обмен этими данными перед собственно передачей.
А я ведь говорил, что 90% линуксового десктопного софта -- это недоделанный постоянно глючащий хлам.
Вон, даже у гуру-линуксоида не работает нормально.
Q>Вот меня всегда интересовало, а какой дурень придумал протокол FTP? Q>Это каким местом нужно было думать, чтобы додуматься до ЭТОГО? Q>У меня такое ощущение, что изобретатели основных интернет-протоколов (и не только сабжа) думали не головой, а одним местом.
А в чем проблема?
Если в секьюрности, то есть масса вариантов:
ftp over SSH, или
Secure FTP (SFTP), или
FTP over SSL (FTPS), или
sftp, или,
наконец запусти vpn и всё будет секьюрно...
Здравствуйте, Arsen.Shnurkov, Вы писали: AS>А в чем проблема?
А в том, что по-хорошему негоже клиенту сервером прикидываться (а т.н. "пассивный режим" -- очередной костыль, который прикрутили сбоку в надежде, что он сделает из говна конфету). Какая нафиг секьюрность? Пень через колоду просто с архитектурной точки зрения.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>А в чем проблема?
присоединяюсь к вопросу. в чем проблема с ftp? нормальный протокол. постоянно использую в работе. скажите, а как еще между двумя машинами гонять файлы, при условии, что машины под разными осями и желательно обойтись тем софтом, который либо предустановлен изначально, либо бесплатен и общепринят. помимо ftp не так уж много вариантов...
AS>Если в секьюрности, то есть масса вариантов:
а кто сказал за секьюрити? файл может быть зашифрован изначально. на фига это поручать ftp? да и как вы сами сказали ftp можно и поверх запустить. вполне в стиле unix way. каждый делает свою работу. а если ftp займется еще шифрованием -- я сдохну реализовывать клиента, не говоря уже за сервер.
AS>наконец запусти vpn и всё будет секьюрно...
ТС возмущается протоколом в стиле, что все придурки и он один такой умный. исторический контекст, конечно, он не учитывает. и как-то не обращает внимание на то, что новых способов передачи файлов (мыло и самба не в счет) до сих пор не придумали. особенно, если мне не просто файл передать нужно, но и по каталогу пройтись.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
Q>>Здравствуйте, Arsen.Shnurkov, Вы писали: AS>>>А в чем проблема? Q>>А в том, что по-хорошему негоже клиенту сервером прикидываться М>что на счет SMB?
"А у вас негров линчуют!" (C)
М>что на счет кучи других протоколов для чатов и обмена файлов, которые приницпиально не работают за фаером или натом, потому что их разработчики об этом не думали?
У меня за NAT работает все кроме FTP. А когда нужно было туннель для сабжа поднимать, геморроя натерпелись выше головы даже на выделенном сервере.
>> (а т.н. "пассивный режим" -- очередной костыль, который прикрутили сбоку в надежде, М>да-да. у IM's костыль еще круче -- через 3rd сервер. это просто супер умное решение. у ftp как раз все продумано.
Продумано? Мама, какое нахрен продумано? Реверсивное подключение, четырехкратный пинг на каждый файл, пассивный режим с хрен поймет какими портами -- все это, оказывается, продумано!?
>> Какая нафиг секьюрность? М>если вы намекаете на то, что можно авторизоваться путем открытой передачи пароля по сети, который можно прописать ftp://user:pass@host/dir/file, то из этого ничего не следует. а вот с SMB в этом смысле все намного хуже.
"А у вас негров линчуют!"
Кто-нибудь упоминал SMB? Покажите мне этого паскудника!
>> Пень через колоду просто с архитектурной точки зрения. М>какой протокол вы считаете образцом для подражания с архитектурной точки зрения? ой, извините, забыл, что у вас все протоколы кривые.
Сабж и HTTP маст дай, остальное -- слишком разное, а что?
Здравствуйте, мыщъх, Вы писали:
AS>>наконец запусти vpn и всё будет секьюрно... М>ТС возмущается протоколом в стиле, что все придурки и он один такой умный.
ТС возмущается тупостью и недальновидностью архитекторов, которым 640 КБ достаточно на все случаи жизни. Нахрена реверсивное подключение? Нахрена вообще раздельные каналы для команд и данных? HAYES как-то обходится одним физическим линком, но нет, нужно же было свой собственный велосипед изобрести.
М>исторический контекст, конечно, он не учитывает. и как-то не обращает внимание на то, что новых способов передачи файлов (мыло и самба не в счет) до сих пор не придумали. особенно, если мне не просто файл передать нужно, но и по каталогу пройтись.
А кто вообще называл альтернативу? SMB вам во сне пригрезилось, я же просто спросил каким местом думали изобретатели одного конкретного протокола -- FTP.
Здравствуйте, quwy, Вы писали:
Q>Вот меня всегда интересовало, а какой дурень придумал протокол FTP? Q>Это каким местом нужно было думать, чтобы додуматься до ЭТОГО?
Что именно не нравится?
Поддержка кучи разных форматов данных? Ну так он разрабатывался, когда 8-битные октеты ещё не были однозначной нормой. Более того, первые машины для APRAnet были 18- или 36-битные.
Завязка на telnet? Так telnet уже был готов и работал, и реально она не используется.
Отдельным каналом для данных? SCTP не было.
Авторизация? Не было ни причины ни идей придумывать что-то сложнее.
ARPAnet тогдашних времён был нацелен на полное доверие и выживание при любой возможности, и решения были соответствующие.
Например, в SMTP-серверах до середины 90-х не было защиты от релеинга чужих писем. Потому что не было спама.
Q>У меня такое ощущение, что изобретатели основных интернет-протоколов (и не только сабжа) думали не головой, а одним местом.
Они были мудрее нас с тобой вместе взятых. И под тогдашние цели и реалии они всё это придумывали достаточно хорошо. Вот к современному IETF у меня таки куча претензий.
Здравствуйте, quwy, Вы писали:
Q>Здравствуйте, Arsen.Shnurkov, Вы писали: AS>>А в чем проблема? Q>А в том, что по-хорошему негоже клиенту сервером прикидываться (а т.н. "пассивный режим" -- очередной костыль, который прикрутили сбоку в надежде, что он сделает из говна конфету). Какая нафиг секьюрность? Пень через колоду просто с архитектурной точки зрения.
Вот есть такой time.nist.gov, на котором лежит файлик просто чудовищной важности для систем реального времени — таблица корректировочных секунд для UTC. (Кстати, ближайшая будет 30 июня сего года, и в этом дне будет секунда с хитрым временем 23:59:60.)
В пассивном режиме к нему подключиться нереально — ему не хватает портов всем отдать. А в активном — отдаёт на ура.
Здравствуйте, netch80, Вы писали:
N>Вот есть такой time.nist.gov, на котором лежит файлик просто чудовищной важности для систем реального времени — таблица корректировочных секунд для UTC. (Кстати, ближайшая будет 30 июня сего года, и в этом дне будет секунда с хитрым временем 23:59:60.) N>В пассивном режиме к нему подключиться нереально — ему не хватает портов всем отдать. А в активном — отдаёт на ура.
Что-то я не понял, почему в пассивном режиме не хватает портов, а в активном хватает, учитывая то, что в активном все равно открывается клиентский порт на сервере? А в пассивном он мог бы теоретически с одного порта раздавать сразу нескольким клиентам, благо файл один.
Здравствуйте, mrTwister, Вы писали:
N>>Вот есть такой time.nist.gov, на котором лежит файлик просто чудовищной важности для систем реального времени — таблица корректировочных секунд для UTC. (Кстати, ближайшая будет 30 июня сего года, и в этом дне будет секунда с хитрым временем 23:59:60.) N>>В пассивном режиме к нему подключиться нереально — ему не хватает портов всем отдать. А в активном — отдаёт на ура. T>Что-то я не понял, почему в пассивном режиме не хватает портов, а в активном хватает, учитывая то, что в активном все равно открывается клиентский порт на сервере?
В активном режиме открывается *сокет*, а не порт. Порт у них всех один и тот же — 20.
T> А в пассивном он мог бы теоретически с одного порта раздавать сразу нескольким клиентам, благо файл один.
Мог бы. Более того, можно было бы вообще поставить что-то вроде следующего — через inetd написать
920/tcp stream nowait nobody /bin/sh sh 'cat /home/ftp/pub/leap-seconds.txt; echo END'
и вообще никакого FTP не надо было бы. Разумеется, обучив этому постоянные клиенты.
Но они почему-то категорически остановились на использовании стандартных утилит без кастомных патчей.
Здравствуйте, quwy, Вы писали:
Q>Здравствуйте, Arsen.Shnurkov, Вы писали: AS>>А в чем проблема? Q>А в том, что по-хорошему негоже клиенту сервером прикидываться
Видите ли, когда придумывали протокол FTP понятия клиента и сервера как-то ещё не очень установившимися были, как и многое другое. Первая версия FTP вообще появилась ещё в 1971 году, а более-менее современный вид устаканился к 1982 году.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>А в чем проблема?
Основная проблема FTP в отсутствии в базовой версии стандартизированного способа получить листинг каталога. И сразу же за этим — отсутствие в базовой версии стандарта хоть каких-либо упоминаний кодировок (кроме ASCII и EBCDIC, не к ночи будь помянута). Вследствие чего имеем листинги, ориентированные на чтение глазами на узком терминале («если файл модифицирован в течение последнего года, то показываем день, месяц и время; если раньше, то день, месяц и год»), и неподписанные кодировки.
Нет, есть, конечно, RFC2640 от 1999 года и RFC3659 от 2007, но до сих пор крупные игроки на рынке FTP-серверов их не реализуют или реализуют опционально на усмотрение администратора.
Здравствуйте, quwy, Вы писали:
Q>Вот меня всегда интересовало, а какой дурень придумал протокол FTP? Q>Это каким местом нужно было думать, чтобы додуматься до ЭТОГО? Q>У меня такое ощущение, что изобретатели основных интернет-протоколов (и не только сабжа) думали не головой, а одним местом.
Здравствуйте, okman, Вы писали:
Q>>Вот меня всегда интересовало, а какой дурень придумал протокол FTP? Q>>Это каким местом нужно было думать, чтобы додуматься до ЭТОГО? Q>>У меня такое ощущение, что изобретатели основных интернет-протоколов (и не только сабжа) думали не головой, а одним местом.
O>Это Вы еще до USB не дошли, наверное.
А что USB? С точки зрения прикладного программиста в нём самое кривое — отсутствие механизма подачи внимания от внешнего устройства.
Здравствуйте, netch80, Вы писали:
N>А что USB? С точки зрения прикладного программиста в нём самое кривое — отсутствие механизма подачи внимания от внешнего устройства.
Это я о том, что все познается в сравнении.
Вы спецификации USB 2.0 видели ? Я как-то хотел однажды написать утилиту
для контроля ИБП (как работала штатная, меня страшно не устраивало), заодно
немного "прокачать" скиллы по USB. После двух-трех недель ковыряния этих
многосотстраничных документов и чтения книг Агурова, пришел к выводу,
что застряну в лучшем случае на полгода. Вот такие они бывают, эти протоколы.
Здравствуйте, okman, Вы писали:
N>>А что USB? С точки зрения прикладного программиста в нём самое кривое — отсутствие механизма подачи внимания от внешнего устройства.
O>Это я о том, что все познается в сравнении. O>Вы спецификации USB 2.0 видели ? Я как-то хотел однажды написать утилиту O>для контроля ИБП (как работала штатная, меня страшно не устраивало), заодно O>немного "прокачать" скиллы по USB. После двух-трех недель ковыряния этих O>многосотстраничных документов и чтения книг Агурова, пришел к выводу, O>что застряну в лучшем случае на полгода. Вот такие они бывают, эти протоколы.
Если использовать libusb и взять пример грамотной инициализации, то всё в разы проще.
Полугода там нет. Зная конкретные запросы к UPS и ответы на них — пару дней без безумной спешки.
Здравствуйте, netch80, Вы писали:
N>Если использовать libusb и взять пример грамотной инициализации, то всё в разы проще. N>Полугода там нет. Зная конкретные запросы к UPS и ответы на них — пару дней без безумной спешки.
O>>Это Вы еще до USB не дошли, наверное.
N>А что USB? С точки зрения прикладного программиста в нём самое кривое — отсутствие механизма подачи внимания от внешнего устройства.
Он сильно переусложнен, имхо. Если работать напрямую, а не через обертки. После того же serial, который я нежно люблю за простоту, USB — ад и геморрой.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
AS>>А в чем проблема? Q>А в том, что по-хорошему негоже клиенту сервером прикидываться
Какие нить аргументы против этой фичи кроме "негоже" есть?
А вот аргумент за: возможность трансфера файлов между двумя FTP серверами, инициированного клиентом, который через себя данные не пропускает при этом
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
AS>>>А в чем проблема? Q>>А в том, что по-хорошему негоже клиенту сервером прикидываться O>Какие нить аргументы против этой фичи кроме "негоже" есть?
NAT и firewall.
O>А вот аргумент за: возможность трансфера файлов между двумя FTP серверами, инициированного клиентом, который через себя данные не пропускает при этом
Это без проблем делается без обратного подключения к клиенту.
AS>>>>А в чем проблема? Q>>>А в том, что по-хорошему негоже клиенту сервером прикидываться O>>Какие нить аргументы против этой фичи кроме "негоже" есть? Q>NAT и firewall.
Тогда их еще не было. Они сами со себе являются хаками, основанными на "обычных" сценариях пользования TCP/IP
O>>А вот аргумент за: возможность трансфера файлов между двумя FTP серверами, инициированного клиентом, который через себя данные не пропускает при этом Q>Это без проблем делается без обратного подключения к клиенту.
Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>Какие нить аргументы против этой фичи кроме "негоже" есть? Q>>NAT и firewall. O>Тогда их еще не было. Они сами со себе являются хаками, основанными на "обычных" сценариях пользования TCP/IP
Ну если про NAT это еще можно сказать, то firewall -- извините, это не хак. Arpanet разрабатывалась как военная сеть и предположить тот факт, что не на всех машинах будут доступны все порты, можно было.
Q>>Это без проблем делается без обратного подключения к клиенту. O>Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю.
Хотел написать, что вся эта красота отключена на 999 серверах из 1000, но меня опередили.
Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21?
O>>Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю. N> ... и по причине лёгкого абуза запрещена по умолчанию везде, кроме особо закрытых сетей.
Ну мона запрещать не все подряд, а делать списки IPшников куда мона конектиться и/или разрешать оную фичу тока для доверенных юзеров, а не анонимусов.
Как много веселых ребят, и все делают велосипед...
Q>>>NAT и firewall. O>>Тогда их еще не было. Они сами со себе являются хаками, основанными на "обычных" сценариях пользования TCP/IP Q>Ну если про NAT это еще можно сказать, то firewall -- извините, это не хак. Arpanet разрабатывалась как военная сеть и предположить тот факт, что не на всех машинах будут доступны все порты, можно было.
"Недоступность портов" это ваще идиотская фишка файрволлов я считаю. Как и файрволлы сами по себе. IDS еще куда ни шло.
ЗЫ Я работаю в конторе у которой бизнес основан на файрволлах, так что знаю что говорю
O>>Повторяю — вот я клиент, подключился к N серверам по FTP, и теперь мне захотелось гонять данные между мной и произвольным из этих серверов а так же между любыми двумя этим серверами, не прибегая к каким нить другим протоколам. Обратное подключение тем и хорошо что оно не обязательно к клиенту (хотя многие сервера запрещают другие сценарии его использования), а может быть к другому серверу который примет подключение как в passive режиме. Очень мощная фича я считаю. Q>Хотел написать, что вся эта красота отключена на 999 серверах из 1000, но меня опередили.
Ну если рассматривать анонимнусные сервера и логины — то само собой
Q>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21?
Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует.
Философская причина: новая команда FTP — новая сущность, зачем? Мне всегда эстетически нравились архитектуры в которых базовым набором команд делаются все необходимые операции как конструктором, и не нравились где каждая команда — суть пользовательская операция.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Я знаю, я знаю!!
AS>идеальный протокол вместо ftp — это WebDAV over https
ситуация. есть программа бэкапа, которая грузится с флешки. она поддерживает ftp. WebDAV -- увы и ах
ситуация N2: есть программа восстановления диска, которая тоже грузится с флешки и тоже как ни странно поддерживает только ftp, то ни разу не WebDAV
ситуация N3: есть хостер, который дает мне доступ по ftp для заливки файлов (практически все дают), кто дает по WebDAV? ну кто-то может и дает...
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
AS>>идеальный протокол вместо ftp — это WebDAV over https М>ситуация. есть программа бэкапа, которая грузится с флешки. она поддерживает ftp. WebDAV -- увы и ах
Меняем программу.
М>ситуация N2: есть программа восстановления диска, которая тоже грузится с флешки и тоже как ни странно поддерживает только ftp, то ни разу не WebDAV
Меняем программу.
М>ситуация N3: есть хостер, который дает мне доступ по ftp для заливки файлов (практически все дают), кто дает по WebDAV? ну кто-то может и дает...
Меняем хостера.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, мыщъх, Вы писали:
AS>>>идеальный протокол вместо ftp — это WebDAV over https М>>ситуация. есть программа бэкапа, которая грузится с флешки. она поддерживает ftp. WebDAV -- увы и ах C>Меняем программу.
какая программа бэкапа, которая грузится в флехи, поддерживает WebDAV? можно ли обменять без доплаты, т.к. программу я уже купил.
М>>ситуация N2: есть программа восстановления диска, которая тоже грузится с флешки и тоже как ни странно поддерживает только ftp, то ни разу не WebDAV C>Меняем программу.
на что меняем, простите? программ для восстановления дисков можно пересчитать по пальцам одной руки.
М>>ситуация N3: есть хостер, который дает мне доступ по ftp для заливки файлов (практически все дают), кто дает по WebDAV? ну кто-то может и дает... C>Меняем хостера.
во имя чего? чтобы пользоваться идеальным протоколом WebDAV, который идеален как персидская принцесса, вот только нормальный народ говорит на английском, испанском и паре тройке других языков.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, okman, Вы писали:
N>>Если использовать libusb и взять пример грамотной инициализации, то всё в разы проще. N>>Полугода там нет. Зная конкретные запросы к UPS и ответы на них — пару дней без безумной спешки. O>Не зная протокола ? Я так не могу.
Действия послать порцию октетов и получить ответ достаточно просты, чтобы не лезть в детали протокола.
Здравствуйте, Eugeny__, Вы писали:
O>>>Это Вы еще до USB не дошли, наверное. N>>А что USB? С точки зрения прикладного программиста в нём самое кривое — отсутствие механизма подачи внимания от внешнего устройства. E__>Он сильно переусложнен, имхо. Если работать напрямую, а не через обертки. После того же serial, который я нежно люблю за простоту, USB — ад и геморрой.
Мнэээ... RS-232, конечно, кажется простым, но только до тех пор, пока на него не наворотишь свой слой пакетизации, детекта устройства и так далее. После этого он становится не проще USB, а может, и сложнее.
Здравствуйте, netch80, Вы писали:
O>>Не зная протокола ? Я так не могу.
N>Действия послать порцию октетов и получить ответ достаточно просты, чтобы не лезть в детали протокола.
Идея была в том, чтобы осилить протокол USB, решая одну из базовых задач.
Честно признаюсь — мне это не удалось. Перечитал Агурова и pdf-ки с usb.org почти все,
наверное, а в голове по-прежнему каша. Как все эти descriptors и reports связаны, и
как эта вся кухня работает — не понял. Поэтому после USB такие протоколы, как FTP, кажутся
элементарщиной. А пользоваться либами, не постигнув сути происходящего, мне неинтересно.
Лучше я помучаюсь еще какое-то время, "созрею", а потом возьму, да и осилю.
Здравствуйте, ДимДимыч, Вы писали:
O>>Не зная протокола ? Я так не могу.
ДД>Все UPS'ы, что мне встречались, работали как communication device, т.е. обычный виртуальный COM-port.
Ну так речь же не о том, сложно или не сложно использовать протокол практически, как с
помощью библиотек, а о сложности самого протокола. Не могу сказать, что USB в этом
плане простой. И такие вещи, как virtual com, появились, видимо, тоже неспроста,
потому что программировать COM существенно проще.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Я знаю, я знаю!!
AS>идеальный протокол вместо ftp — это WebDAV over https
AS>1. можно обходить каталоги (вглубь и как угодно) AS>2. потенциально поддерживает версионирование AS>3. есть шифрование AS>4. возможно сжатие при передаче AS>5. поддерживается в интерфейсе windows (web-folders называется)
Здравствуйте, okman, Вы писали:
ДД>>Все UPS'ы, что мне встречались, работали как communication device, т.е. обычный виртуальный COM-port.
O>Ну так речь же не о том, сложно или не сложно использовать протокол практически, как с O>помощью библиотек, а о сложности самого протокола. Не могу сказать, что USB в этом O>плане простой. И такие вещи, как virtual com, появились, видимо, тоже неспроста, O>потому что программировать COM существенно проще.
Скорее потому, что были уже готовые и отлаженные средства, которым надо было всего лишь подменить идентификацию порта. А дальше работало как всё привычное.
Конечно, переходить после этого на сложные технологии вроде "найти устройство, открыть endpoint, создать канал, посылать что-то по этому каналу" сильно сложнее.
Здравствуйте, okman, Вы писали:
O>>>Не зная протокола ? Я так не могу. N>>Действия послать порцию октетов и получить ответ достаточно просты, чтобы не лезть в детали протокола. O>Идея была в том, чтобы осилить протокол USB, решая одну из базовых задач. O>Честно признаюсь — мне это не удалось. Перечитал Агурова и pdf-ки с usb.org почти все, O>наверное, а в голове по-прежнему каша. Как все эти descriptors и reports связаны, и O>как эта вся кухня работает — не понял.
Гм... ты, наверно, не изучал SIP или H.323. Вот там действительно сложно. USB по сравнению с этим, конечно, путано описывается, но достаточно просто и прямолинейно.
Все эти reports и descriptors — стандартные структуры данных для стандартных целей. Метод общения достаточно прост и понятен. Изучаешь, что к тебе подключилось, чуть подстраиваешь по необходимости, открываешь связи и работаешь.
O> Поэтому после USB такие протоколы, как FTP, кажутся O>элементарщиной. А пользоваться либами, не постигнув сути происходящего, мне неинтересно. O>Лучше я помучаюсь еще какое-то время, "созрею", а потом возьму, да и осилю.
Здравствуйте, quwy, Вы писали:
N>>Что именно не нравится? Q>Так написали же. Проблемы с кодировками; наличие двух каналов связи, один из которых изначально устанавливался от сервера к клиенту; пассивный режим, требующий дополнительных портов и сокетов.
Идея понятна. А теперь подумай, пожалуйста, вот о чём:
1. Бинарное мультиплексирование — возможно, но не подходит по стилю реализации. Реализация должна была быть настолько проста, чтобы пригодна к диагностике и/или аварийному использованию через простейший telnet.
2. Текстовое мультиплексирование приводит к чему-то вроде нынешнего HTTP, но с определёнными проблемами. Например, неудобно каждый раз задавать контекст. Бинарные данные передавать в тексте — сорвёт крышу подложке. Конверсия в текстово-совместимый формат типа base64 — дорого во всех смыслах. Более того, как выцепить поток данных из переговоров данных по HTTP, видимых в telnet? Как его потом конвертировать и, главное, зачем требовать этого? А в случае отдельного соединения это тривиально — данные просто выливаются в файл или берутся из файла.
Да, сейчас хорошо сравнивать с HTTP. Для которого уже наделали клиентов всех видов. Особенно если WebDAV, как тут упоминали рядом. А тогда? Нормальная реализация HTTP требует больше памяти, чем могла себе позволить типичная машинка того времени.
Проблемы с кодировками — кодировками чего? Файлов? Их вообще-то нет, если платформа не извращённая, как Windows (с различием text/binary) или что-то 36-битное. Имён файлов? Да, проблема была, но возникла только за счёт поспешного решения 8-битных кодировок в exUSSR и аналогичных местах.
Сейчас нормальные клиенты и серверы используют только UTF-8 и проблемы нет, по крайней мере пока не вмешиваются заморочки Unicode (типа разложить символ на codepoints или собрать в один), от которых никто нигде не защищён.
Итого, мы всё равно приходим к тому, что ресурсы тех времён требовали решения в виде предельно простого канала управления и использования внешних уже готовых средств мультиплексирования (второе соединение) для данных. А активный или пассивный режим при этом делать основным — уже не так существенно.
N>>Отдельным каналом для данных? SCTP не было. Q>Отдельный канал не нужен при обычном TCP (и даже UDP).
Громоздко, неудобно, криво и, главное, не видно цели такого решения.
Задача пробиться через файрволлы не стояла в принципе.
Здравствуйте, quwy, Вы писали:
Q>Здравствуйте, ononim, Вы писали:
O>>>>Какие нить аргументы против этой фичи кроме "негоже" есть? Q>>>NAT и firewall. O>>Тогда их еще не было. Они сами со себе являются хаками, основанными на "обычных" сценариях пользования TCP/IP Q>Ну если про NAT это еще можно сказать, то firewall -- извините, это не хак. Arpanet разрабатывалась как военная сеть и предположить тот факт, что не на всех машинах будут доступны все порты, можно было.
Ну так во времена Arpanet ещё и портов то небыло. Какие ещё firewall? Они привет уже из восьмидесятых.
O>>"Недоступность портов" это ваще идиотская фишка файрволлов я считаю. Как и файрволлы сами по себе. IDS еще куда ни шло. >Если доступ к какому-то ресурсу в принципе недопустим с определённых адресов, то зачем надеяться на IDS?
Чтобы доступ к ресурсу был недопустим — нужно убрать ресурс как таковой. Чтобы он был допустим только для определенных сетей — забиндить его на интерфейсы которые смотрят только в те определенные сети. Разграничивать доступ по IPшникам которые являются частью большой сети (интернета) ваще малоосмысленное с ТЗ секурити занятие. Разве что от DOSа. Но от DOSа если блокировать IPшник — то ваще все с него, а не определенные порты.
Да и в конце то концов — все видимые сервисы должны быть в определенном диапазоне, остальное — динамические порты, которые являются частью прикладных протоколов, дело файрволла — разграничивать доступ к сервисам, если он в прикладных протоколах этих сервисов ни бумбум — значит он не должен соваться глубже, разграничивая доступы к динамическому диапазону.
Q>>>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21? O>>Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует. N>Однократные токены.
Дающий однократно одному фтп серверу полный доступ на уровне текущего логина к другому? Это мало чем лучше от знания логина/пароля. Или один раз не ... — будет служить основой секурити?
O>>Философская причина: новая команда FTP — новая сущность, зачем? Мне всегда эстетически нравились архитектуры в которых базовым набором команд делаются все необходимые операции как конструктором, и не нравились где каждая команда — суть пользовательская операция. N>Проблема именно в авторизации действия по такому соединению к кому-то другому. N>Хотя если бы её хотели решить конструктивно — решили бы. Например, вводится передача в команду PASV проверочного приветствия и своего пароля, и протокол, который гарантированно непохож ни на один существующий и который предусматривает обмен этими данными перед собственно передачей.
Костыль ради того чтоб работали какието то быдлоFW и быдлоNAT которые не знают про FTP, который был придуман до FW и NAT?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>"Недоступность портов" это ваще идиотская фишка файрволлов я считаю. Как и файрволлы сами по себе. IDS еще куда ни шло. >>Если доступ к какому-то ресурсу в принципе недопустим с определённых адресов, то зачем надеяться на IDS? O>Чтобы доступ к ресурсу был недопустим — нужно убрать ресурс как таковой. Чтобы он был допустим только для определенных сетей — забиндить его на интерфейсы которые смотрят только в те определенные сети.
Пусть сеть A имеет право на доступ к ресурсу, а сеть B — нет. При этом обе сети находятся за маршрутизатором и видны данному серверу через eth1. Как будешь управлять биндингом?
А через фильтр с разграничением по IP и ingress filtering на маршрутизаторе, не пропускающем пакеты с левых сетей — получается надёжная и гарантированная защита.
Почему я должен отказываться от подобных схем ради странной теории?
O> Разграничивать доступ по IPшникам которые являются частью большой сети (интернета) ваще малоосмысленное с ТЗ секурити занятие. Разве что от DOSа. Но от DOSа если блокировать IPшник — то ваще все с него, а не определенные порты.
Во-первых, я говорил про интранет. Во-вторых, и в случае интернета есть существенная разница. Когда я работал в ISP, мы в принципе давали доступ к smtp.lucky.net только с адресов нашей автономной системы (и пары других AS, с которыми были договора об этом). Если кому-то нужно было прийти извне с авторизацией — он шёл на auth-smtp.lucky.net, на котором такого разграничения не было, но на письмо обязательно требовалась авторизация. Вот этот доступ уже был открыт всем, но своя IDS контролировала диверсии против этого адреса (которых, на самом деле, по факту так ни одной и не произошло — ибо неуловимый Джо). Это при том, что физически они сидели на одном хосте — но логически их было удобнее разделить на разные сущности со своими IP адресами. Аналогично было с несколькими другими сервисами.
O>Да и в конце то концов — все видимые сервисы должны быть в определенном диапазоне, остальное — динамические порты, которые являются частью прикладных протоколов, дело файрволла — разграничивать доступ к сервисам, если он в прикладных протоколах этих сервисов ни бумбум — значит он не должен соваться глубже, разграничивая доступы к динамическому диапазону.
А про динамические я ничего и не говорил. Хотя в случаях запрета прямого выхода в мир общий ограничитель работает и для них.
Q>>>>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21? O>>>Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует. N>>Однократные токены. O>Дающий однократно одному фтп серверу полный доступ на уровне текущего логина к другому? Это мало чем лучше от знания логина/пароля. Или один раз не ... — будет служить основой секурити?
А почему ты не думаешь, что однократный токен может ограничивать и доступ к конкретному файлу и не дальше его? Например, построим как hash от логина, пароля, внутреннего seq и полного пути.
O>>>Философская причина: новая команда FTP — новая сущность, зачем? Мне всегда эстетически нравились архитектуры в которых базовым набором команд делаются все необходимые операции как конструктором, и не нравились где каждая команда — суть пользовательская операция. N>>Проблема именно в авторизации действия по такому соединению к кому-то другому. N>>Хотя если бы её хотели решить конструктивно — решили бы. Например, вводится передача в команду PASV проверочного приветствия и своего пароля, и протокол, который гарантированно непохож ни на один существующий и который предусматривает обмен этими данными перед собственно передачей. O>Костыль ради того чтоб работали какието то быдлоFW и быдлоNAT которые не знают про FTP, который был придуман до FW и NAT?
Нет, речь не про файрволл или NAT. Речь, например, про рассылку спама. Пишется файл, состоящий из строк:
MAIL FROM:<адрес>
RCPT TO:<адрес>
...
DATA
текст письма
.
RSET
QUIT
дальше кладётся на FTP сервер любым путём (например, на чём-то вроде github создать проект, в котором этот файл будет в данных), и делается массовый GET с указанием порта назначения — левого SMTP сервера с портом 25 или 587. Это пример схемы, есть вариации. Никогда не слышал? А наука умеет много гитик и это не самая сложная, и она массово применялась в окрестностях 2000-го года.
Q>>>>>Однако повторю вопрос: что мешает при желании одному FTP подключиться и передать файл на другой FTP по команде, принятой от пользователя по единственному каналу в виде сокета на порт 21? O>>>>Ну сходу практичная причина: необходимость авторизации на другом FTP логином/паролем, которому первому знать не следует. N>>>Однократные токены. O>>Дающий однократно одному фтп серверу полный доступ на уровне текущего логина к другому? Это мало чем лучше от знания логина/пароля. Или один раз не ... — будет служить основой секурити? N>А почему ты не думаешь, что однократный токен может ограничивать и доступ к конкретному файлу и не дальше его? Например, построим как hash от логина, пароля, внутреннего seq и полного пути.
Идя по такому пути в конце концов образом мы изобретем FTP-over-FTP туннель, сделав из FTP сервера еще и прокси И все это ради быдлофрйрволлов
N>>>Хотя если бы её хотели решить конструктивно — решили бы. Например, вводится передача в команду PASV проверочного приветствия и своего пароля, и протокол, который гарантированно непохож ни на один существующий и который предусматривает обмен этими данными перед собственно передачей. O>>Костыль ради того чтоб работали какието то быдлоFW и быдлоNAT которые не знают про FTP, который был придуман до FW и NAT? N>Нет, речь не про файрволл или NAT. Речь, например, про рассылку спама. Пишется файл, состоящий из строк: N>.. N>дальше кладётся на FTP сервер любым путём (например, на чём-то вроде github создать проект, в котором этот файл будет в данных), и делается массовый GET с указанием порта назначения — левого SMTP сервера с портом 25 или 587. Это пример схемы, есть вариации. Никогда не слышал? А наука умеет много гитик и это не самая сложная, и она массово применялась в окрестностях 2000-го года.
Само собой слышал. Нефиг раздавать доступ к FTP акаунту к серверу с такой возможностью. Вы бы еще шелл раздавали под анонимусом с полным доступом к инету и потом жаловались что оттуда спам шлют.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, netch80, Вы писали:
N>Пусть сеть A имеет право на доступ к ресурсу, а сеть B — нет. При этом обе сети находятся за маршрутизатором и видны данному серверу через eth1. Как будешь управлять биндингом?
Биндить не по имени интерфейса, а по адресу.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, ДимДимыч, Вы писали:
N>>Пусть сеть A имеет право на доступ к ресурсу, а сеть B — нет. При этом обе сети находятся за маршрутизатором и видны данному серверу через eth1. Как будешь управлять биндингом? ДД>Биндить не по имени интерфейса, а по адресу.
Адрес у данного интерфейса только один. Как уже сказано, две других сети за *маршрутизатором*.
Ещё предложения?
Здравствуйте, ononim, Вы писали:
N>>А почему ты не думаешь, что однократный токен может ограничивать и доступ к конкретному файлу и не дальше его? Например, построим как hash от логина, пароля, внутреннего seq и полного пути. O>Идя по такому пути в конце концов образом мы изобретем FTP-over-FTP туннель, сделав из FTP сервера еще и прокси И все это ради быдлофрйрволлов
Нет, вопрос не в файрволлах, а как раз в доверии в открытой сети.
N>>дальше кладётся на FTP сервер любым путём (например, на чём-то вроде github создать проект, в котором этот файл будет в данных), и делается массовый GET с указанием порта назначения — левого SMTP сервера с портом 25 или 587. Это пример схемы, есть вариации. Никогда не слышал? А наука умеет много гитик и это не самая сложная, и она массово применялась в окрестностях 2000-го года. O>Само собой слышал. Нефиг раздавать доступ к FTP акаунту к серверу с такой возможностью.
То есть теперь ещё надо следить за комбинацией фич, выданных юзеру или какой-то группе? Одним — с разрешением канала данных к другому клиенту, другим — класть файлы, и следить, чтобы одни с другими не сговорились? Не проще ли разрешить фичу, но с адекватными техническими ограничениями?
O> Вы бы еще шелл раздавали под анонимусом с полным доступом к инету и потом жаловались что оттуда спам шлют.
Не вижу никакой связи и думаю, что Вы привели аналогию чисто для красного словца.
N>>>А почему ты не думаешь, что однократный токен может ограничивать и доступ к конкретному файлу и не дальше его? Например, построим как hash от логина, пароля, внутреннего seq и полного пути. O>>Идя по такому пути в конце концов образом мы изобретем FTP-over-FTP туннель, сделав из FTP сервера еще и прокси И все это ради быдлофрйрволлов N>Нет, вопрос не в файрволлах, а как раз в доверии в открытой сети.
Один сервер другому может не доверять. Причем объектом защиты безопасности может быть как файлы на другом сервере, так даже и имена/пути под которыми файл с одного сервера мы сохраняем на другой. Если мы хотим дать админам возможность качать майло с сервера на сервер имея на руках лишь модемный\gprs канал — надо в любом случае реализовывать server<->server interconnectivity. То есть один из серверов должен будет являться клиентом. Что собственно и было сделано уже в виде passive/active и к чему одноразовыее токены ничего не добавят в плане функционала, тк все равно будет режим когда сервер является клиентом.
Вся разница решения-нагромождения в виде однократного токена по сравнению с тем что есть — это то что это просто неявно сделает active режим тока режимом между серверами. Сейчас это отдано на откуп админам сервера и юзера — юзать ли клиентам active. А ваше решение — дополнить стандарт мегафичей которая по сути просто лишит их этого выбора и добавит геморроя имплементаторам.
N>>>дальше кладётся на FTP сервер любым путём (например, на чём-то вроде github создать проект, в котором этот файл будет в данных), и делается массовый GET с указанием порта назначения — левого SMTP сервера с портом 25 или 587. Это пример схемы, есть вариации. Никогда не слышал? А наука умеет много гитик и это не самая сложная, и она массово применялась в окрестностях 2000-го года. O>>Само собой слышал. Нефиг раздавать доступ к FTP акаунту к серверу с такой возможностью. N>То есть теперь ещё надо следить за комбинацией фич, выданных юзеру или какой-то группе? Одним — с разрешением канала данных к другому клиенту, другим — класть файлы, и следить, чтобы одни с другими не сговорились? Не проще ли разрешить фичу, но с адекватными техническими ограничениями?
Нет не проще. Проще сделать простую и надежную как молоток техническую фичу, а как и по чем стучать этим молотком — забота админа. В FTP еще кстати есть команда site — ее возможности тоже различаются между разными юзерами, если админ адекватен.
O>> Вы бы еще шелл раздавали под анонимусом с полным доступом к инету и потом жаловались что оттуда спам шлют. N>Не вижу никакой связи и думаю, что Вы привели аналогию чисто для красного словца.
Нет не для красного словца. Аналогия простая — есть мощная фича которую мона применять как админы для пользы так и хакеры во вред. Юзерам простым она воще не нужна. Потому ее нуна разрешать тока доверенным юзерам/админам, как и шелл, как впрочем нынче дела и обстоят, что создают обманчивое впечатление у большинства участвующих тут юзеров, что такой фичи ваще не существует. Она существует, просто для админов. А FTP никогда и не был user-friendly протоколом, это таки протокол для админов.
Как много веселых ребят, и все делают велосипед...
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
