10.08.2007

Управление ПО. Создание собственных репозитариев

Ранее мы уже рассказывали о необходимости упаковывать собственное ПО и ПО третьих поставщиков в RPM. Помимо непосредственно сборки пакетов, в крупной инфраструктуре необходимо обеспечить верификацию подлинности RPM-пакета и безопасное распространение пакетов. Все примеры абсолютно работоспособны и проверены в RHEL5. Если вы пытаетесь использовать эти примеры в отличающейся системе – позаботьтесь об адаптации. =)


GPG-подпись пакетов


GPG-подпись – стандартный механизм подписи пакетов RPM. Для его использования необходимо сделать следующее:

  1. Сгенерировать пару GPG-ключей.

  2. Добавить данные желательной подписи в конфиг RPM

  3. Подписать пакет.

  4. Экспортировать публичный ключ и выложить его в общедоступное место.


Пойдем по порядку.


Генерация пары GPG-ключей


Сначала сгенерируем ключ, для чего выполним команду gpg –gen-key. После ответов на ряд простых вопросов наш ключ будет сгенерирован. Ответы могут быть довольно произвольными, единственное – запомните имя, адрес электронной почты и пассфразу. Я например скромно назвался Albert Einstein <a.einstein@example.com> и записал пассфразу на бумажке. =)

После окончания генерации вы увидите в конце вывода утилиты 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 <a.einstein@example.com>

Единственным «критичным» моментом является совпадение имени и 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 и его возможности этим не ограничиваются.

1 комментарий:

rj комментирует...

Отличная статья, спасибо. Впервые создавал свой репозиторий, но благодаря статье получилось.