LINUX.ORG.RU

Предлагаю сделать в пакетных менеджерах получение пакетов по ipfs или zeronet

 , , , зеркало дистрибутива,


0

0

Навеяно это новостью о уязвимости apt при закачке пакета по http и о причине по которой debian в своё время не хотел делать закачку по https по умолчанию.
Причина эта проста - https создаёт большую нагрузку на сервер и создаёт больший объём трафика.

Создание зеркала на основе пиринговой сети должно решить сразу две обе эти проблемы, потому что раздача через пиринговую сеть создаёт большую нагрузку только вначале и потом требует присутствия оригинальной закачки только как резерва с полной копией блоков.

Опасения что процесс боотстрапа клиента пиринговой сети может оказаться слишком долгим можно решить тем что дистр создаст собственную боотстрап ноду которой в клиенте даст найбольший приоритет для получения первоначального списка пиров, но при этом не будет её регистрировать в общем списке боотстрап нод, чтобы для неё не создавалась дополнительная нагрузка.

И так достоинства


  • Получение файлов через ipfs достаточно просто реализовать, для этого даже не нужен отдельный транспорт, просто соответствующая директория указывается как локальный репозитарий.
  • Снижается нагрузка на оригинальный сервер, можно использовать менее дорогое оборудование.
  • Снижается объём трафика на сервере так как основная нагрузка будет распределена по личерам и сидерам и как следствие требуется канал в интернет с меньшей пропускной способностью и требованием к *качеству* интернета что позволит сократить расходы на интернет без создания неудбства пользователям.
  • Упростится создание и регистрация зеркал дистра.
    Для создания зеркала потребуется всего лишь откешировать у себя в клиенте соответствующий адрес, при этом регистрировать такое зеркало не требуется, оно будет участвовать в сети как обычный клиент-сидер сразу после его создания.
  • При этом надо учитывать, что упрощение создания зеркала приведёт к росту числа зеркал, потому что зеркала будут создавать те, кто раньше этого не делал из-за нежелания преодолевать трудности(регистрировать домен, арендовать сервер с надёжным подключением к интернету и всё это оплачивать, зеркало на основе пиринговой сети не нуждается ни в том и ни в другом и может вносить свой вклад в распространение пакетов дистрибутива через домашний канал, так как в пиринговых сетях качество канала к отдельному сидеру не важно, один и тот же фаил может закачиваться от нескольких сидеров паралельно)



П.С. Жалко что пакета с ipfs нет в Debian Buster, пора бы ему появиться.

★★★★★

Последнее исправление: torvn77 (всего исправлений: 8)

Ответ на: комментарий от Atlant

При таком подходе это никто не захочет делать так как будет слишком много работы.
Усилия же для задействования ipfs будут минимальны.

Во вторых важно чтобы используемый протокол предусматривал изменение раздаваемого контента.
По этому например торрент для этого не подходит, так как при каждом изменении надо надо будет перекачивать торрент фаил и полностью перехешировать раздачу.

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от mord0d

Но ведь не вбросил, а предложение хорошее и главное не так тяжело реализуемое.

Что такое РоС?

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от aureliano15

Если так то единственное что приходит в голову это
1. Создать на числодробилке пару ключей с тем же ipfs адресом и попытаться подсунуть изменённый репозитарий, но скорее всего тогда надо изолировать атакуемую систему от всех нод ipfs, кроме нод злоумышленника.
2. Восстановить на числодробилке приватный ключ раздающей ноды.
. В принципе, если учесть большой объём передаваемых файлов это должно быть возможным.
Но прямой связи apt и ipfs не будет, ресурс буде подключен как локальный репозитарий и подмена по идее должна быть выявлена стандартными средствами apt, ну или другого пакетного менеджера.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от torvn77

используемый протокол предусматривал изменение раздаваемого контента.

хм, а как раз ipfs в основном для неизменного контента.
Тогда уж лучше использовать Metalink
Там как раз почти все протоколы могут быть описаны
P.S. да и клиентов для него завались уже.

Atlant ★★★★★
()
Последнее исправление: Atlant (всего исправлений: 1)

тег: emerge
уязвимости apt

Всего-то надо было посчитать чесуммы deb-пакетов, как в манифесте портажа. Также подписать манифесты (или как там называется реестр пакетов в дебиане), как делается в последнее время в портаже.
А то сразу решать проблему артхитектуры (города) посредством (общественного) транспорта. Таксистов не хватит, не говорю про беспрерывные стихийные демонстративные пробки перед зданием мерии.

anonymous
()
Ответ на: комментарий от torvn77

Восстановить на числодробилке приватный ключ раздающей ноды. В принципе, если учесть большой объём передаваемых файлов это должно быть возможным.

Имхо, если это возможно (я не знаю, возможно ли, но если так), то это – серьёзная уязвимость. Ведь тогда кто угодно может прикинуться кем угодно и раздавать что угодно. Или я чего-то не понимаю.

aureliano15 ★★
()

Какая-то туфта, достаточно множества зеркал + свой http proxy + цифровые подписи. Быстро и надежно. Накрайняк имеет смысл socks 5 proxy / ipsec vpn; все эти сети по образу Tor не для выкачки по гигу за минуту.

menangen ★★★★★
()
Ответ на: комментарий от aureliano15

Любой ключ можно восстановить если файлы известны в зашифрованном и расшифрованном виде и этих файлов достаточное количество.

Например так набрав кучу публичных ключей из мониторов Китайцы на горе копирастам смогли восстановить мастер ключ HDCP.

Это фундаментальное свойство шифрования и это *notabug*.

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от menangen

В чём туфта то?
Инфраструктура как раз и со стороны сервера и у клиента упрощается, плюс снижаются требования к надёжности сети в целом.

Зачем делать свою проксю если проксей будет ставящий ОС в соседней квартире сосед?

Для зеркала нужен домен, здесь же для зеркалирования будет достаточно начать раздавать свою локальную копию, при чём это можно будет начинать и прекращать в любое время, чего с зеркалом делать нельзя.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от torvn77

Любой ключ можно восстановить если файлы известны в зашифрованном и расшифрованном виде и этих файлов достаточное количество.

Это понятно. Вопрос в том, идёт ли речь о теоретической возможности (если супер-компьютер НАСА будет работать 8 тыс. лет ...) или о вполне практической (любой 8-ядерный комп взломает за 1 день, ну или как вариант можно взломать за 2 дня, используя ботнет). Если второе, то, имхо, способ ненадёжный.

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

Скажу так, Китайцам для восстановления ключа потребовался кластер, но как там написали этот кластер решал огромную ЛИНЕЙНУЮ систему уравнений.
То есть при некотором наборе материала восстановление ключа неизбежно причём за допустимое для расшифровывающего время.

Но надо понимать то, что материала надо очень много.

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 1)

Я тебе разрешаю. Делай.

anonymous
()
Ответ на: комментарий от torvn77

То есть при некотором наборе материала восстановление ключа неизбежно причём за допустимое для расшифровывающего время.

Это не проблема, если регулярно менять ключ. Но чем чаще меняется этот самый ключ, тем чаще устаревают абсолютно все файлы в сети (в т. ч. и актуальные). Т. е. вопрос сводится к минимально необходимой частоте смены ключа с одной стороны и затратам, связанным с полным обновлением всех зеркал с такой же частотой — с другой. Думаю, как-то так, хотя могу и ошибаться.

aureliano15 ★★
()

Во-первых ipfs ненужно, т. к.

Troubleshooting

Help!

If you have any problems, come get live help at #ipfs or via the mailing list.

Check Go Version

IPFS Documentation - Install IPFS

Во-вторых, ok, ты «упростил» синхронизацию между серверами. Что делать тем, кто не хочет\у кого нет места под зеркалирование целого репозитория ради сотни пакетов?

mogwai ★★★★
()
Ответ на: комментарий от torvn77

Мэн мен не надо может лучше на оборот все репозиторий отключить и просто всем на экран светануть типа качайте теперь deb пакеты вот такой то спец сайт и.т.д , а то зонды и в man сидят и частично в этих сракотанских трекерах

anonymous
()
Ответ на: комментарий от torvn77

А , знаешь почему ? Потому что хватило и гугл сервисов что бы телефон с 512 мемори уходил в дауншифт

anonymous
()
Ответ на: комментарий от anonymous

Да потому что хватит обновлять систему не налаживая её , вот смотри суть какая васян или корпопораши прогеры не задумываясь спросить как васян создал дистрибутив берут и начиняют его новыми программами в итоге ломают какой нибудь модуль который до этого работал , там каждый файлик имеет правило типа 777 и другие и не дай бог что бы какой нибудь фаил на чтение там где не нужно просто тупо не поставил раком

anonymous
()
Ответ на: комментарий от anonymous

Это не имеет отношения к делу потому что пакеты с программами будут только браться из ipfs или иной распределённой системы, а ставится они будут стандартным образом через apt.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от mogwai

Что делать тем, кто не хочет\у кого нет места под зеркалирование целого репозитория ради сотни пакетов?

Даже в bittorrent нет необходимости качать торрент целиком чтобы закачать один файл, думаю что в ipfs будет тоже самое, да и в других актуальных распределённых сетях тоже.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от torvn77

Там вся проблема в кривом апт и наплевательском отношении к цифровым подписям пакетов. Лично я вижу смысл в быстрых протоколах типа uTP поверх UDP из кеша системных пакетов. А к центральному репозиторию / зеркалам / CDN обращаться по HTTP2 / новым протоколам на базе tls over udp.

menangen ★★★★★
()
Ответ на: комментарий от menangen

Там вся проблема в кривом апт и наплевательском отношении к цифровым подписям пакетов.

А я не только изза этой уязвимости предлагаю, почитай внимательно, переход на распространение через пиринговую сеть должен вообще существенно упростить жизнь.

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от torvn77

Это все сведётся к DHT, а это не быстро работает, если только не держать на зеркалах и офф репозитории аналог статичной DHT ноды, но в DHT ты качаешь с рандомного узла, а не с того, который «сосед через стенку», а надо бы с ближайших скоростных узлов.

menangen ★★★★★
()
Ответ на: комментарий от menangen

ично я вижу смысл в быстрых протоколах типа uTP поверх UDP из кеша системных пакетов.

Нагрузку на сервер и объём трафика это сильно не изменит и к сокращению расходов не приведёт.
Да и конечный юзер не сможет тянуть пакует на всех 100 МБ/сек.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от menangen

Это уже детали, мало какой хостинг по скорости закачки сможет переплюнуть торрент с 15 сидерами.
И это только те сидеры, которых я вижу.

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 2)
Ответ на: комментарий от torvn77

У торрента поиск нод долгий. 1-2 минуты только найти сида и постоянный поиск новых (т.к. на одной ноде может не быть нужных файлов-пакетов; много системных пакетов весит по 3-8 КБ, по HTTP2 быстрее выкачаются.

menangen ★★★★★
()
Ответ на: комментарий от menangen

1. Основные пакеты будут у всех.
2. Пакеты можно будет закачивать параллельно, по этому общее время закачки будет меньше чем суммарное время закачки пакетов.
3. Идёт ли установка дистра с нуля или просто обновляешся отдал команду и забыл минут на 20 и что там с какой скоростью будет происходить неважно.
Да и не всегда торрент ищется две минуты, на худой конец можно свой трекер завести или его функциональный аналог.
Но что важно снизятся расходы на главный сервер и канал интернета у дистрибутива.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от torvn77

Это не имеет отношения к делу потому что пакеты с программами будут только браться из ipfs или иной распределённой системы, а ставится они будут стандартным образом через apt.

Каким образом? Какой компонент за что будет отвечать, каким образом они будут взаимодействовать?

ps: не могу привыкнуть, что на лоре отступ делать надо после цитат

mogwai ★★★★
()
Последнее исправление: mogwai (всего исправлений: 1)
Ответ на: комментарий от torvn77

Даже в bittorrent нет необходимости качать торрент целиком чтобы закачать один файл, думаю что в ipfs

Эм… торент клиент сам парсит раздачу, сам её качает, а ты потом вручную смотришь и открываешь то, что уже скачалось. Ты же в ОП пишешь:

…для этого даже не нужен отдельный транспорт, просто соответствующая директория указывается как локальный репозитарий.

Каким образом пакетный менеджер узнает, что этот файл уже скачался, этот ещё качается, а этот стоит в очереди?

mogwai ★★★★
()
Ответ на: комментарий от mogwai

Упрлс? Безопасный язык с нормальными протоколами и форматами из коробки. Если бы apt писали на нём, не было бы соблазна велосипедить свой кривой протокол.

anonymous
()
Ответ на: комментарий от torvn77
  1. Основные пакеты будут у всех.

Что есть «основные»? Ты репозитории перекраивать собрался? И с чего ты решил, что у пользователя есть лишние даже 10Gb под хранение «основных» пакетов?

отдал команду и забыл минут на 20 и

Это сейчас за 15 минут система устанавливается. Тебе уже сказали, про время на поиск пиров.

на худой конец можно свой трекер завести или его функциональный аналог.

Т.е. раздавать файлы напрямую с сервера? От чего уходили, к тому и пришли.

Но что важно снизятся расходы на главный сервер и канал интернета у дистрибутива.

Расчёты покажешь? Или ты пальцем в небо ткнул?

mogwai ★★★★
()
Ответ на: комментарий от torvn77

и главное не так тяжело реализуемое.

Ну так реализуй. Хотя бы для одного менеджера пакетов.

Что такое РоС?

Proof of concept.

mord0d ★★★★★
()
Ответ на: комментарий от torvn77

Сессионные ключи должны частично решать проблему - вместо шифрования главным ключом гигабайт файлов, мы шифруем лишь несколько сотен бит сессионного ключа. Материала для анализа мастер ключа становится на порядок меньше.

KivApple ★★★★★
()
Ответ на: комментарий от mogwai

Что есть «основные»?

Это пакеты которые будут установлены при выборе минимальной установки в инсталяторе, ну и в случае десктопа распространённые программы: xorg,libreoffice,firefox,mplayer,ffmpeg,pulseaudio навряд ли ваша установка десктопа не будет содержать хотябы одной из них, у большинства же они скорее всего будут все сразу.

Это сейчас за 15 минут система устанавливается.
Тебе уже сказали, про время на поиск пиров.

Я понимаю так, что по вашему мнению транспорт для ipfs уже написан и 20 мин не высосаны из пальца, а есть реальное время закачки пакетом этим транспортом по ipfs.
Только тогда почему в этой теме я предлагаю создать такой транспорт, а не улучшить его для уменьшения времени работы?

на худой конец можно свой трекер завести

Т.е. раздавать файлы напрямую с сервера?

Позор ЛОРа, трекер не раздаёт файлы, он передаёт личерам информацию о сидерах, эдакий список из 15~40 IP адресов.

Расчёты покажешь? Или ты пальцем в небо ткнул?

Изучи что такое децентрализованные сети и как они работают, после выдачи *сервером* одной копии файла может вообще никогда не возникнуть необходимости делать это повторно.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от menangen

Не обязательно «с рандомного».

Во-первых первый запрос проходит на все узлы с которыми есть прямое соединение.

Во-вторых скачивание происходит с узла с минимальным пингом (не уверен, но вроде заявлялось.

В-третьих, если mDNS обнаружение соседей работает - у тебя всегда будут достаточно «быстрые» узлы рядом.

А если всё это сфейлило - тогда да, перебираем уже узлы по XOR метрике...

Scondo
()
Ответ на: комментарий от mord0d

Ну так реализуй. Хотя бы для одного менеджера пакетов.

Для этого надо немного, ну для начала просто чтобы обновлятся дебиановцы должны расшарить корень репозитария через ipfs и опубликовать параметры доступа к нему.
Ну а я этот корень у себя смонтировав пропишу точку его монтирования как локальный репозитарий.
Далее обычный apt update&&apt upgrade

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от Scondo

А пакетный менеджер в это время будет «висеть»? Он же не скачивает 10 пакетов одновременно, пакеты уже «есть» локально на диске, он их по одному устанавливать будет. Снова упёрлись в то, что оно работать будет гораздо медленней.

mogwai ★★★★
()
Ответ на: комментарий от mogwai

Ну при такой реализации - да.

можно просто добавлять URL на локальном шлюзе IPFS http://127.0.0.1:8080/ipfs/Qmc7k1DbyNNkjwU29rAo1h9yKvf4fsfaczs6MJVAn1hDmb

На самом деле я не пытаюсь агитировать за идею: мой опыт работы с IPFS говорит, что он пока ещё сыроват.

Но тем не менее основные положения идеи «пакеты в IPFS» правильные и я считаю необходимым прояснить некорректно понимаемые вещи про природу IPFS.

Scondo
()
Ответ на: комментарий от mogwai

А пакетный менеджер в это время будет «висеть»? Он же не скачивает 10 пакетов одновременно,

Да, надо видимо будет кому-то дописать apt нужным образом.
Может вынести закачку в отдельный прописанный в переменной модуль, который просто будет получать список пакетов, ну а далее модуль последовательной загрузки будет закачивать как обычно, а модуль паралельной запускать в фон кучу копирований и ждать их завершения?

Но в любом случае это можно сделать потом, когда PoC из поста выше будет отлажен.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от Scondo

Но тем не менее основные положения идеи «пакеты в IPFS» правильные

Не обязательно IPFS, правильнее децентрализованной сети, какой пока не ясно.
Дело в том что мне написали что IPFS *в основном для неизменяемого контента*, правда почему не пояснили.
Но с другой стороны и не полностью возможность использования отрицают.

torvn77 ★★★★★
() автор топика
Ответ на: комментарий от torvn77

дебиановцы должны

а я [...] пропишу точку

То есть кто-то за тебя должен всё сделать, а ты будешь только пользоваться? Не катит.

Реализуй ноду, опубликуй инструкцию, я готов развернуть вторую. Если это взлетит — останусь на постоянной основе и даже накачаю пакетов на терабайт и буду их периодически обновлять; не взлетит — сверну лавочку через полгода.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

То есть кто-то за тебя должен всё сделать, а ты будешь только пользоваться? Не катит.

Ты и так всё для меня и за меня делаешь, а я пользуюсь и не плачу донаты.
Но в случае распространения через ipfs ты будешь меньше платить за сервер и интернет канал, а у меня возможно как тут правильно опасаются будут чуть медленнее закачиваться мелкие пакеты.
Хотя тянуть эту мелочь я буду на 10 Мб/сек, так что медленный поиск вполне может компенсироваться последующей скоростью загрузки.
Но в любом случае эта скорость будет не за твой счёт.

Ну и весьма вероятно что если будет ipfs или иная децентрализованная сеть то я зеркало сделаю и возьму на себя часть трафика.

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 4)
Ответ на: комментарий от mord0d

Реализуй ноду, опубликуй инструкцию, я готов развернуть вторую. Если это взлетит

Нода от Васяна не взлетит, надо чтобы её организовывал Дебиан.
Ну или если тебе просто надо ipfs протестить то могу и сделать, но опыты можно делать и на обычных аниме мультиках, зеркалировать огромный репозитарий пакетов для этого не нужно.

останусь на постоянной основе и даже накачаю пакетов на терабайт и буду их периодически обновлять

Если я правильно понимаю, то помещать файлы в ноду может только владелец ключа.
По этому обновлять поднятую мной ноду ты не сможешь, и на оборот.

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 4)
Ответ на: комментарий от torvn77

xorg,libreoffice,firefox,mplayer,ffmpeg,pulseaudio навряд ли ваша установка десктопа не будет содержать хотябы одной из них, у большинства же они скорее всего будут все сразу.

С чего ты решил, что я ставлю десктоп? С чего ты решил, что у пользователя есть место хранить «xorg,libreoffice,firefox,mplayer,ffmpeg,pulseaudio» для других пользователей, когда они ему никуда не упёрлись?

Получение файлов через ipfs достаточно просто реализовать, для этого даже не нужен отдельный транспорт

я предлагаю создать такой транспорт

Ты сначала определись, что ты предлагаешь.

по вашему мнению 20 мин не высосаны из пальца

По моему мнению, как раз, высосаны именно из пальца. И мозг во время высасывания не подключался.

трекер не раздаёт файлы, он передаёт личерам информацию о сидерах, эдакий список из 15~40 IP адресов.

В ситуации, когда сидов нет, как оно поможет? Или предлагаешь абсолютно всем компьютерам поддерживать соединение с трэкером и дёргать его не раз в несколько дней, когда обновления нужны, а сотни раз в сутки? Или ты считаешь, что это для сервера будет проще, чем раздать статику?

может вообще никогда не возникнуть необходимости делать это повторно. Нагрузку на поддержание актуального списка сидеров ты решил не учитывать, значит?

mogwai ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.