Ключевые слова:linux, redhat, fedora, centos, rpm, repository, (найти похожие документы)
From: Lynz <http://red-hat-moscow-times.blogspot.com>;
Date: Mon, 14 Jan 2007 14:31:37 +0000 (UTC)
Subject: Создание собственных репозиториев RPM пакетов
Оригинал: http://red-hat-moscow-times.blogspot.com/2007/08/blog-post.html
Ранее мы уже рассказывали о необходимости упаковывать собственное ПО и
ПО третьих поставщиков в RPM. Помимо непосредственно сборки пакетов, в
крупной инфраструктуре необходимо обеспечить верификацию подлинности
RPM-пакета и безопасное распространение пакетов. Все примеры абсолютно
работоспособны и проверены в RHEL5. Если вы пытаетесь использовать эти
примеры в отличающейся системе - позаботьтесь об адаптации. =)
GPG-подпись пакетов
GPG-подпись - стандартный механизм подписи пакетов RPM. Для его
использования необходимо сделать следующее:
1. Сгенерировать пару GPG-ключей.
2. Добавить данные желательной подписи в конфиг RPM
3. Подписать пакет.
4. Экспортировать публичный ключ и выложить его в общедоступное
место.
Пойдем по порядку.
Генерация пары GPG-ключей
Сначала сгенерируем ключ, для чего выполним команду gpg -gen-key.
После ответов на ряд простых вопросов наш ключ будет сгенерирован.
Ответы могут быть довольно произвольными, единственное - запомните
имя, адрес электронной почты и пассфразу. Я например скромно назвался
Albert Einstein <[9][email protected]> и записал пассфразу на
бумажке. =)
После окончания генерации вы увидите в конце вывода утилиты GPG строки
наподобие
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024D/AE49A408 2007-08-10
Key fingerprint = 4734 6DB2 6078 EAFE 4B3F 8346 8FD7 F01C AE49 A408
uid Albert Einstein
Note that this key cannot be used for encryption. You may want to use
the command "--edit-key" to generate a subkey for this purpose.
Важно запомнить части, выделенные жирным шрифтом. В нашем случае
AE49A408- идентификатор моего ключа, а более длинный фрагмент,
выделенный полужирным курсивом - это "отпечаток" (fingerprint) моего
ключа.
Если вы не послушали меня и не запомнили выделенные жирным данные - вы
всегда можете их "подсмотреть", выполнив команду
gpg --fingerprint
Конфигурирование RPM для использования ключа
Конфигурирование RPM в данном (как в прочем и в любом другом) случае
сводится к добавлению двух строк в файл ~/.rpmmacros
%_signature gpg
%_gpg_name Albert Einstein <[10][email protected]>
Единственным "критичным" моментом является совпадение имени и e-mail
адреса в выводе команды gpg -fingerprint с адресом, указанным в файле .rpmmacros.
Подпись пакетов
Задача важная, требующая интерактива и внимания. Хотя бы потому, что
вам придется вспомнить пассфразу, введенную ранее. =)
Для подписи RPM-пакетов у утилиты rpm есть два параметра.
* --addsign - начальная подпись. Используется в случае, если пакет
не подписывался ранее.
* --resign - как очевидно из названия "переподписать". (не верьте
переводу Lingvo, сдаваться мы не собираемся).
Формат вызова и использование параметров довольно очевидно:
rpm -addsign hello-1.0-1.i386.rpm
и после введения пассфразы мы получаем "помеченный" пакет. Если
пакет уже был кем-то "помечен" до вас, то
rpm -resign kernel-2.6.18-8.1.8.el5.i686.rpm
позволит вам удовлетворить самолюбие, сменить подпись пакета. Хотя вам
скорее всего не удастся убедить окружающий мир в том, что вы
крупнейший криптографический подписной авторитет, вы сможете добавлять
в собственные репозитарии ПО третьих лиц, удостоверяя их подлинность
вашей личной "вензельной печатью".
Экспорт ключа
Естественно, наша самодержавная подписная фабрика нуждается в средстве
донесения публичного ключа до широких масс серверов. Нет, объявление в
газету мы давать не будем, а сделаем следующее:
gpg --export --armor AE49A408 > /tmp/gpg-key
После этого "объявление" должно быть донесено до каждой системы. Для
локальной системы можно тут же, не отходя от кассы, выполнить команду
rpm -import /tmp/gpg-key
а для использования GPG-ключа в нашем репозитарии нам необходимо
обеспечить удаленный свободный доступ к этой публичной части ключа.
Наиболее простое решение (предполагающее, что у вас запущен httpd) -
выполнить команду
cp /tmp/gpg-key /var/www/html/
После этого на прочих системах достаточно выполнить команду
rpm -import http://192.168.0.1/gpg-key
где 192.168.0.1 - IP-адрес вашей системы. После этого вы можете
проверить подлинность пакета вызвав rpm с ключом -Kv
rpm -Kv hello-1.0-1.i386.rpm
Создание репозитория
Для создания репозитария вам потребуется:
1. Набор пакетов для репозитария. Если пакеты, которые вы хотите
включить в свой репозитарий зависят от пакетов, не входящих в
стандартный репозитарий дистрибутива - хорошей практикой будет
включение подобных зависимостей в ваш репозитарий. Разумеется,
удаленный доступ к пакетам с клиентских систем должен быть
обеспечен. Наиболее простой способ - обеспечение доступа по HTTP
или анонимному FTP. Мы надеемся, что с этим читатель справится. В
нашем примере мы просто создали директорию
/var/www/html/repository/5/i386/ и переместили наши RPM-пакеты
туда.
2. GPG-ключ. Мы уже обеспечили свободный доступ к нему; уровень
"свободности" доступа может ограничиваться вашей организацией, а
может быть глобальным - это совершенно безопасно.
3. Метаданные для пакетов. Это данные, которые необходимы утилите yum
для разрешения зависимостей. Процесс создания прост. Нам
потребуется установить пакет createrepo. Найти ее можно в
стандартной поставке RHEL5. Простейший вариант использования:
cd [директория-с-пакетами]; createrepo .
4. Файл описания репозитория, Этот файл необходимо "донести" до
широких масс систем, которые будут пользоваться вашим
репозитарием. Способ оставляем на ваше усмотрение. Содержание
файла может быть примерно следующим
[user@fortice ~]$ cat /etc/yum.repos.d/packages.repo
[epel]
name=Extra Packages for Enterprise Linux 5 - $basearch
baseurl=http://192.168.0.1/repository/5/$basearch
enabled=1
gpgcheck=1
gpgkey=http://192.168.0.1/gpg-key
структура этого файла интуитивно понятна, поэтому явно разбирать
мы ее не будем.
Заключение.
Описанный метод позволит вам наладить распространение ПО собственной
сборки, а также ПО третьих, особо доверенных сборщиков и управлять им
так же, как и ПО, входящим в дистрибутив. Это хороший метод, имеющий
правда один существенный недостаток. Этот недостаток заключается в
том, что управление ПО можно осуществлять только методом "PULL", то
есть непосредственно с клиентской системы.
Существуют решения для управления ПО, позволяющие использовать также
метод PUSH и иметь централизованный источник информации и пульт
управления ПО в вашей инфраструктуре. Имя ему Red Hat Satellite Server
и его возможности этим не ограничиваются.
