Администраторы инфраструктуры kernel.org сообщили (https://www.kernel.org/shutting-down-ftp-services.html) о решении прекратить поддержку протокола FTP для доступа к основному архиву и FTP-зеркалам. Работа сервиса ftp://ftp.kernel.org/ будет прекращена с 1 марта 2017 года, а сервис ftp://mirrors.kernel.org/ с FTP-зеркалами (http://mirrors.kernel.org/) многих известных проектов будет закрыт 1 декабря 2017 года. После этого времени доступ к ресурсам будет осуществляться только по HTTP/HTTPS.
В качестве причин прекращение поддержки FTP отмечается:- Неэффективность протокола и связанная с этим необходимость применения обходных путей в настройке межсетевых экранов и балансировщиков нагрузки;- Отсутствие поддержки кэширования и применения акселераторов доступа. Например, при доступе к архиву по HTTP применяется сеть доставки контента cdn.kernel.org, для FTP создание подобной системы невозможно, что создаёт перекосы в нагрузке на инфраструктуру;- Стагнация разработки приложений с реализаций FTP и отсутствие регулярных обновлений. Прекращение использования FTP позволит повысить безопасность инфраструктуры за счёт сокращения публично доступных сервисов.
URL: https://www.kernel.org/shutting-down-ftp-services.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=45935
>за счёт сокращения публично доступных сервисовЧто это значит?
Уменьшение точек отказа.
> Уменьшение точек отказа.Не точек отказа, а поверхности атаки.
Это означает, что они сужают вектор для возможной атаки, публично доступных означает, что они доступны в рамках экстранет или Интернет, а не только в интранет.
Меньше открытых наружу протоколов - меньше потенциальных точек взлома/отказа.
Давно пора на битторрент протокол перейти.
Почему именно на него а не другие альтернативы?
Может-быть другие альтернативы не так распространены?
> Почему именно на него а не другие альтернативы?Какие альтернативы?
> Какие альтернативы?Может FreeNet, GNUnet, I2P, RetroShare?
С их скоростью - не лучший вариант. К сожалению.
Да и нет там ничего, что стоит дополнительно заворачивать со снижением эффективности.
Xuntei thunder://
Пройдет еще лет 20, и после того, как от залежалого хттп/с начнет смердить, тогда и передут на битторрент.
Вот-вот. Даже либреофис можно торентами скачать.
Но лучше, биткоинами.
Лучше уж на rsync.
> Лучше уж на rsync.Да, его очевидно недостаёт в браузерах рядом с/вместо ftp.
Уже есть
>> RSYNC rsync://rsync.kernel.org/pub/
>> https://www.kernel.org/
КЫНТС -- שдовс?
> Лучше уж на rsync.rsync там всегда был...
> Лучше уж на rsync.rsync очень сильно грузит сервера, как по i/o, так и по cpu.
ftp — самый легковесный из тройки ftp, http(s), rsync.
> Давно пора на битторрент протокол перейти.gittorrent? :)
> HTTP/HTTPSосталось сделать хипсторскую страничку с кучей гумноскриптов
Не понял связи.
> хипсторскую страничку с кучей гумноскриптовСплюнь!
А то вон РеактОС уже до этого докатились...
>> хипсторскую страничку
>РеактОС уже до этого докатились...Даже имакс уже "там". Семеро Толвальдса не ждут~ >/<
А мне FTP, как протокол, никогда не нравился.
А как способ скачивания/закачивания файлов?
Именно как способ закачивания-скачивания файлов HTTP отлично подходит. GET, PUT - что может быть проще?А вот с листингом файлов есть проблема, тут начинается webdav с сумасшедними microsoft-овскими xml-ями и рекурсиями, придуманными-то вовсе и не для файлов.
> Именно как способ закачивания-скачивания файлов HTTP отлично подходит. GET, PUT - что
> может быть проще?Нет, ФТП - самый быстрый протокол передачи данных. Но, к сожалению, и самый слабый, поскольку когда его делали, то на безопасность не заморачивались.
GET, PUT - они в в ФТП есть! :) Учите матчасть... Проблема не в примитивах мета-языка, а в реализации функциональности.
По http. FTP требует 2-х tcp соединений, что усложняет логику приложения и является причиной сетевых проблем. И распространенные FTP клиенты (winScp например) у меня лично работают очень медленно...
> (winScp например) у меня лично работают очень медленно...Так и должно быть: вендузятник должен страдать.
> По http. FTP требует 2-х tcp соединений, что усложняет логику приложения и
> является причиной сетевых проблем. И распространенные FTP клиенты (winScp например) у
> меня лично работают очень медленно...Скорее всего у тебя или сетевой экран плохо настроен, или сам клиент. Или и то, и другое! :)
Зря заминусовали человека. Переливать через FTP много маленьких файлов очень медленно, именно из-за подхода "каждый файл - отдельное TCP соединение".
>из-за подхода "каждый файл - отдельное TCP соединение".http://slacksite.com/other/ftp.html#pasvexample РацЫя - на танке!
О, да ви мастег игонии и иносказательного слога? Рацыю маете? Она, кстати, на бронетранспортёре была.Хотите сказать, что в passive mode не используется принцип "каждый файл - отдельное TCP соединение" ? А что тогда происходит? Появляется Keep-Alive? Pipelining? Параллельная передача нескольких файлов по нескольким TCP соединениям? Очень интересно послушать специалиста с реалнеймом.
> О, да ви мастег игонии и иносказательного
> Хотите сказать, что в passive mode не используется принцип "каждый файл -
> отдельное TCP соединение" ? А что тогда происходит?
>Очень интересно послушать специалиста с реалнеймом.Да. Некоторые специалисты не умеют в ftp:// еще больше, чем kernel.ogr. Очевидно же.
Так вы, товарищ специалист, так и не ответили. Я повторю вопрос.Хотите сказать, что в passive mode не используется принцип "каждый файл - отдельное TCP соединение" ? А что тогда происходит? Появляется Keep-Alive? Pipelining? Параллельная передача нескольких файлов по нескольким TCP соединениям?
> Так вы, товарищ специалист, так и не ответили. Я повторю вопрос.Моя [само-]ирония была слишком мастерска для Вас? Ну ничего.
Я ответил. Я не умею в ftp. Самоирония невообразима? Ну, ну.
Короткими предложениями: лучше?
Да, слишком мастерска была. И слишком иносказательна. :)Снимаю шляпу, редко встретишь на форуме признание своей, даже маленькой, ошибки.
> А как способ скачивания/закачивания файлов?HTTP и впрямь имеет горку преимуществ, кроме глоббинга (которое преимущество о двух концах -- удобно для DoS). Кстати, lftp умеет и HTTP :)
А какая есть альтернатива FTP на предприятии? WebDav? Нужно что бы тупые пользователи, на винде, могли залить информацию без установки дополнительного ПО и еще более тупые пользователи могли скачать эту информацию просто кликнув по ссылке( что бы как и с фтп можно было включить логин и пароль в состав ссылки) Подскажите пожалуйста.
smb
и чем тебе WebDav плох? работает
В венде реализация клиента оч корявая.
http://netlab.dhis.org/wiki/ru:software:nginx:webdav
sftp
> sftpХреновато в Венде. Как так с поддержкой SDCSA и SD25519?
>> sftp
> Хреновато в Венде.winscp, filezilla?
>>> sftp
>> Хреновато в Венде.
> winscp, filezilla?Вопрос не в клиентах, а в поддержке алгоритмов на эллиптических кривых, используемых SSH: ECDSA и ED25519. RSA/DSA всё таки старые и, не исключено, что от них рано или поздно откажутся.
Уже год как пусси умеет ECDSA и чуть меньше как винсцп это себе втащил.
Только пусси надо качать не релиз а дев версию, хз чего они слоупочат.
> Вопрос не в клиентах, а в поддержке алгоритмов на эллиптических кривых, используемых SSH: ECDSA и ED25519.Это вообще вопрос не к ОС, а к установленным пакетам.
Само по себе ядро linux ни установит, ни примет шифрованное соединение, ни на кривых, ни по RSA.
Это делает SSH - обычный пакет (обычно openssh), который обычно опирается на либы openssl/libressl/gnutls.
А эти пакеты и либы можно установить и в windows, macos, и.т.д.
Поэтому вопрос "умеет ли это windows" некорректен.
>>>> sftp
>>> Хреновато в Венде.
>> winscp, filezilla?
> Вопрос не в клиентах, а в поддержке алгоритмов на эллиптических кривых, используемых
> SSH: ECDSA и ED25519. RSA/DSA всё таки старые и, не исключено,
> что от них рано или поздно откажутся.Даже RSA/DSA всё же лучше, чем открытый ФТП!
>> sftp
> Хреновато в Венде. Как так с поддержкой SDCSA и SD25519?В оффтопике, априори, с безопасностью хреново!
Но FileZilla вполне умеет по ed25519 подключаться.
>>> sftp
>> Хреновато в Венде. Как так с поддержкой SDCSA и SD25519?
> В оффтопике, априори, с безопасностью хреново!
> Но FileZilla вполне умеет по ed25519 подключаться.Хоть кто-то научился из клиентов, работающих в Венде. :-)
на предприятии можно установить ftp сервер.
Конечно "очень тупые пользователи" не смогут скачать ничего с kernel.org. Это печально, но чем-то всегда придется жертвовать.
> После этого времени доступ к ресурсам будет осуществляться только по HTTP/ HTTPS.Скорее всего только по HTTPS...
Ви таки все дураки, одна я тут стою вся в белом! (С) Модам либерастНе то и не другое, будет только HTTP2, даже театров не будет! :-)
И кстати HTTPS2 для прокачки файлов уже не так плох ... а если взвесить всё костыли для обеспечения работы FTP (а уж если он должен быть хоть по минимуму секурным то и вовсе - КОСТЫЛИЩЩИ из кованной стали!) то ну его действительно!
Дедушка заслуженный, славно потрудился, но пора с почестями на пенсию.
Пусть вон - молодые пашут уже :)
Бедный фтп, так и фидонет скоро склеится
Это никак не связанные вещи.
Это obsoleteness.
На великий и могучий _приблизительно_ переводится как устаревание, не соответствие текущей реальности. Ну типа почему в нынешних армиях мира нет ни панцирников, ни мушкетёров? They are obsolette ...
Так же и тут - что FTN (Fido), что FTP уже не то ...
Ага и поэтому наследники Поттер-инга переизобретают UUCP
Привет )) https://github.com/Mithgol/phido
Главное, чтобы gopher не отключили.
Давно пора отправить FTP на заслуженный отдых. Практически все кейсы его использования покрываются либо HTTP либо SFTP (SSH File Transfer Protocol).Ещё туда же надо бы отправить SMTP и тому подобное и перейти на XMPP.
>Давно пора отправить FTP на заслуженный отдых.Школота с мозолистыми руками :) Нет конечно. http2 всего то пару лет как появился, а без него - без вариантов.
Но! http2 всё же появился - уже пора начитать готовить "отвальную" пьянку для FTP:)>Ещё туда же надо бы отправить SMTP и тому подобное и перейти на XMPP.
Без малейшего шанса :-\ Даже не упоминая что XMPP - **но, они тля ___разные___ задачи решают. SMTP пока заменить увы - нечем.
HTTP2 ни при чём, я уже лет 10 если ни больше не могу понять зачем люди продолжают поддерживать FTP при том, что для полноценной работы с удалёнными серверами есть SFTP, а скачивают файлы люди всё-равно по HTTP в основном.Про SMTP и XMPP - было бы интересно увидеть пояснение какие это разные задачи они решают. По-разному - да, но разные задачи - ну фиг знает: ни одной задачи, решаемой e-mail и не решаемой Джаббером на вскидку не вижу. И там и там передача сообщений между адресами вида user@host, в первом случае в нагрузку тяжёлым наследием 7-битного legacy, во втором с человечкской кодировкой, почти реальным временем (ну, по сравнению), расширениями и вот этим всем...
> ну фиг знает: ни одной задачи, решаемой e-mail и не решаемой Джаббером на вскидку не вижуЕсть очень простая задача - передать послание между людьми, у которых есть email и нет jabber.
Нужно признать, что email смог стать чем-то универсальным, за счет чего можно общаться двум любым людям.
Email сейчас есть у миллиардов.А jabber - никогда не знаешь, как настроен jabber сервер на конкретном домене.
Вдруг там выключен server2server?
Или ещё какие-то неочевидные настройки.
И всегда остается вопрос, есть ли у человека jabber.
У почты есть несколько неочевидных, как оказывается, плюсов:1) Архив переписки. Сравните удобство хранения и поиска всяческих договоренностей в корпоративной переписке и в почте. Попробуйте что-то найти в хистори вашего джаббера.
2) Групповые обсуждения. Никто в здравом уме не будет обсуждать важные вопросы в "чатике" пусть и официальном корпоративном. Только почта, только хардкор. Надо кого-то добавить в копию, в скрытую копию, для части обсуждения... Ни один групповой чат пока этого не реализует.
> 2) Групповые обсуждения. Никто в здравом уме не будет обсуждать важные вопросы
> в "чатике" пусть и официальном корпоративном. Только почта, только хардкор. Надонаоборот - только %^@%@ *обсуждают* вопросы (и важные, и неважные) почтой.
Все остальные предпочитают живое общение (неважно, online или нет) - потому что иначе это не обсуждение, а вялое пинание. (/me с матом закрывает уведомление об очередной забронированной переговорке)> кого-то добавить в копию, в скрытую копию, для части обсуждения... Ни
угу, гугли "всем чмоке в этом чятике". В настоящих чатах, как раз, крайне редко что-то улетает не предназначенным для этого получателям.
Преимущества почты совершенно не в этом, а в том, что она принципиально оффлайновая, и заставляет (или позволяет) сперва подумать, а потом бросаться лупить по клавишам. (остальное, в том числе и удобство в разгребании древних мусорок - всего лишь следствие этого)
Ну и да - всем понятна и всем доступна, людей у которых нет постоянного почтового адреса, надо еще поискать. Жаббер даже если и есть - часто живет недолго, никто особо эти "user@host" не бережет (в том числе потому что именно @host, а не @domain, который в почте может быть личным)
Ну и отдельно - существующие жаберосервера по надежности и защищенности рядом с даже древним сендмэйлом не валялись. Пока неуловимый джо нахрен никому не нужен - это прокатывает.
Многие вопросы в живую решаются хуже, потому-что перед тем как написать ответ, человек всё-таки немного больше задумывается, может взять паузу для уточнения каких-то вещей или внешних консультаций, а вот в кабинете из 5-10 человек прийти к компромиссному решению здраво оценив ситуацию весьма сложно, конечно если это не просто голосование по выбору одного из трёх предварительно предложенных вариантов.
> У почты есть несколько неочевидных, как оказывается, плюсов:
> 1) Архив переписки. Сравните удобство хранения и поиска всяческих договоренностей в
> 2) Групповые обсуждения. Никто в здравом уме не будет обсуждать важные вопросы
> в "чатике" пусть и официальном корпоративном. Только почта, только хардкор. Надо+1 Эти же профиты отличают ML-культуру (f.e.LKML) многих СПО проектов от веб-да-ноль-ных гитхубиковых пуль-реквестов. Review патчей _перед_ коммитом в "master" тоже где-то там... в списках рассылки.
> HTTP2 ни при чём,а, мы-то думали ты хоть немного шаришь в том, о чем говоришь. http2 - на сегодня единственный общедоступный (кхе-кхе) протокол, хотя бы в теории приспособленный для передачи бинарных данных, а не текста в обертке.
> я уже лет 10 если ни больше не могу понять зачем люди продолжают поддерживать FTP при
> том, что для полноценной работы с удалёнными серверами есть SFTPпотому что я не хочу давать возмонжость "полноценной" работы с моим сервером кому-то, кому надо просто скачать файлик. А sftp - побочный выпердыш _удаленного_шелла_. И то, что основные грабли там кое-как прикрыты тряпочкой, совершенно не гарантирует от прилета ручки по лбу в самый неожиданный момент.
При этом, зачем тебе нужен шифрованный туннель для получения общедоступного файла с проверяемой (в виду доступности множества разных источников) контрольной суммой - мне не понять.Причем все проблемы (на самом деле, конечно, не проблемы а рыдовы страдания от косорукости полубесплатных админов) на которые жалуются kernel.org, там никуда не деты, и даже возведены в энную степень (в частности, опять же, потому что ftp все же изначально был задуман как public service, а вот авторы sftp никогда даже не помышляли о таком).
> а скачивают файлы люди всё-равно по HTTP в основном.
люди тупы - в принципе. Ты вот прекрасно это демонстрируешь.
> Про SMTP и XMPP - было бы интер
мне, к сожалению, неинтересно, пусть другие отдуваются.
Почтой бумажной айфонопоколение, видимо, никогда не пользовалось, и смысл ее им непонятен.
помнится лет 10 назад настроишь каждому юзеру в интернет, кэширование, проксирование, файрволл общий - на все про все один вечер. А потом начинается - я не могу скачать драйвера с hp. Почему? потому что ftp. Начинаешь вспоминать, что это такое, и какого х.. оно через файрвол не робит, и что на до сделать с бедным iptables. В итоге понимаешь что нафиг не нужно тратить столько драгоценного времени на всего лишь такую простую вещь как инет шлюзе с контролем доступа
> Неэффективность протокола и связанная с этим необходимость применения обходных путей в настройке межсетевых экранов и балансировщиков нагрузки;Сначала я подумал, что они о безопасности пекутся. А им просто лень фаерволл настраивать.
Недорого настрою Application-level gateway :)Феерически ленивые товарищи - одна строчка в конфиге Cisco... :)
Сложно усомниться в компетентности обслуживающего персонала kernel.org и уж конечно, они знакомы с теорией построения Stateful Inspection Firewall.Но, речь идёт о том, что File Transfer Protocol реализуемый сторонними программными продуктами, более не отвечает требованиям политики безопасности принятой kernel.org. И наличие или отсутствие Application Level Gateway у Cisco или Juniper, не коим образом не может повысить безопасность стороннего FTP сервера, который они используют.
Именно по этой причине, они приняли вынужденное решение, прекратить поддержку предоставления доступа к ресурсам kernel.org по протоколу FTP.
Вообще-то ftpd - вещь достаточно отлаженная и надежная, новых фичь в протоколе не появлялось сто лет как, протокол - достаточно простой для реализации и миллионы глаз давно должны были выловить все ошибки в коде. :)
Но видимо миллионы глаз плохо помогают, да? :)
Кроме того в новости указаны и другие причины, балансировка нагрузки и акселерации является либо не возможными, либо слишком сложными. К тому же, когда мы говорим о Application Level Gateway, мы должны помнить, что он значительно медленнее стандартного Packet Filtering или Stateful Firewall, ввиду потребности его обработки на process level. Поэтому они взвесили все за и против, и приняли решение, которое мы все обсуждаем сейчас.
> Недорого настрою Application-level gateway :)
> Феерически ленивые товарищи - одна строчка в конфиге Cisco... :)Там ещё нагрузку нужно держать и балансировать.
Странно, что их CDN не умеет в ftp.
> Там ещё нагрузку нужно держать и балансировать.dns round-robin обычно вполне достаточен (к счастью, ftp не требует ничего для этого настраивать)
> Странно, что их CDN не умеет в ftp.ничего странного,увы.
Вообще-то там ещё и rsync://kernel.org работает. Странно, что ни один зануда об этом не вспомнил.
а мне вот удобно было тарболлы тянуть именно по фтп. просто потому что консольный ftp не требует знаний кучи ключей, а сам протокол простой cd ls get, все.
да и я уверен по безопасности кода, vsftpd уделает все http серверы вместе взятые.короче как всегда лишьбы миллионам мух угодить, а на пользователей, которые пользовались фтп им наплевать.
> да и я уверен по безопасности кода, vsftpd уделает все http серверы
> вместе взятые.напрасно, он отвратителен (хуже только pro, но тот из-за изобилия [мис]фич) и дыры в нем были крайне серьезные. Но для ридонли анонимоус-онли сервера ни тот, ни другой не нужны.
Я бы еще поставил что-нибудь интересное, что ломает доступ из браузеров - это несложно, и эффективно отсекло бы тех, кому нафиг не нужен ftp-протокол.> короче как всегда лишьбы миллионам мух угодить, а на пользователей, которые пользовались
> фтп им наплевать.отдельный прикол - зачем, собственно, миллиону мух исходники ведра линукса с kernel org?
Впрочем, подозреваю, в данном случае миллионом мух выступили хозяева их cdn'а, которым совершенно не нужен ftpd.
> а мне вот удобно было тарболлы тянуть именно по фтп. просто потому
> что консольный ftp не требует знаний кучи ключей, а сам протокол
> простой cd ls get, все.
> Вообще-то там ещё и rsync://kernel.org работает. Странно, что ни один зануда об
> этом не вспомнил.а чего хорошего в рсинке (если только ты не мирроришь их целиком) для передачи одиночных огромных файлов?
Странно что да, рукожопых админов кернелогра это совсем не беспокоит (наверное, действительно, не вспомнили, тем более что с настройкой файрвола для него проблем нет. С решeтом в самом rsync'е (from the people who brought you samba) проблем, конечно же, у них тоже "нет". Хотя, да, а как же, как же "cdn" ?)
> Странно что да, рукожопых админов кернелогра это совсем не беспокоит (наверное,
> действительно, не вспомнили, тем более что с настройкой файрвола для него проблем нет. С
> решeтом в самом rsync'е (from the people who brought you samba) проблем, конечно же, у них
> тоже "нет". Хотя, да, а как же, как же "cdn" ?)Ну, аккуратнее про "рукожопых". %)
Мы используем haproxy для load-balancing и для упрощения поддержки ipv6 и для настройки ftp и ftp-data необходимо вставлять в конфигурацию грустные грабли. Вдобавок, поскольку сам vsftpd находится на внутренней сети, ему необходимо знать через который внешний IP-адрес зашел пользователь чтобы ему правильно отправить PORT команду.
Если кому-то нравится листать директории через терминальную утилиту, то для этого имеется lftp, который отлично имитирует ftp-доступ без множества заморочек. Попробуйте сами:
KR
kernel.org
у ftp есть главный плюс - я могу открыть в mc панель с ftp и панель с локальной директорией, затем нажать кнопку 'сравнить директории' и затем уже вручную, пользуясь нужным методом сортировки, отметить нужное/разотметить ненужное. это очень быстро и очень просто.
быстро и просто - это скучно, чувак. теперь тебе придется для этой задачи накатить fuse кое-нибудь.
> у ftp есть главный плюс - я могу открыть в mc панельосспаде... XXI век, а у них все месе с панелями...
> с ftp и панель с локальной директорией, затем нажать кнопку 'сравнить
> директории' и затем уже вручную, пользуясь нужным методом сортировки, отметитьдля этого существует rsync как раз - быстро, просто, и без дурацкого ручного отмечания "нужного".
правда, для kernel.org совершенно лишнее.
>для этого существует rsync как раз - быстро, просто, и без дурацкого ручного отмечания "нужного".Что быстро? Что просто? Ты когда в последний раз через rsync качал ТОЛЬКО файлы, которые тебе нужны? Походу, никогда. Так вот через rsync это делается через выкачивание списка всех файлов, потом ТЫ сам смотришь, что тебе нужно и не нужно, а после формируешь список хотелок и передаешь его rsync. Вручную.
>правда, для kernel.org совершенно лишнее.Что лишнее? Браузинг по директориям через клиент ftp? Где нормальный файло-браузер для веб-браузера? Нигде. Нормальный это тот, что умеет в хоткеи, настраивается все от цветов до шрифтов, а также умеет настраивается в заданное кол-во соединений, ограничения скорости.
Троль, лжец и девственник --- вот ты кто.
> Что лишнее? Браузинг по директориям через клиент ftp?в том числе.
Имя (вместе с путем) нужного файла на kernel.org мне становится известно в тот момент, когда я понимаю, что он мне зачем-то стал нужен, я, как правило, даже не захожу туда интерактивно (благо, имеющийся ftp-клиент умеет html-style url. Там, правда, есть и tab completion, но для kernel.org он тоже ненужен). Потому что они там совершенно предсказуемы.> Троль, лжец и девственник --- вот ты кто.
мухахахаа..
И да, единственное назначение mc - это копание файлопомоек. Что локальных, что ftp'шных. Ну, для тех, конечно, кто умеет что-то еще.
>Стагнация разработки приложений с реализацией FTP и отсутствие регулярных обновлений. >Прекращение использования FTP позволит повысить безопасность инфраструктуры за счёт >сокращения публично доступных сервисов.Фтп-серверы и клиенты написать написали, а поддерживать и обновлять - влом. Вот почему в Арче дропнули ProFtpd