Комментарии 36
Интересно. Это такой упрощённый Pulp у вас получился (REST тоже поддерживается):
Вопрос вдогонку. Лицензия GPL v2.0, или необходимо связываться с вами для лицензирования в коммерческом продукте? Что подразумевается вами под коммерческим продуктом?
pulp-admin rpm repo create --repo-id myrepoИли repositor.io:
pulp-admin rpm repo uploads rpm --repo-id myrepo --file ./lalala-1.2-3.noarch.rpm
pulp-admin rpm repo publish run --repo-id myrepo
repositorio --repo=myrepo --initИли PackageCloud локальный.
repositorio --repo=myrepo --add-file=lalala-1.2-3.noarch.rpm
Вопрос вдогонку. Лицензия GPL v2.0, или необходимо связываться с вами для лицензирования в коммерческом продукте? Что подразумевается вами под коммерческим продуктом?
# Сервис для поддержания репозиториев (С) Sergey Pechenko, 2017
# Лицензия — GPL v2.0. Никаких дополнительных гарантий или прав не предоставляется.
# Для лицензирования использования кода в коммерческом продукте свяжитесь с автором.
И чтобы второй раз с места не вставать, Сергей, сколько стоит лицензия на ваш код для использования в коммерческом продукте? Спасибо.
Хорошо, вы связались. Как автор, сообщаю — данную кучку кода для использования в коммерческих продуктах не лицензирую.
Прошу извинить, не смог понять из комментария, хотите ли вы уточнить детали или просто троллите — выражения лица не вижу, интонаций не слышу, смайлики отсутствуют.
Мой посыл так же лёгок в понимании и прост, как гвоздодёр из титанового сплава: хотите этот код развивать и поддерживать как Open Source Software — пожалуйста. Хотите зарабатывать на нём деньги — вам придётся делать это вместе со мной, только и всего.
Мой посыл так же лёгок в понимании и прост, как гвоздодёр из титанового сплава: хотите этот код развивать и поддерживать как Open Source Software — пожалуйста. Хотите зарабатывать на нём деньги — вам придётся делать это вместе со мной, только и всего.
Не троллю. Просто не нужен этот код дома или в некоммерческих проектах — это во-первых. Во-вторых, GPL 2.0 прямо запрещает налагать дополнительные ограничения, как вы это пытаетесь сделать:
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.Нет никакого смысла пушить вам коммиты с фиксами и фичами, если использовать ваш код можно только в некоммерческих проектах.
Забавно. Вы — третий человек по счёту человек, который пытается уличить меня в нарушении GPL. Правда, предыдущие два сочли более уместным написать в личку, но воля ваша — обсудим вопрос здесь.
Предлагаю вам проверить по любому доступному словарю слово "redistribute", а затем привести в следующем комментарии ваш перевод этого слова и ваше понимание того, каким образом процитированный абзац применим ко мне как к автору данного кода.
Правильный ответ:
Автор имеет право налагать на код любые лицензионные ограничения, какие он сочтёт необходимым (хоть запускать код только в полнолуние, ночью, и на перекрёстке трёх дорог).
Если у вас есть дальнейшие вопросы — предлагаю до их обсуждения прочитать в ГК РФ ст. 1229, п.1.
Нет никакого смысла пушить вам коммиты с фиксами и фичами, если использовать ваш код можно только в некоммерческих проектах.
Вам решать, пушить что-то или нет, я-то вообще ничего от вас не требовал, а только выставил определённые ограничения. Хотите пользоваться кодом — соблюдаете ограничения и пользуетесь, не хотите соответствовать — не пользуетесь, в чём здесь проблема?
человек, который пытается уличить меня в нарушении GPLНичего подобного, не вас. Вы — copyright holder, и вольны делать что угодно. Нарушать будут те, кто будет использовать код: вы с одной стороны даёте возможность им пользоваться кодом под GPL 2.0, но с другой стороны, вы дополнительно ограничиваете права пользователей, что запрещено GPL 2.0.
О, важный момент. Я — «copyright holder». Приведите цитату, где написано, что «copyright holder» не может налагать дополнительные ограничения.
Прошу извинить, но перевода слова «redistribute» я так и не увидел, так же, как и соображения по поводу применимости этого слова ко мне — а ведь в п.6 лицензии именно тому, кто делает «redistribute», запрещается налагать дополнительные ограничения на пользователей.
Да и вообще, я слышал, что существуют двойные лицензии. Хочешь — работаешь с софтом как OpenSource, не хочешь — связываешься с автором и получаешь лицензию на закрытый код. Или врут?..
Прошу извинить, но перевода слова «redistribute» я так и не увидел, так же, как и соображения по поводу применимости этого слова ко мне — а ведь в п.6 лицензии именно тому, кто делает «redistribute», запрещается налагать дополнительные ограничения на пользователей.
Да и вообще, я слышал, что существуют двойные лицензии. Хочешь — работаешь с софтом как OpenSource, не хочешь — связываешься с автором и получаешь лицензию на закрытый код. Или врут?..
Приведите цитату, где написано, что «copyright holder» не может налагать дополнительные ограничения.Ничего подобного нет в лицензии, о чём я написал выше: вы — copyright holder, и вольны делать что угодно.
соображения по поводу применимости этого слова ко мнеРечь не о вас, я написал об этом выше: нарушать будут те, кто будет использовать код.
http://www.repositor.io/ уже не работает.
Pulp — более сложный в установке, чем скрипты в этом посте.
Установку PackageCloud локально я не нашел. Может плохо искал.
Про repositor.io не удивительно — не взлетело, закрылись. Pulp — да, какая-то дичь. Ну а PackageCloud — как обычно, за деньги: enterprise.packagecloud.io.
P.S. Указанные скрипты до сих пор (уже три года!) работают.
P.S. Указанные скрипты до сих пор (уже три года!) работают.
Не совсем понял, зачем сложность с тредами. Почему не просто gunicorn с gevent воркером?
В большом репозитории операция обновления метаданных занимает отнюдь не нулевое время, поэтому я изначально решил, что запускать обновление по событию «загрузка» — не вариант: элементарная ситуация «гонок», когда обновление после предыдущей загрузки ещё идёт, а уже в наличии следующая загрузка, напрочь ломает весь концепт.
Закладываться на то, что эта ситуация никогда не возникнет, я счёл бессмысленным — своими глазами видел, как при почти одновременных загрузках пакетов в один из коммерческих репозиториев (правда, в бесплатной версии) файл с метаданными просто обнуляется в размере. Подобная потеря данных может быть одним из признаков «гонок», то есть некорректной обработки многопоточного доступа. Отсюда и необходимость обработки подобной ситуации.
Я не берусь утверждать, что мой подход — единственно правильный, но факт использования очереди «под капотом» того же Pulp может быть косвенным подтверждением моей позиции.
Закладываться на то, что эта ситуация никогда не возникнет, я счёл бессмысленным — своими глазами видел, как при почти одновременных загрузках пакетов в один из коммерческих репозиториев (правда, в бесплатной версии) файл с метаданными просто обнуляется в размере. Подобная потеря данных может быть одним из признаков «гонок», то есть некорректной обработки многопоточного доступа. Отсюда и необходимость обработки подобной ситуации.
Я не берусь утверждать, что мой подход — единственно правильный, но факт использования очереди «под капотом» того же Pulp может быть косвенным подтверждением моей позиции.
rsync сервер для заливки
Правило в unit в systemd для апдейта репы
Nginx для раздачи репы
И не нужно писать код
Правило в unit в systemd для апдейта репы
Nginx для раздачи репы
И не нужно писать код
У нас примерно тоже самое только через Jenkins:
Jenkins собирает пакет после merge в репозитории
Он же подписывает этот пакет (да-да в статье не написано, но это считается дурным тоном не подписывать rpm пакеты)
Он же заливает пакеты в репозиторий (через sshfs)
Он же обновляет мета-данные репозитория и подписывает их
И все настраивается красиво через WebUI. Непонятно зачем такие сложности с написанием своего велосипеда на Python
Jenkins собирает пакет после merge в репозитории
Он же подписывает этот пакет (да-да в статье не написано, но это считается дурным тоном не подписывать rpm пакеты)
Он же заливает пакеты в репозиторий (через sshfs)
Он же обновляет мета-данные репозитория и подписывает их
И все настраивается красиво через WebUI. Непонятно зачем такие сложности с написанием своего велосипеда на Python
Откровенно говоря, у меня для сборки пакетов тоже используется Jenkins, но мой опыт эксплуатации говорит о том, что делать из него «швейцарский нож» себе дороже. В моей ситуации работа Jenkins заканчивается на этапе отправки пакета на веб-сервер.
Насчёт подписи — да, подписи — это хорошо, но я не считаю для себя возможным обучать читателей правилам хорошего тона при сборке rpm-пакетов.
Кстати, чисто технически интересно, как в описанном вами варианте решён вопрос с гонками при одновременной заливке пакетов?
Насчёт подписи — да, подписи — это хорошо, но я не считаю для себя возможным обучать читателей правилам хорошего тона при сборке rpm-пакетов.
Кстати, чисто технически интересно, как в описанном вами варианте решён вопрос с гонками при одновременной заливке пакетов?
Так как всем управляет Jenkins, то у нас делается в два этапа:
— первая задача собирает пакет по триггеру из репозитория и кладет пакет в промежуточную директорию, в конце она вызывает задачу номер 2
— вторая задача смотрит что лежит во временной директории, подписывает, кладет в WebRoot, обновляет мета-данные и подписывает их
При этом у второй задачи в настройках указано — ждать если есть другие задачи в очереди, т.е. если у меня одновременно два (или больше) пакета собирается, то вторая задача не начнет выполнятся пока не появится окно между сборками. Чтобы особо долго не ждать можно выставить в настройках чтобы вторая задача ждала не дольше определенного времени. Т.е. я сначала аггрегирую пакеты которые уже готовы и вторая задача их все вместе зальет.
Еще в Jenkins можно отключить параллельное исполнение одной и той же задачи, т.е. даже если есть свободные воркеры, повторный вызов просто встанет в очередь.
— первая задача собирает пакет по триггеру из репозитория и кладет пакет в промежуточную директорию, в конце она вызывает задачу номер 2
— вторая задача смотрит что лежит во временной директории, подписывает, кладет в WebRoot, обновляет мета-данные и подписывает их
При этом у второй задачи в настройках указано — ждать если есть другие задачи в очереди, т.е. если у меня одновременно два (или больше) пакета собирается, то вторая задача не начнет выполнятся пока не появится окно между сборками. Чтобы особо долго не ждать можно выставить в настройках чтобы вторая задача ждала не дольше определенного времени. Т.е. я сначала аггрегирую пакеты которые уже готовы и вторая задача их все вместе зальет.
Еще в Jenkins можно отключить параллельное исполнение одной и той же задачи, т.е. даже если есть свободные воркеры, повторный вызов просто встанет в очередь.
Для тех, кто не хочет все это поддерживать есть ещё вариант купить Artifactory от Jrog. Приемущество этого продукта в том, что там из коробки порядка 20 поддерживаемых типов реп, что может быть удобно для задач DevOps.
Да, есть такой продукт, но лично для меня существуют несколько важных моментов:
На мой вкус, сравнивать работающий концепт, сделанный за выходные, и коммерческий продукт как-то нелогично, не находите? Я никогда не видел, чтобы велосипеды и суперкары участвовали в одних и тех же гонках.
А по поводу поддержки — сервис работает в существующем виде порядка двух месяцев, и мне его даже перезапускать не пришлось ни разу. Единственный озадачивший меня эпизод — когда Jenkins из-за ошибки в скриптах удалил всё в /tmp.
- изучение этого продукта не входило в мои задачи;
- мне требуется только три типа репозиториев из большого перечня возможностей продукта;
- а с точки зрения изначально решаемой задачи лично я не вижу смысла покупать лицензию на Artifactory, чтобы получить результат, аналогичный результату «проекта выходного дня»
На мой вкус, сравнивать работающий концепт, сделанный за выходные, и коммерческий продукт как-то нелогично, не находите? Я никогда не видел, чтобы велосипеды и суперкары участвовали в одних и тех же гонках.
А по поводу поддержки — сервис работает в существующем виде порядка двух месяцев, и мне его даже перезапускать не пришлось ни разу. Единственный озадачивший меня эпизод — когда Jenkins из-за ошибки в скриптах удалил всё в /tmp.
На мой вкус, сравнивать работающий концепт, сделанный за выходные, и коммерческий продукт как-то нелогично, не находите? Я никогда не видел, чтобы велосипеды и суперкары участвовали в одних и тех же гонках.
От чего же. На мой взгляд это чертовски важный концептуальный вопрос: надо ли делать велосипеды, когда есть готовое решение. На мой взгляд, если мы говорим о DevOps — нет. Ценность в DevOps представляет логика сборки и поставки продукта. В эту логику надо инвестировать время и деньги и следить за тем какие она дает результаты. Все остальное лишь инструментарий и заниматься его разработкой без крайней необходимости не следует.
Не выглядит как devops. Какой app.py? Где приложение в pypi? Где setup.py, где собственная rpm'ка? Плохо.
В мире дебиана всё лучше —
А вот у rpm'щиков это как-то всё похуже, как я вижу.
В мире дебиана всё лучше —
aptly наше всё, и оно отлично интегрируется с jenkins-debian-glue, gbp buildpackage, dpkg-buildpackage и всей остальной инфраструктурой сборки пакетов.А вот у rpm'щиков это как-то всё похуже, как я вижу.
А вот у rpm'щиков это как-то всё похуже, как я вижу.
Отнюдь, для простых случаев есть pulp, для devops есть jenkins+koji
А никто и не обещал, собственно говоря. В начале статьи обозначена задача, ниже приведён вариант её решения. Кому этого достаточно — будут пользоваться, кому мало — не будут. На мой взгляд, важно, чтобы у людей просто был выбор — ставить и поддерживать что-то огромное типа Pulp, либо закупать платные решения (кстати, всё равно потом их кто-то будет ставить и поддерживать), либо вот такие простые штуки использовать. Тут каждый сам для себя должен решить, что ему важнее.
А чем createrepo_c не подошел?
А никто не подскажет, есть ли свободные решения которые умеют делать virtual repo который объединяет в себе несколько других. В документации artifactory есть такое понятие Artifactory RPM Repositories. Было бы удобно централизовано подключить все нужные репы (epel/remi/zabbix/freeswitch/...), добавить туда свой локальный репозиторий, и представить в виде одного репозитория.
Да, у Artifactory такое есть.
Из бесплатных решений — у Pulp есть что-то очень похожее на «content sources».
Из бесплатных решений — у Pulp есть что-то очень похожее на «content sources».
Делал подобное. У меня это была связь apache и vsftpd. Без авторизации в web части просто доступ к файлам. С помощью mod_autoindex и кучи плюшек (jquery, bootstrap, font awesome, backbone и showdown для отображения markdown файлов) сделан интерфейс, при этом отсутствие javascript не приводит к поломке отображения файлов (привет noscript). Отдельная страничка для добавления файлов в репозиторий (ajax, multiple files — привет ie9) требует авторизации. На сервисе обслуживает PHP скрипт (сразу выполнил в едином файле и добавления файлов и обход по крону кучки для добавления, ну и запуск createrepo.). vsftpd без авторизации просто доступ к файлам, а с авторизацией доступ к директории загрузки (директория одна для всех и права запрещают просмотр что приводит к тому, что не видно ее содержимое но можно загружать файлы). При запуске php скрипта из крона проходит парсинг логов vsftpd (apache не парсится там сразу записывается в бд факт добавления файлов при обработке запросов из браузера) и записываем кто какие файлы добавил. Для разбора rpm файлов в php использовал библиотеку rpmreader.
Из идей которые еще не сделаны:
— уход от крона в пользу механизма inotify
— создание репозитория для pip python
— возможность управлять добавленными пакетами
— красивая статистика с применением d3 библиотеки для графиков
Из идей которые еще не сделаны:
— уход от крона в пользу механизма inotify
— создание репозитория для pip python
— возможность управлять добавленными пакетами
— красивая статистика с применением d3 библиотеки для графиков
Интересный комментарий очень практической направленности. Над веб-интерфейсом я, если честно, задумывался, но крайне ненадолго — нашёл, как включить autoindex, и на этом успокоился. Справедливости ради хочу заметить, что для полноценного решения веб-интерфейс действительно необходим.
Правильно ли я понял, что часть загружающая и часть обрабатывающая впрямую не взаимодействуют?
Правильно ли я понял, что часть загружающая и часть обрабатывающая впрямую не взаимодействуют?
Не совсем. Все это, и загрузка (html страница отдает по ajax php скрипту с пред обработкой rpm пакета) и обработка последующая (тут полная обработка файлов полученных от ftp) выполнена в едином php скрипте, но логически разделена. Т.е. загружаем файлы, сразу они не появляются, а раз в час только выгружаются после обработки. Если бы исключить ftp, то можно было бы сразу грузить и обрабатывать. Inotify очень понравился, но пока руки не доходят.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RPM-репозиторий — своими руками