Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

При развёртывании IT инфраструктуры на основе UNIX/Linux важным моментом является организация локальных репозитариев пакетов, что, совместно с инфраструктурой сетевой установки, обеспечит возможность подготовки типовых конфигураций и их поддержки, в том числе автоматизированной установки и периодического обновления. Локальные репозитарии, периодически обновляемые с официальных зеркал используемых вами дистрибутивов, кроме прочего позволяют резко экономить Интернет трафик и организовать единый, контролируемый и управляемый администратором источник установки и обновлений. Ниже будет описан "скелет" приёмов работы с репозитариями для двух наиболее распространённых пакетных форматов DEB и RPM. Рассматриваемые здесь задачи:

• RPM based. подключить дополнительные репозитарии, в частности репозитарий RPMForge (Дага)
• RPM based. установить на клиентских хостах поддержку APT и Synaptic
• RPM based. создать локальные зеркала репозитариев (установки, обновления, Дага и другие расширенные, частный. Для Yum и APT
• RPM based. подключить клиентские машины к локальным репозитариям в двух вариантах - для yum и для apt
• DEB based. обзор устройства репозитария DEB
• DEB based. процедура создания локального репозитария

подключить дополнительные репозитарии напрямую клиентскому хосту

Репозиторий серверного ПО от RPMForge Дага со товарищи. Подключение описано http://centos.name/?page/additionalresources/RPMForge (faq доступно по http://dag.wieers.com/rpm/FAQ.php), но повторим

• установить пакет поддержки приоритетов, и выставить приоритеты для описания каждого репозитария
  
  yum install yum-priorities; ... echo priority=XXX > repo.XXX
• при необходимости в /etc/yum.conf настроить прокси опциями proxy=,proxy_user=,proxy_password=
• импортировать ключ репозитария
  rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
• скачать и установить с ресурса http://rpmforge.sw.be/redhat/el5/en/i386/rpmforge/RPMS/ последний rpmforge-release, например rpmforge-release-0.5.1-1.el5.rf.i386.rpm

Другие известные репозитарии:

• epel. Установка
  rpm -ihv http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
• elrepo. Установка на клиенте, без создания локального зеркала командой
  rpm -Uvh http://elrepo.org/elrepo-release-0.1-1.el5.elrepo.noarch.rpm
• atomic. Установка на клиенте, без создания локального зеркала командой
  rpm -ihv http://www.atomicorp.com/channels/atomic/centos/5/i386/RPMS/atomic-release-1.0-11.el5.art.noarch.rpm
• odiecolon. несовместим с отдельными сторонними. http://odiecolon.lastdot.org/
• pramberger. серверные пакеты, модули Perl и т.п. http://www.pramberger.at/peter/services/repository/
• rpmfusion. http://rpmfusion.org/
• centalt. http://centos.alt.ru

установить на клиентских хостах поддержку APT и Synaptic

• установить последние apt и sypaptic можно из подключенного ранее репозитария RPMForge командой
  yum install apt synaptic
• в конфигурации /etc/apt/source.list включить репозитарии и обновить индекс командой
  apt-get update

создать локальные RPM - based репозитарии
(установки, обновления, расширенные и частные для Yum и APT)

Для YUM, официально поддерживаемого производителем, процедура создания локальных репозитариев такова:

• установить mrepo и createrepo: yum install mrepo createrepo
• базовый репозитарий грамотно совместить с источником сетевой установки, для чегоскопировать содержимое DVD (или слить содержимое CD)
• метаданные уже лежат на правильном месте в дереве каталогов, но если будут дополнения или слияния CD, то пересоздать их можно командой
  createrepo корень_скопированного_дистрибутива
• создать алиас для Apache, который будет указывать и на репозитарий, и на источник установки
• репозитарий обновлений должен регулярно синхронизироваться с официальными зеркалами. Достичь этого можно использованием утилиты mrepo, или самостоятельно написав скрипт, сравнивающий локальное и официальное зеркала, удаляющий из локального зеркала устаревшее и скачивающий недостающее, с последующим прогоном
  createrepo --update базовый_каталог_обновлений
• дополнительные репозитарии, в частности RPMForge создаются также как периодисески синхронизируемое хранилище, отдаваемое в локальную сеть по http (ftp, nfs), по которому после синхронизации проходится
  createrepo [--update] базовый_каталог_репозитария
• частные репозитарии со своими пакетами создаются как каталоги, розданные по http, с предварительным созданием метаданных командой
  createrepo [--update] базовый_каталог_репозитария

Дополнительной возможностью является создание комплексного репозитария, хранящего отдельные репозитарии (например base,updates,contrib) пакетов для различных версий дистрибутивов, для различных архитектур и источников (например i386,amd, а также PRMS и SRPMS). Здесь же можно разместить ISO образы дистрибутивов. Официальные зеркала CentOS, в частности, являются такими комплексными репозитариями, и ничто не мешает создать аналогичный репозитарий в локальной сети

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

Для APT, являющегося неофициальным RPM вариантом, репозитарии могут создаваться на той же базе, что и YUM ориентированные. Для создания APT репозитариев процедура создания локальных репозитариев такова:

• создаются источники копированием с DVD/CD, синхронизацией с официальных зеркал и т.п. под требуемые версии, архитектуры, типы пакетов (rpm, srpm) для каждого нужного нам репозитария (base, update, contrib, local, addons, extras, дополнительные из сети). Или используются те же, что и для локальных YUM репозитариев
• в корне источника создаётся папка base, в которой готовятся вписки пакетов и генерируются метаданные
  genpkglist --progress /mnt/repodisk1/co5_i386_base os
  genpkglist --progress /mnt/repodisk1/co5_i386_base updates
  genbasedir --progress --bloat /mnt/repodisk1/co5_i386_base os updates

подключить клиентские машины к локальным репозитариям для yum и для apt

• установке поддержки приоритетов (опционально)
  yum install yum-priorities; ... echo priority=XXX > repo.XXX
• созданию в каталоге /etc/yum.repos.d файла описания локального репозитария/ев
• при необходимости импортирования ключа подписи этих репозитариев командой
  rpm --import файл_с_ключём

Примером описания новых репозитариев может служить следующий фрагмент:

 
[repobase] 
name=CentOS-$releasever - local base 
baseurl=http://192.168.0.2/repo_base/ 
#mirror.domain.ru /centos/$releasever/os/$basearch/ 
#(путь/тип дистрибутива/версия/тип репозитария/архитектура)
enabled=1 
gpgcheck=1 
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 
priority=15

[repoupdates] 
name=CentOS-$releasever - local updates 
baseurl=http://192.168.0.2/repo_updates/ 
#mirror.domain.ru/centos/$releasever/updates/$basearch/ 
#(путь/тип дистрибутива/версия/тип репозитария/архитектура)
enabled=1 
gpgcheck=1 
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 
priority=15

Для APT, являющегося неофициальным RPM вариантом, репозитарии могут подключаться созданием дополнительного файла в каталоге /etc/apt/sources.list.d. После чего обновить кеш командой apt-get update. Пример содержания файла

 
rpm http://192.168.0.2 repo_base os 
rpm http://192.168.0.2 repo_updates updates 

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

обзор устройства репозитария DEB

Локальный репозитарий является структурой каталогов, и разделяется на дистрибутивы stable (стабильный), testing (тестируемый), unstable (нестабильный), каждый из которых имеет разделы (каталоги) - main (свободные пакеты), contrib (свободные, зависящие от несвободных), non-free (не свободные пакеты). Каждый раздел имеет подраздел (каталог) для каждой поддерживаемой архитектуры, а также каталог source для исходных текстов

В каждом каталоге подраздела располагаются непосредственно пакеты .deb, а также файл Packages.gz (для бинарных пакетов) или Sources.gz (для пакетов с исходными кодами), а также, опционально, файл Release, содержащий поля Archive: (stable|testing|unstable), Component: (main|contrib|non-free), Origin: ваше_имя, Label: произвольная_метка, Architecture: (i386|amd64|ia64...). Непосредственно файлы Packages.gz и Sources.gz создаются соответственно командами:
dpkg-scanpackages каталог_с_пакетами /dev/null | gzip -c > binary/Packages.gz
dpkg-scansources каталог_с_исходниками /dev/null | gzip -с > source/Sources.gz

Репозитарий отдаётся локально или по сети через протоколы HTTP, FTP. Клиенты узнают о существованиее репозитария из прописанной в вайле /etc/apt/apt.conf ссылки на репозитарий

процедура создания локального DEB репозитария

Здесь есть варианты. В общем случае создаётся структура каталогов, в которой размещаются пакеты, после чего по ней проходится описанными выше утилитами dpkg-scanpackages и dpkg-scansources. Далее такая структура каталогов отдаётся в сеть по http, ftp или nfs, используется локально или оформляется как отдельный CD/DVD носитель. Менеджер пакетов на клиенте узнаёт о существовании репозитария из списка источников, обычно хранящемся в файле /etc/apt/sources.list

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

Белонин С.С. (С), июнь 2004 года