Comments 79
И в самом деле — почему то никогда не пользовался source. Всегда качал с сайта. Спасибо.
P.S. Жаль заголовок не поправили.
P.S. Жаль заголовок не поправили.
Вместо:
sudo apt-get install debhelper autotools-dev zlib1g-dev
обычно достаточно
sudo apt-get build-dep ccahe
sudo apt-get install debhelper autotools-dev zlib1g-dev
обычно достаточно
sudo apt-get build-dep ccahe
Совершенно верно, надо увеличить номер версии пакета. Набираем всё в том же каталоге команду
$ dch -i
Небольшая поправка, Вы не являетесь официальным сопровождающим пакета, поэтому изменять версию не рекомендуется. Вместо этого следует менять локальный префикс пакета:
--local, -l suffix
Add a suffix to the Debian version number for a local build.
Например, вот так:
dch -l local1
А вы попробуйте, dch -i, как из примера видно, определяет, что вы не мэинтейнер и увеличивает версию в рекомендуемом формате: до 2.4-16.1. Если почитать приведенный вывод lintian, то там об этом даже явно написано:
Собственно мы исправляли предложенный вариант и неправильно увеличивали номер версии с единственной целью — продемонстрировать, как работает и ругается lintian.
N: A source NMU should have a Debian revision of "-x.x" (or "+nmuX" for a
N: native package). This is to prevent stealing version numbers from the
N: maintainer.
Собственно мы исправляли предложенный вариант и неправильно увеличивали номер версии с единственной целью — продемонстрировать, как работает и ругается lintian.
не хочу показаться брюзгой — но чем это отличается от инфомации в maint-guide-ru?
Кроме того, что это рассказано Вами.
Не надо изобретать велосипеды — все это уже написано, и гораздо лучше пользоваться документацией именно от разработчиков дистрибутива.
Относительно создания своего репозитария — аналогично, уже написано самими разработчиками. Достаточно грамотно сформулировать запрос apt-cache search'у
Кроме того, что это рассказано Вами.
Не надо изобретать велосипеды — все это уже написано, и гораздо лучше пользоваться документацией именно от разработчиков дистрибутива.
Относительно создания своего репозитария — аналогично, уже написано самими разработчиками. Достаточно грамотно сформулировать запрос apt-cache search'у
> Достаточно грамотно сформулировать запрос apt-cache search'у
Можно поподробнее? (конечно, если не затруднит)
Можно поподробнее? (конечно, если не затруднит)
Например, apt-ftparchive, reprepro, mini-dinstall, может еще что-то. Об этом, собственно, я в следующий раз хотел рассказать :)
ну конечно не затруднит.
Вариант 1.
Мы пользуемся утилитой apt-build — в этом случае репозитарий собранных пакетов будет создаваться автоматически и сам же пропишеться в sources.list
Вариант 2.
Мы хотим создать просто зеркало репозитария — в этом случае смотрим apt-mirror, debmirror и debpartial-mirror
Вариант 3.
Мы хотим сделать некий кеш. В этом случае нас интересуют:
apt-cacher — кеширующий прокси-сервер для работы с репозиторями пакетов Debian
approx — кеширующий прокси-сервер для работы с репозиторями пакетов Debian
apt-proxy — прокси для доступа к репозиториям с возможностью создания частичных зеркал
и подобные.
Вариант 4.
У нас есть кеш скаченых пакетов и мы хотим им поделиться с кем-либо, создав из них репозитарий — в этом случе курим apt-move.
Вариант 5.
У нас есть просто набор deb-файлов, которые мы хотим оформить в репозито(а)рий. Причем эти файлы могут быть в собраны Вами же — без разницы. Просто набор файлов. В том и с сырцами. В этом случае варим с молоком dpkg-scanpackages /dpkg-scansources
И таких вариантов куча, и, в принципе, методы решения задач мы можем комбинировать.
Вариант 1.
Мы пользуемся утилитой apt-build — в этом случае репозитарий собранных пакетов будет создаваться автоматически и сам же пропишеться в sources.list
Вариант 2.
Мы хотим создать просто зеркало репозитария — в этом случае смотрим apt-mirror, debmirror и debpartial-mirror
Вариант 3.
Мы хотим сделать некий кеш. В этом случае нас интересуют:
apt-cacher — кеширующий прокси-сервер для работы с репозиторями пакетов Debian
approx — кеширующий прокси-сервер для работы с репозиторями пакетов Debian
apt-proxy — прокси для доступа к репозиториям с возможностью создания частичных зеркал
и подобные.
Вариант 4.
У нас есть кеш скаченых пакетов и мы хотим им поделиться с кем-либо, создав из них репозитарий — в этом случе курим apt-move.
Вариант 5.
У нас есть просто набор deb-файлов, которые мы хотим оформить в репозито(а)рий. Причем эти файлы могут быть в собраны Вами же — без разницы. Просто набор файлов. В том и с сырцами. В этом случае варим с молоком dpkg-scanpackages /dpkg-scansources
И таких вариантов куча, и, в принципе, методы решения задач мы можем комбинировать.
А еще вообще всё написано в манах и исходниках программ, достаточно только покурить их с недельку. А еще есть толстый красивый документ Debian Policy, освещающий все аспекты бытия и листы рассылки debian-devel и debian-mentors для тех, кому всех аспектов бытия почему-то не хватило.
И чтобы всё это воскурить, надо потратить кучу времени, разбираясь, где с чего начать, как всем этим заниматься, что куда писать и к кому собственно обращаться для добавления пакета в репозиторий, ну и так далее. Я знаю это по собственному опыту, потому что начинал я этим заниматься сам, а когда решил всё-таки включить пакет в официальный репозиторий Debian, то всплыло столько интересных моментов, что допиливаю я его до сих пор. И спасибо одному российскому Debian Developer'у, который потратил много времени, рассказывая мне все тонкости.
Всем известно, что у Убунту, наверное, самое большое и мощное коммьюнити, но при этом подавляющее число пользователей не являются гиками и специалистами вообще. Поэтому я хочу составить доступное удобное руководство, которое позволило бы разобраться со всем необходимым, не привлекая толпы посторонних людей, и не изучая страницы англоязычной переписки на debian-devel.
P.s. И, кстати говоря, русская версия maint-guide, когда я ее последний раз видел, была очень сильно устаревшей и неполной по сравнению с нормальной английской.
И чтобы всё это воскурить, надо потратить кучу времени, разбираясь, где с чего начать, как всем этим заниматься, что куда писать и к кому собственно обращаться для добавления пакета в репозиторий, ну и так далее. Я знаю это по собственному опыту, потому что начинал я этим заниматься сам, а когда решил всё-таки включить пакет в официальный репозиторий Debian, то всплыло столько интересных моментов, что допиливаю я его до сих пор. И спасибо одному российскому Debian Developer'у, который потратил много времени, рассказывая мне все тонкости.
Всем известно, что у Убунту, наверное, самое большое и мощное коммьюнити, но при этом подавляющее число пользователей не являются гиками и специалистами вообще. Поэтому я хочу составить доступное удобное руководство, которое позволило бы разобраться со всем необходимым, не привлекая толпы посторонних людей, и не изучая страницы англоязычной переписки на debian-devel.
P.s. И, кстати говоря, русская версия maint-guide, когда я ее последний раз видел, была очень сильно устаревшей и неполной по сравнению с нормальной английской.
Я не понял (сорри) пока, как сделать свой новый пакет с репозитарием.
Как быть в Debian/Ubuntu, если есть программа, как её правильно запаковать, и создать репозитарий? Про это будет в цикле статей?
Если программа на Питоне, и её можно раздавать в tar.gz — это насколько плохо? Обновляться по идее она и сама может, скачивая всё необходимое с сервера.
Хочется узнать, почему и как надо делать хорошо и правильно :-)
Извиняюсь за такие вот глупые вопросы, просто человеческим языком, как Вы пишете, мало информации, уверен, что если будет больше, Debian/Ubuntu станет гораздо популярнее.
Спасибо!
Как быть в Debian/Ubuntu, если есть программа, как её правильно запаковать, и создать репозитарий? Про это будет в цикле статей?
Если программа на Питоне, и её можно раздавать в tar.gz — это насколько плохо? Обновляться по идее она и сама может, скачивая всё необходимое с сервера.
Хочется узнать, почему и как надо делать хорошо и правильно :-)
Извиняюсь за такие вот глупые вопросы, просто человеческим языком, как Вы пишете, мало информации, уверен, что если будет больше, Debian/Ubuntu станет гораздо популярнее.
Спасибо!
если программа на пайтоне — то можно воспользоваться утилитой checkinstall.
Всё будет, я только начал :) Просто чтобы рассказывать именно об упаковке, надо сначала представлять, что нам из этого может понадобиться и как этим всем пользоваться :) В следующий раз будет как раз уже про сборку пакетов.
Да, а для питона есть какой-то свой аналог перлового CPAN и утилита checkinstall, тут OldFornit совершенно прав.
И отдельно можете почитать Python Policy, описывающее особые правила, применяемые в Debian к питону и его модулям.
И отдельно можете почитать Python Policy, описывающее особые правила, применяемые в Debian к питону и его модулям.
Имеется в виду end-user продукт. На питоне, в общем-то, много чего написано — я думаю, для юзера не должно быть никакой разницы, на чём написана программа, на питоне, си или ещё чём-то. Правильнее, мне кажется, использовать deb.
Другое дело, что интересно понять, что проще и удобнее для юзера — распространять в tar.gz, или делать собственный репозиторий. С точки зрения юзера.
Если делать репозиторий, юзеру надо добавлять его в список репозиториев, в случае с архивом — просто распаковать. deb пакет тоже хорошо — но он не будет обновляться автоматически, если не прописать репозиторий(?).
Т.е. интересует юзабилити, хочется такой же простоты как с setup.exe — для юзера. Юзер ведь не обязан знать про то, о чём мы тут говорим. В идеале всё должно сводиться к одному клику, или apt-get install.
Другое дело, что интересно понять, что проще и удобнее для юзера — распространять в tar.gz, или делать собственный репозиторий. С точки зрения юзера.
Если делать репозиторий, юзеру надо добавлять его в список репозиториев, в случае с архивом — просто распаковать. deb пакет тоже хорошо — но он не будет обновляться автоматически, если не прописать репозиторий(?).
Т.е. интересует юзабилити, хочется такой же простоты как с setup.exe — для юзера. Юзер ведь не обязан знать про то, о чём мы тут говорим. В идеале всё должно сводиться к одному клику, или apt-get install.
Ну, для пользователя проще всего будет поставить программу откуда-нибудь из репозитория. В убунту с его ежедневным поиском обновлений это вообще не вызовет никаких проблем — как только залили новую версию в репозиторий — на следующий день она уже предлагается пользователю для установки, только нажми кнопочку «установить». А архив надо откуда-то скачать, распаковать, поставить…
Так что оптимальным вариантом будет естественно собрать пакет и пропихнуть в офф. репозиторий. Для изучения особенностей питоновских пакетов — опять же смотрить Python Policy плюс скачайте src-пакет еще какой-нибудь программы на питоне, которую уже добавили в репозиторий. Будет намного проще :)
Так что оптимальным вариантом будет естественно собрать пакет и пропихнуть в офф. репозиторий. Для изучения особенностей питоновских пакетов — опять же смотрить Python Policy плюс скачайте src-пакет еще какой-нибудь программы на питоне, которую уже добавили в репозиторий. Будет намного проще :)
Вот только обновления версий выходят раз в полгода, а в рамках одного релиза идёт feature freeze, разве не так? :-)
Это в убунту, и там только в определенный момент идёт фриз новых версий, а принимаются только исправления найденных багов. В дебиане то же самое происходит со stable версией, которая выпускается раз в ~2 года, а в unstable у меня пакеты каждую неделю обновляются :)
А по вашему опыту — unstable по сравнению с testing предназначен для совсем джедаев с красными гл световыми мечами?
Да нет, ничего подобного :) В дебиане на самом деле всё просто: обычные пользователи в большинстве своём отлично пользуются unstable, по версиям пакетов он примерно соответствует свежим релизам убунту, лишь немного новее. Осторожные пользователи, которые не гонятся за новыми мегафичами, пользуются testing. Системные администраторы, знающие, что всё дело в волшебных пузырьках, а всё прочее — суета сует, ставят на сервера stable. А вот те, кому хочется нежных ласок с системой, регулярно падающий софт и т.д. и т.п., но зато САМЫЕ новые фичи — ставят experimental.
или изучить возможности easy-install — нам никто это не запрещает ;-)
да, русская версия на самом деле очень устаревшая.
Просто что я хотел сказать — если уж человек чувствует, что ему настала пора собирать пакеты самому, то он должен быть достаточно уже подкован в знании системы. А тут, естественно, без чтения именно оригинальной документации не обойтись.
Тут образование не как самоцель выступает, а как инструмент. К сожалению, статьи, написанные о неких конкретных случаях имеют свойство устаревать со временем, а оригинальная документация, естественно, обновляется сразу же.
Никогда, особенно когда только начинали работать с *nix не сталкивались со статьями о настройке шлюзов, где самый первый пункт — это пересборка ядра и echo «1» > /proc…?
И ведь сейчас начинающие зачастую именно так по статьям и делают, хотя ядро допустим сейчас всегда уже готово в такого рода задачи, а вместо echo «1» достаточно отредактировать /etc/sysctl.conf.
Также можно сильно мучаться, пересобирать iptables и долго думать на предмет скриптов, а можно установить arno-iptables-firewall и, при необходимости, допилить правила.
Просто что я хотел сказать — если уж человек чувствует, что ему настала пора собирать пакеты самому, то он должен быть достаточно уже подкован в знании системы. А тут, естественно, без чтения именно оригинальной документации не обойтись.
Тут образование не как самоцель выступает, а как инструмент. К сожалению, статьи, написанные о неких конкретных случаях имеют свойство устаревать со временем, а оригинальная документация, естественно, обновляется сразу же.
Никогда, особенно когда только начинали работать с *nix не сталкивались со статьями о настройке шлюзов, где самый первый пункт — это пересборка ядра и echo «1» > /proc…?
И ведь сейчас начинающие зачастую именно так по статьям и делают, хотя ядро допустим сейчас всегда уже готово в такого рода задачи, а вместо echo «1» достаточно отредактировать /etc/sysctl.conf.
Также можно сильно мучаться, пересобирать iptables и долго думать на предмет скриптов, а можно установить arno-iptables-firewall и, при необходимости, допилить правила.
Это всё верно, просто у разных инструментов разный порог вхождения.
Например, ebuild в gentoo предполагает, что пользователь должен знать и уметь bash и, вообщем-то, больше почти ничего не надо — короткой заметки в handbook-е по волшебным переменным достаточно.
Несколько раз я пытался разобраться в документации разработчика debian — каждый раз становилось невыносимо грустно где-то главе к третей…
Может быть я какую-то не ту документацию читаю?
Например, ebuild в gentoo предполагает, что пользователь должен знать и уметь bash и, вообщем-то, больше почти ничего не надо — короткой заметки в handbook-е по волшебным переменным достаточно.
Несколько раз я пытался разобраться в документации разработчика debian — каждый раз становилось невыносимо грустно где-то главе к третей…
Может быть я какую-то не ту документацию читаю?
может просто не созрел? ;-)
Я подобным образом окого года созревал до понимания netams'a. Теперь уже более-менее понимаю и могу настроить под мои нужды.
Я подобным образом окого года созревал до понимания netams'a. Теперь уже более-менее понимаю и могу настроить под мои нужды.
Ну не знаю… Почему-то я не считаю, что собирать софт должно быть сложнее, чем его писать. :-)
А по поводу netams-а могу сказать одно — не знаю как сейчас, но полтора года назад был ужасно сырым (и это при версии 3.х!!!): даже zombie-процессы за собой не подбирал и сегфолтился на раз-два-три, а ЛЮБОЙ сегфолт — это ошибка разработчика, а не пользователя… Ну и использование тредов там, где достаточно процессов — тоже не способствовало стабильности.
Настроить его на правильный учёт по нужным мне тарифам я смог за неделю, но при этом пользоваться его встроенным генератором статистики не получалось — при попытке сгенерировать что-то он падал в корку, при попытке использовать встроенный шедалер — падал в корку.
Пару сегфолтов я пофиксил, матерясь, а потом плюнул и перешел на голые счетчики iptables, т.к. роутер и считалка трафика были одной и той же машиной.
А по поводу netams-а могу сказать одно — не знаю как сейчас, но полтора года назад был ужасно сырым (и это при версии 3.х!!!): даже zombie-процессы за собой не подбирал и сегфолтился на раз-два-три, а ЛЮБОЙ сегфолт — это ошибка разработчика, а не пользователя… Ну и использование тредов там, где достаточно процессов — тоже не способствовало стабильности.
Настроить его на правильный учёт по нужным мне тарифам я смог за неделю, но при этом пользоваться его встроенным генератором статистики не получалось — при попытке сгенерировать что-то он падал в корку, при попытке использовать встроенный шедалер — падал в корку.
Пару сегфолтов я пофиксил, матерясь, а потом плюнул и перешел на голые счетчики iptables, т.к. роутер и считалка трафика были одной и той же машиной.
Понимаете, если пользователь сделает echo 1 > /proc/..., то он всё равно как минимум включит роутинг на своём шлюзе, а потом, со временем, при попытке оптимизации своих скриптов или просто исследовании /etc наткнется на упоминание нужной переменной в sysctl.conf и разберется, как сделать лучше. Даже если у него не сработает пример из руководства — он сможет залезть в ман и найти, что в руководстве оказалось неверным применительно к новой версии. В любом случае материал мана будет восприниматься гораздо лучше, а не как абстрактный набор каких-то команд, не связанных в стройную последовательность. Отсутствие руководств вообще — это хуже, чем наличие устаревших руководств.
Я хочу, чтобы для сборки пакетов не надо было специального созревания. Чтобы пользователь прочитал краткое руководство и сразу сел их собирать. Вот когда при заливке в репозиторий ему скажут: «тут у вас бага, поправьте», он уже залезет в официальное руководство и восполнит пробелы. И это ему будет гораздо проще, поскольку он уже будет понимать процесс сборки, а не теряться в томах Policy.
Я хочу, чтобы для сборки пакетов не надо было специального созревания. Чтобы пользователь прочитал краткое руководство и сразу сел их собирать. Вот когда при заливке в репозиторий ему скажут: «тут у вас бага, поправьте», он уже залезет в официальное руководство и восполнит пробелы. И это ему будет гораздо проще, поскольку он уже будет понимать процесс сборки, а не теряться в томах Policy.
Отсутствие руководств вообще — это хуже, чем наличие устаревших руководств.
На эту тему также есть мнение, что неверная документация хуже её отсутствия. Конечно, это не касается неполной или «неряшливой» документации.
Вопрос в том, насколько она неверная. «Устаревшая и поэтому неверная в деталях» и «вызывающе неверная» — это две большие разницы, согласитесь. Тем более, что у данных материалов явно видны даты публикации, которые при чтении надо будет учитывать :)
Нет-нет, я не спорю, под «неряшливой» я и имел ввиду в том числе и устаревшую.
А не хотите третью часть (про сборку деб-пакетов) разобрать на примере какой-нибудь софтины… Ну не знаю, например redsocks ;-)
А не хотите третью часть (про сборку деб-пакетов) разобрать на примере какой-нибудь софтины… Ну не знаю, например redsocks ;-)
Не вопрос :) Скажите только список возможных зависимостей, чтобы я не развлекался, выискивая их сам.
В README только libevent, из компиляторов — только gcc.
Если будут вопросы, контакты мои в профиле :-)
Если будут вопросы, контакты мои в профиле :-)
это замечательное стремление. Но нет ощущение, что произойдет то же самое, как и на bash.org.ru?
Может это и шовинизм, но не надо каждого пользователя приучать к мысли, что он может так просто стать сопровождающим пакета, всего лишь почитав пару статей. Уж лучше посидеть на том же самом apt-get.org и поискать, чем собирать кривой пакет, им делиться, а потом в слезах кричать — ubuntu/debian кака и никогда им не пользуйтесь.
Помните, после чего php стали считать быдлоязыком? Хотя сам язык для своих задачь очень даже неплох.
Может сложиться впечатление, что я призываю запрещать пользователям делать свои пакеты, делиться ими со знакомыми. Нет. Я всего-навсего призываю сначала их научиться учиться. Изучить систему, в которой работают.
В конце-концов, высокий порог вхождения — это хорошо.
На правах ИМХО ;-)
Может это и шовинизм, но не надо каждого пользователя приучать к мысли, что он может так просто стать сопровождающим пакета, всего лишь почитав пару статей. Уж лучше посидеть на том же самом apt-get.org и поискать, чем собирать кривой пакет, им делиться, а потом в слезах кричать — ubuntu/debian кака и никогда им не пользуйтесь.
Помните, после чего php стали считать быдлоязыком? Хотя сам язык для своих задачь очень даже неплох.
Может сложиться впечатление, что я призываю запрещать пользователям делать свои пакеты, делиться ими со знакомыми. Нет. Я всего-навсего призываю сначала их научиться учиться. Изучить систему, в которой работают.
В конце-концов, высокий порог вхождения — это хорошо.
На правах ИМХО ;-)
Так, сударь, в убунту УЖЕ юзер-френдли порог вхождения. Я до сих временами вспоминаю добрым словом человека, собравшего версию 0.1 кутима для убунту, в следующий раз расскажу, почему. Просто документации на русском языке у убунту мало, а дискриминировать и говорить, что «русские лучше и не будут собирать быдлопакеты» — было бы как-то глупо. Я лучше постараюсь научить собирать сразу получше и поправильнее, и это будет хорошо.
А в дебиане — неужели вы думаете, что там кто-то снизит порог вхождения?) Там и так ежедневно приходят десятки предлагаемых пакетов, но при этом у них есть суровые спонсоры, проверяющие пакет, ftp-masters, которые тоже смотрят на пакет и могут еще всех отправить в топку, плюс команды debian-security и debian-legal, которые тоже изучат ваш пакет вдоль и поперек.
А в дебиане — неужели вы думаете, что там кто-то снизит порог вхождения?) Там и так ежедневно приходят десятки предлагаемых пакетов, но при этом у них есть суровые спонсоры, проверяющие пакет, ftp-masters, которые тоже смотрят на пакет и могут еще всех отправить в топку, плюс команды debian-security и debian-legal, которые тоже изучат ваш пакет вдоль и поперек.
так. Разводить холивар debian vs ubuntu я не собираюсь ;-)
Если документации к бубунте на русском мало — идите читайте документацию к дебиану. Не думаю, что разница будет такая же, как и со слакой.
Уж по дебиану то документации хватает…
А по поводу тех, кто будет отправлять «в топку» — раз они нас проверяют, значит и будем их засыпат своим «творчеством».
Я, кстати, ничего не имею против Вашей статьи и Ваших комментариев. Честно и статье плюс поставил, и некоторым комментариям.
Я против современных «пользователей», которые воспримут Ваше статью просто как шаблон. Которые как бибизянка — потыкают на кнопофки и, возможно, что-то сломают.
Которые скажут — а для сего мне список конфликтов и зависимостей описывать? У меня же все заработало.
В наше время мало осталось людей, которые будут делать что-то — именно думая и зная, для чего они это делают.
Знаете, по работе мне иногда приходится обучать персонал работе с некоторыми программами. Есть один магический вопрос, который почти всегда вводит в ступор — «Для чего вы нажали эту кнопку?».
Поэтому я и призываю — заставляйте людей учиться.
З.Ы. Опять таки на правах ИМХО.
Если документации к бубунте на русском мало — идите читайте документацию к дебиану. Не думаю, что разница будет такая же, как и со слакой.
Уж по дебиану то документации хватает…
А по поводу тех, кто будет отправлять «в топку» — раз они нас проверяют, значит и будем их засыпат своим «творчеством».
Я, кстати, ничего не имею против Вашей статьи и Ваших комментариев. Честно и статье плюс поставил, и некоторым комментариям.
Я против современных «пользователей», которые воспримут Ваше статью просто как шаблон. Которые как бибизянка — потыкают на кнопофки и, возможно, что-то сломают.
Которые скажут — а для сего мне список конфликтов и зависимостей описывать? У меня же все заработало.
В наше время мало осталось людей, которые будут делать что-то — именно думая и зная, для чего они это делают.
Знаете, по работе мне иногда приходится обучать персонал работе с некоторыми программами. Есть один магический вопрос, который почти всегда вводит в ступор — «Для чего вы нажали эту кнопку?».
Поэтому я и призываю — заставляйте людей учиться.
З.Ы. Опять таки на правах ИМХО.
Замечательно! Как раз всё никак не соберусь с gentoo перейти на debian/testing, т.к. сборка пакетов в debian заметно сложнее ebuild-ов из gentoo с первого взгляда. Хотя бы по сравнению объемов документации, в gentoo — одна страница введения в рамках хэндбука (которого достаточно почти для всего) с ссылками на dev.gentoo.com, а в debian — документ о 20 главах…
ну скажем так — мне за лет 5 пришлось 4 раза встретиться со случаем, что надо что-то в дебиане пересобрать.
Все случаи благодаря apt-src и debuild binary были тривиальными.
Ведь зачастую нам что надо? Нам надо не стать сопроводителем определнного пакета, а просто пересобрать уже существующий с нужными опциями. А это на самом деле очень просто — грамотные маинтентеры эту предусматривают и, например, в файле debian/rules пишут все необходимые комментарии. Или пишут дополнительные правила, которые элементарно подключить.
Так, надо было пересобрать freeradius на предмет поддержки postgres'а. Это заняло минут 20, в том числе 5 минут изучени и правки файла с правилами сборки.
Все случаи благодаря apt-src и debuild binary были тривиальными.
Ведь зачастую нам что надо? Нам надо не стать сопроводителем определнного пакета, а просто пересобрать уже существующий с нужными опциями. А это на самом деле очень просто — грамотные маинтентеры эту предусматривают и, например, в файле debian/rules пишут все необходимые комментарии. Или пишут дополнительные правила, которые элементарно подключить.
Так, надо было пересобрать freeradius на предмет поддержки postgres'а. Это заняло минут 20, в том числе 5 минут изучени и правки файла с правилами сборки.
Да, сборка дебианизированного пакета тривиальна, согласен, но мне иногда бывает необходимо собрать последнюю версию какой-нибудь редкой библиотеки или же поставить какой-нибудь софт, который вообще еще не опакетили для debian.
В gentoo это сделать проще, но, увы, оверхэд на сборку остальной системы всё-таки весьма ощутим.
В gentoo это сделать проще, но, увы, оверхэд на сборку остальной системы всё-таки весьма ощутим.
Для личного пользования собрать и совсем просто :)
Вот пример: maximum-value.blogspot.com/2008/09/deb_17.html
Вот пример: maximum-value.blogspot.com/2008/09/deb_17.html
Вот потом и появляются пакеты с бинарниками, которые от libc не зависят ;-)
Для личного пользования в конце концов и checkinstall сойдет, но хочется же наработки и контрибутить иногда =)
Для личного пользования в конце концов и checkinstall сойдет, но хочется же наработки и контрибутить иногда =)
А вдруг при отправке на сервер ключа:
gpg --keyserver subkeys.pgp.net --send-keys 3904FAE7
его перехватит злоумышленник
его перехватит злоумышленник
Почитайте что-нибудь про PKI или системы шифрования с открытым ключем вообще.
а рассказать в двух словах? o_O
Ну вот публичный ключ на сервер отправлен. А его перехватил злоумышленник и подставил свой публичный ключ. Теперь если кто-то хочет сверить, скачивает паш публичный, оп-па, а он не тот.
*ваш
Но его публичный ключ не будет подписан кем-либо.
Нет, я не то имею в виду.
Вот вы отправляете ключ на сервер. Злоумышленник в этот момент вламывается и вместо вашего ключа на сервер идёт его и там хранится как, якобы, ваш. Такое ведь возможно?
Вот вы отправляете ключ на сервер. Злоумышленник в этот момент вламывается и вместо вашего ключа на сервер идёт его и там хранится как, якобы, ваш. Такое ведь возможно?
Конечно, но его ключ не заверен никем. Прочитайте про web of trust (оно же «сеть доверия») на, к примеру, pgpru.com.
Более того, насколько я знаю, чтоб стать debian-девелопером и подписывать пакеты своим ключем, надо чтоб ваш ключ заверил кто-то из debian-девелоперов при личной встрече.
Более того, насколько я знаю, чтоб стать debian-девелопером и подписывать пакеты своим ключем, надо чтоб ваш ключ заверил кто-то из debian-девелоперов при личной встрече.
Вот, это я и хотел узнать. При личной встрече. Спасибо.
а про сеть доверия сейчас почитаю o_O
Да, всё обстоит именно так :) У каждого ключа есть так называемый оттиск — fingerprint — что-то типа хэша, что можно вставить в подпись письма или распечатать на бумажке. А у каждого загруженного себе ключа есть статус доверия:
И ты когда загружаешь ключ, указываешь, насколько ты ему доверяешь. Соответственно, увидев лично человека и получив у него оттиск ключа, ты его можешь сверить и выставить предпочтительный статус доверия.
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
И ты когда загружаешь ключ, указываешь, насколько ты ему доверяешь. Соответственно, увидев лично человека и получив у него оттиск ключа, ты его можешь сверить и выставить предпочтительный статус доверия.
Как я понимаю, заверение ключа и доверие ключу — две в меру ортогональные сущности… Как я понимаю, можно ключ подписать, но не доверять ему, или нет?
Ну, ты можешь выставить статус «недоверия», подразумевающий, что ты не знаешь, кто это он или «делаешь вид, что не знаешь». Это собственно в пункте 1 прямым текстом сказано. То есть ты не подтверждаешь тем самым достоверность владельца ключа или считаешь его ключ скомпрометированным, украденным или еще каким. Статус 5 выставляется когда ты обладаешь даже приватным ключом, то есть доверяешь подписывающему полностью. Как правило, это выставляется только своему собственному ключу.
А еще при подписи ключа есть степень валидации от 0 до 3:
0 — ничего не утверждаю про степень валидации
1 — поглядел в глаза
2 — поглядел в глаза и на отпечаток ключа
3 — поглядел в глаза, в паспорт и на отпечаток ключа
0 — ничего не утверждаю про степень валидации
1 — поглядел в глаза
2 — поглядел в глаза и на отпечаток ключа
3 — поглядел в глаза, в паспорт и на отпечаток ключа
Я про то, что циферок разных много, но мало кто ими всеми пользуется :-)
Посмотрел сейчас свой небольшой keyring — значения trust ни у кого не выставлены. Да и certificate check level только в одном случае есть.
Посмотрел сейчас свой небольшой keyring — значения trust ни у кого не выставлены. Да и certificate check level только в одном случае есть.
Это публичный ключ. Его и так можно будет свободно с этого сервера скачать. Его цель именно в том, чтобы имея данный ключ, проверить — тот ли самый человек подписал данные. А вот ваш приватный ключ никому отсылать или отдавать нельзя ни в коем случае.
Алгоритм GPG/PGP собственно работает следующим образом. Есть приватный ключ владельца, которым можно подписать любые данные. И есть публичный ключ, который пытается проверить подпись. Если подпись проверена успешно, то считается, что файл подписали именно вы, а не кто-то другой. Именно поэтому публичный ключ может иметь любой — с его помощью нельзя притвориться вами, только проверить данные. Я всё это, конечно, объясняю на пальцах, лучше почитайте русскую википедию, там это немножко лучше написано. Там внизу также есть ссылки, по которым можно походить и почитать поподробнее.
Алгоритм GPG/PGP собственно работает следующим образом. Есть приватный ключ владельца, которым можно подписать любые данные. И есть публичный ключ, который пытается проверить подпись. Если подпись проверена успешно, то считается, что файл подписали именно вы, а не кто-то другой. Именно поэтому публичный ключ может иметь любой — с его помощью нельзя притвориться вами, только проверить данные. Я всё это, конечно, объясняю на пальцах, лучше почитайте русскую википедию, там это немножко лучше написано. Там внизу также есть ссылки, по которым можно походить и почитать поподробнее.
часть до хабраката напомнила
Пароль: «русскими_буквами» в английской раскладке © баш
Пароль: «русскими_буквами» в английской раскладке © баш
столкнулся с проблемой при генерации ключа
«Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 291 more bytes)»
я сижу из ssh… что я только не вводил и сколько кнопок не нажимал… гугл говорит надо послать большой файл в /dev/null, но что-то cat /dev/sdc > /dev/null результата не приносит :( как быть?
«Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 291 more bytes)»
я сижу из ssh… что я только не вводил и сколько кнопок не нажимал… гугл говорит надо послать большой файл в /dev/null, но что-то cat /dev/sdc > /dev/null результата не приносит :( как быть?
А вы слали файл в /dev/null параллельно с генерацией ключа или нет?) Запустите в одной сессии cat /dev/sdc > /dev/null, а в другой в это же время — генерацию ключа.
Вообще говоря, создавать ключ через ssh-соединение крайне не рекомендуется в силу требований всё той же безопасности. Сейчас уже не найду ссылку, где бы это было написано, но когда-то GPG крайне просил меня этого не делать. Поэтому если есть возможность поставить на свою linux/windows машину gnupg — лучше сгенерировать ключ на своей машине, потом экспортировать приватный и публичный ключ в файлы и заимпортировать их на удаленной машине. Файлы с ключами, особенно с приватным, после этого, разумеется, надо тщательно стереть.
Вообще говоря, создавать ключ через ssh-соединение крайне не рекомендуется в силу требований всё той же безопасности. Сейчас уже не найду ссылку, где бы это было написано, но когда-то GPG крайне просил меня этого не делать. Поэтому если есть возможность поставить на свою linux/windows машину gnupg — лучше сгенерировать ключ на своей машине, потом экспортировать приватный и публичный ключ в файлы и заимпортировать их на удаленной машине. Файлы с ключами, особенно с приватным, после этого, разумеется, надо тщательно стереть.
естественно, я запускал процесс генерации параллельно с пересылкой файла :)
так вот, попутно нашел какой-то пакет, который должен был воспользоваться датчиком случайных чисел встроенным в процессор, в AMD Turion X2 никаких встроенных датчиков не оказалось :(
про то, что ключи можно на любой машине сгенерить я как то забыл, cygwin + pgp помог
так вот, попутно нашел какой-то пакет, который должен был воспользоваться датчиком случайных чисел встроенным в процессор, в AMD Turion X2 никаких встроенных датчиков не оказалось :(
про то, что ключи можно на любой машине сгенерить я как то забыл, cygwin + pgp помог
Sign up to leave a comment.
Стать мэинтейнером. Часть вторая