Создание локального репозитория Ubuntu 10.04
Постепенный перевод предприятия на GNU/Linux порождает необходимость соответствующих изменений в инфраструктуре. Сегодня мы решаем проблему глобального обновления клиентских машин путем создания локального репозитория. Процесс изначально документировался как памятка на будущее, потому заранее прошу прощенья за возможные несуразности в тексте. Итак.
Для начала следует определиться, посредством чего лучше сделать это. Интернеты выделяют двух фаворитов rsync и debmirror. Выбрал последний, ввиду его большей гибкости.
1. Получение ключей
2. Подготовка пространства
Создаем папку для репозитория:
sudo mkdir /path/to/repository
Важно! Потрудитесь проследить за наличием свободного места в указанном пути. Даже две архитектуры i386 и amd64 займут приличное его количество.
3. Получение пакетов
Зеркалирование проходит в три этапа:
- Загрузка индекстых файлов;
- Удаление неизвестных файлов (отключается опцией —nocleanup ниже);
- Построение списка по индексным архивам и проверка на наличие в локальном репозитории.Для реализации вышеперечисленного создадим файл repo_update.sh со следующим содержанием.
#!/bin/sh
#Это конфигурация нашего репозитория. В зависимости от параметров, указанных
#здесь, мы получим нужное нам его содержимое.
#Опция cleanup. Включена по умолчанию. После закачки пакетов удаляет ранние
#версии. Для отключения опции необходим параметр —nocleanup
clean=—nocleanup
#Опция source. Закачивает исходные коды пакетов. Если вы не пользуетесь
#исходными кодами для изучения и модификации приложений ( что свойственно для
#бинарных дистрибутивов), смело ставьте опцию —no-source
src=—source
#Host. Имя сервера, откуда мы берем пакеты.
servername=mirror.yandex.ru
#Root. Корневая директория на выбранном нами сервере.
rdir=/ubuntu
#Имя релиза Ubuntu. Настройки для 10.04 версии.
release=lucid,lucid-backports,lucid-proposed,lucid-security,lucid-updates
#Протокол синхронизации. Debmirror поддерживает следующие способы: http,
#hftp, ftp, rsync
sync_protocol=rsync
#Архитектура. Если используются исключительно 32 или 64х битные системы.
#Одну из архитектур можно убрать. Также если используются иные архитектуры,
#их следует добавить.
arch=i386,amd64
#Местоположение репозитория. Указывайте локальную папку, созданную. в п 2.
path=/path/to/repository
debmirror —progress —verbose $clean $src —md5sums —host=$servername —root=$rdir \
—dist=$release -s=$section —method=$sync_protocol -a=$arch $path
Теперь поместим его в директорию /usr/local/bin и сделаем исполняемым.
chmod +x repo_update.sh
sudo cp repo_update.sh /usr/local/bin/
Далее запустим получившийся скрипт и дождемся завершения процесса. Процесс достаточно долгий. Время выполнения сильно зависит от ширины вашего интернет-канала.
sudo /usr/local/bin/repo_update.sh
Внимание! Размер скачиваемого переваливает за десятки гигабайт, а казеный интернет редко бывает безлимитным. Более того, debmirror чувствителен к стабильности соединения, 120 секунд простоя и все придется начинать сначала.
4. Настройка web-сервера
Дабы не совершать лишних плясок с бубном выберем протокол http, как традиционный метод предоставления доступа к репозиторию. Выбор web-сервера остается за Вами. Из фаворитов ngnix, apache и lighttpd, выбрал последний ввиду отсутствия опыта работы с оным (приятное с полезным, да). Итак.
sudo apt-get install lighttpd
Здесь все просто. Если Вы не планируете использовать в качестве www директории отличную от умолчания, то сервер в настройке не нуждается. Все, что сам нужно сделать, это создать символьную ссылку в директории /var/www
ln -s /path/to/repository /var/www/ubuntu
Проверим доступность репозитория из браузера: http:// /ubuntu/
5. Настройка клиентов
Здесь мы применим маленькую хитрость. Дабы не вносить изменений в /etc/apt/sources.list (мало ли что случится). Добавим в файл /etc/hosts пару строчек.
ru.archive.ubuntu.com
security.ubuntu.com
Примечание. При наличии DNS сервера можно все это прописать в нем, а на сервере репозитория прописать истинные адреса вышеупомянутых имен.
6. Автоматизация
А теперь самое сладкое. Заставим все это крутиться самостоятельно.
6.1 Серверная часть
В пункте #3 мы создавали скрипт, при помощи которого получали пакеты. Настроим его автозапуск средствами демона cron.
sudo crontab -e
В который добавим заветную строчку:
0 0 * * * /usr/local/bin/repo_update.sh
Теперь ежедневно в 0:00 наш скрипт будет делать за нас всю рутинную работу.
6.2 Клиентская часть
На клиентах создадим скрипт system_upd.sh в директории /usr/local/bin следующего содержания:
#!/bin/sh
apt-get -y update && apt-get -y upgrade && apt-get -y clean
Не забудем сделать его исполняемым.
sudo chmod +x /usr/local/bin/system_upd.sh
После чего открываем cron:
sudo crontab -e
И добавляем строчку:
40 17 * * * /usr/local/bin/system_upd.sh
Теперь каждый день в 17:40 система будет опрашивать наш репозиторий на предмет наличия обновлений и обновляться, если таковые будут найдены.
Источник
Развёртывание репозиториев Linux
1. Создаём ключ RPM-GPG-KEY. Стандартно.
/.rpmmacros следующего содержания:
3. Создаём директорию repo, а в ней директории i386, i686 и x86_64. Переносим туда ключ RPM-GPG-KEY
4. Скачиваем и раскладываем по директориям пакеты для соответствующих архитектур. Для i386 и i686 в большинстве случаев будут идентичные пакеты. Для x86_64 может не существовать пакета (например, TeamViewer), в этом случае кладётся соответствующий пакет i686 и в большинстве случаев он в RHEL работает.
6. Запускаем скрипт и отвечаем парольной фразой ключика на запрос.
7. Закачиваем на хостинг директорию repo и описываем репозиторий в /etc/yum.repos.d/nobody.repo
8. Проверяем работу репозитория
1. Создаём ключ DEB-GPG-KEY. Стандартно.
/.rpmmacros следующего содержания:
3. Создаём директорию repo, а в ней директории dists и pool. В них уже будет система каталогов. Переносим туда ключ DEB-GPG-KEY
4. В директории dists у нас будут храниться данные о пакетах, а в директории pool — сами пакеты. Причём из имени /binary-i386/t/teamviewer уже видно, что пакеты раскладываются по архитектурам, затем по буквенным директориям и затем по директориям с именами происходящими от названия содержащегося в них ПО (в них может лежать десяток пакетов необходимых конкретному ПО по его зависимостям). Т.е. имеется заданная иерархия.
5. Кладём в директорию repo скрипт для подготовки репозитория. Меняем в первой строчке скрипта key_pass=«password» на пароль Вашего ключа.
6. Запускаем скрипт и ждём когда он отработает.
Источник
Создаём свой репозиторий с deb-пакетами.
Мы научились собирать пакеты и подписывать их. Теперь самое время сделать свой репозиторий с пакетами.
По сути, есть 3 способа (более или менее «легальных») способа собрать свой репозиторий: dpkg-scanpackages, mini-dinstall и reprepo. dpkg-scanpackages — достаточно простая тулза, но требует много ручной работы. Я хоть и напишу про неё, но использовать её в промышленных масштабах не стоит. С reprepo я особенно не разобрался — официальная документация старовата и далека от вменяемости. Так что в основном здесь написано про mini-dinstall.
dpkg-scanpackages — утилита, которая индексирует каталог и создаёт для него файл Packages. Эту тулзу можно использовать как временную локальную замену (чтобы, например, проверить, что пакеты будут ставиться через apt-get), но не нужно использовать её там, где важна проверка подписи пакетов — dpkg-scanpackages сам по себе этого просто не умеет (хотя и можно подписывать репозиторий лапками).
Сам dpkg-scanpackages живет в пакете dpkg-dev, так что:
# apt-get install dpkg-dev
Представим, что наши пакеты в прошлых статьях мы собирали в /home/user/packages:
$ ls /home/user/packages
example-package_0.3_amd64.build example-package_0.3_amd64.changes example-package_0.3_amd64.deb
Тогда мы генерируем Packages.gz следующим образом:
$ dpkg-scanpackages -t deb /home/user/packages/ | gzip | cat > /home/user/packages/Packages.gz
А в sources.list.d добавляем строчку «deb file:/home/user/ packages/» :
# echo «deb file:/home/user/ packages/» > /etc/apt/sources.list.d/my-own-repo.list
Проверяем, что репозиторий работает:
# apt-get update; apt-cache policy example-package
.
example-package:
Installed: (none)
Candidate: 0.3
Version table:
0.3 0
500 file:/home/ inkvizitor68sl/ Packages
Так в простейшем виде работает и mini-dinstall — генерирует Packages.gz. Но он умеет проверять подписи пакетов, работать по крону/демоном и прочие плюшки.
Повеселились, хватит. Давайте ставить mini-dinstall и другой софт, который пригодится:
# apt-get install mini-dinstall debian-keyring gnupg acl
Дальше всё я буду расписывать исходя из того, что заливать пакеты в репозиторий будет несколько пользователей. Конечно, можно использовать dput и всё делать под одним пользователем, но если у вас полтора разработчика — то такой вариант вас уже не устроит и захочется предоставить возможность заливать пакеты с подписями разных разработчиков. Поэтому мы создадим отдельного пользователя и отдельный gpg-ключ, которым будем подписывать репозиторий. А подписи пакетов будем проверять перед тем, как добавить их в репозиторий.
Mini-dinstall незачем работать под рутом (если запустить его под рутом — нам не придется вводить целую дополнительную команду по выставлению вменяемых прав на каталог incoming, гы). Создадим отдельного пользователя:
# adduser repokeeper
Пойдем под этого пользователя:
# su repokeeper
Создадим папочку, куда будем складывать наш репозиторий:
$ mkdir /home/repokeeper/repo/
Напишем конфиг /home/repokeeper/.mini-dinstall.conf для нашей собиралки репозиториев:
/sign-release.sh
incoming_permissions = 0
chown_changes_files = false
Генерируем ключ уже знакомой нам командой:
$ LANG=C gpg —gen-key
Что там отвечать уже написано, стоит только заметить, что нам нужен именно новый ключ, а не ключ с теми же ответами. Ну там ник и почту измените для приличия.
Создадим каталог keys, в который для начала положим публичный ключ нашего репозитория. Там же мы будем складировать публичные ключи наших разработчиков (себя для начала).
$ mkdir /home/repokeeper/keys
Сначала экспортируем публичный ключ репозитория. Под пользователем repokeeper делаем такое:
$ gpg —export —armor repo@vlad.pro >
Где repo@vlad.pro — почта, которую мы использовали при генерации ключа для пользователя repokeeper.
Так же экспортируем ключ, которым мы подписываем пакеты и «добавим его» в валидные ключи для repokeeper (разрешив тем самым заливать пакеты, подписанные тем ключом). Под пользователем, из-под которого мы собираем пакеты, выполняем команду:
$ gpg —export —armor root@vlad.pro >
(напомню, что свою почту я использовал в прошлом примере)
Файл inkvizitor68sl.gpg нам нужно закинуть в каталог /home/repokeeper/keys на том сервере, где у вас будет работать mini-dinstall. О правах на файлы можно не сильно беспокоиться (в конце концов, это публичная подпись — обладая ей хуже вам не сделают).
Теперь под пользователем repokeeper импортируем ключ «разработчика»:
$ gpg —no-default-keyring —ignore-time-conflict —keyring .gnupg/pubring.gpg —import
Так же нам понадобится скрипт, который будет запускаться для подписывания собранного репозитория. Подходящий скрипт есть в документации к mini-dinstall, утащим его себе:
$ cp /usr/share/doc/mini-dinstall/examples/sign-release.sh
Немного подправим для своих нужд:
$ sed -i ‘s/export GNUPGHOME=.*/export GNUPGHOME=
/.gnupg/passphrase нужно написать пароль от GPG ключа, который мы сгенерировали для репозитория.
Так как мы запускаем mini-dinstall не от рута, нам нужны корректные права на его incoming-каталог. При помощи chmod/chown надежно добиться у нас этого не получится (разработчики обязательно будут заливать с такими правами, что у mini-dinstall не будет хватать прав на удаление залитых файлов — и он будет падать с ошибкой), посему сделаем это через acl:
# setfacl -R —modify user:repokeeper:rwx /home/repokeeper/repo/
# setfacl -R —modify group:repokeeper:rwx /home/repokeeper/repo/
# setfacl -R —modify default:user:repokeeper:rwx /home/repokeeper/
# setfacl -R —modify default:group:repokeeper:rwx /home/repokeeper/
А так же создадим группу, присутствие в которой будет позволять системным пользователям заливать пакеты на сервер (от рута):
# addgroup repouploaders
И выставим права этим пользователям на каталог incoming:
# setfacl -R —modify group:repouploaders:rwx /home/repokeeper/repo/mini-dinstall/incoming/
# setfacl -R —modify default:group:repouploaders:rwx /home/repokeeper/repo/mini-dinstall/incoming/
И добавим пользователя, от которого собираем пакеты в группу аплоадеров. Точнее, добавим пользователя, которому мы хотим дать права на заливание файлов в репозиторий. Это может быть и аккаунт разработчика, который будет заливать пакеты по sftp/scp через dupload.
# usermod -a -G repouploaders user
Заодно по дороге запретим заливать файлы всем остальным:
# chmod 0700 /home/repokeeper/repo/mini-dinstall/incoming/
«Зальём» наш собранный ранее пакетик в репозиторий. Сейчас мы это делаем при помощи простого cp, в будущем я напишу о том, как использовать dupload.
$ cp /home/user/packages/example-package_0.3_amd64.deb /home/repokeeper/repo/mini-dinstall/incoming/
$ cp /home/user/packages/example-package_0.3_amd64.changes /home/repokeeper/repo/mini-dinstall/incoming/
Наконец-то запускаем сборку нашего репозитория (обратите внимание, не от рута):
$ mini-dinstall -b -v
Если ошибок не видно, то проверяем содержимое файла Packages:
/repo/unstable/Packages | grep Package
Package: example-package
Как видим, у нас в репозитории появился наш example-package. Попробуем поставить его.
Для начала подключим репозиторий локально:
# echo «deb file:/home/repokeeper/repo/ unstable/» > /etc/apt/sources.list.d/my-own-repo.list; apt-get update
Проверяем, что пакет появился в индексе apt’a:
# apt-cache policy example-package
example-package:
Installed: (none)
Candidate: 0.3
Version table:
0.3 0
500 file:/home/repokeeper/repo/ unstable/ Packages
Пробуем его поставить:
# apt-get install example-package
.
Install these packages without verification [y/N]?
Фиг нам, как говорится. apt считает пакеты недоверенным. Что ж мы, зря мучались с подписями) ? Скормим публичный ключ нашего репозитория нашему локальному apt-у:
# cat /home/repokeeper/keys/repo.key | apt-key add —
OK
Обновим индекс apt-а, как обычно:
# apt-get update
Пробуем поставить пакет:
# apt-get install example-package
Вуаля. Поставился молча и сделал нам пустой /root/.ssh/authorized_keys, ибо я ленивая жопа и собрал таки пакет с пустыми файлами)
Теперь мы можем закидывать файлы в repo/mini-dinstall/incoming когда нам нужно и перегенерировать репозиторий командой от рута
# su -c «mini-dinstall -b -v» repokeeper
или просто от пользователя repokeeper
$ mini-dinstall -b -v
Дальше нам предстоит научиться использовать upload, запускать mini-dinstall по крону и демоном. А ещё не забыть расшарить репозиторий по http и https. А потом уже перейдем ко всяким забавным полезностям в dpkg.
Источник
