Як виявилося, шановний читачу, я досить рано закрив тему власного реозиторію, а тому цією короткою розповіддю хочу важливі моменти з точки зору супроводжувача репозиторію, з чим вас і вітаю. Підтримувати власний репозиторій виключно для однієї вітки дистрибутиву як мінімум нелогічно. Справа в тому, що цим ви обмежуєте використання продуктів вашої праці лише обраною для цього віткою — використання такого репозиторію для оновлення інших віток є надто небажаним в силу того, що можна запросто зламати систему залежностей пакета, що повертає нас до початкового тезису. Саме тому збирати пакети необхідно у відповідному середовищі(наприклад, chroot відмінно підходить для таких задач), і лиш потім завантажувати до відповідної вітки. В свою чергу, репозиторій повинен мати всі використовувані вітки. Ну а самому репозиторію, звісно, місце на сервері. Ця стаття присвячена таким важливим задачам, як віддалене завантаження нових пакетів в репозиторій та подальше його автоматичне оновлення, організація сумісного репозиторію для різних версій дистрибутиву та дещо інше.
В попередній статті ми створили репозиторій, що підтримує лиш одну вітку — unstable, або ж sid. Для підтримки інших репозиторіїв достатньо повторити вказані нами дані з деякими змінами, відділивши їх пустим рядком. Ось як виглядатиме конфігураційний файл conf/distributions після внесених змін:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | Origin: Jolly Roger Label: ITBlog sample repository Suite: unstable Codename: sid Architectures: amd64 source Components: main non-free contrib Description: Modified debian packages for personal use. SignWith: default Origin: Jolly Roger Label: ITBlog sample repository Suite: testing Codename: squeeze Architectures: amd64 source Components: main non-free contrib Description: Modified debian packages for personal use. SignWith: default Origin: Jolly Roger Label: ITBlog sample repository Suite: stable Codename: lenny Architectures: amd64 source Components: main non-free contrib Description: Modified debian packages for personal use. SignWith: default |
Слід зазначити, що окрім conf/distributions репозиторій містить ще декілька конфігураційних файлів, зокрема, conf/incoming. Цей файл визначає, звідки брати файли *.changes, як їх опрацьовувати та в яку вітку репозиторію класти результати. Про цей файл можна прочитати в документації з reprepro, а я лиш наведу власний:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | Name: lenny Default: lenny IncomingDir: incoming-lenny LogDir: logs-lenny TempDir: temp-lenny Name: squeeze Default: squeeze IncomingDir: incoming-squeeze LogDir: logs-squeeze TempDir: temp-squeeze Name: sid Default: sid IncomingDir: incoming-sid LogDir: logs-sid TempDir: temp-sid |
Як бачимо, файл містить кілька полів: ім’я правила «Name», кінцева вітка репозиторію «Default», директорія з вхідними файлами «IncomingDir», директорії для тимчасових («TempDir») та опрацьованих («LogDir») файлів. Для зручності імена правилам були дані відповідно до віток дистрибутиву. Слід не забути зробити відповідні директорії incoming-lenny, incoming-squeeze та incoming-sid в корені нашого репозиторію для отримання та обробки вхідних пакетів.
Для автоматичного опрацювання вхідних пакетів з наступним підписуванням репозиторію, слід або створити PGP-ключ без паролю, або скористатись послугами gpg-agent‘а з дууже тривалим TTL — часом, протягом якого замість повторного запиту пароля він буде взятий з кешу. Оскільки з точки зору безпеки в даному випадку (репозиторій знаходиться в домашній директорії мого власного користувача) обидва рішення не заслуговують на повагу, я покажу всі наступні дії на прикладі безпарольного сертифікату, деталі безпеки ж будуть наведені в кінці статті.
Маючи безпарольний сертифікат за замовчуванням, всі наступні операції з репозиторієм можна робити без жодного запиту до користувача. Автоматизацію оновлення репозиторію проведемо за допомогою планувальника cron, доступного в кожній системі. А для запуску я змайстрував ось такий коротенький скрипт:
1 2 3 4 5 6 | #!/bin/sh cd $HOME/htdocs/debian for i in lenny squeeze sid ; do reprepro -V processincoming $i 2>&1 done | mail -Es "Updating repository" maintainer@domain.com |
Цей сценарій можна періодично виконувати власноруч або з cron, в результаті після кожного оновлення репозиторію на поштову адресу maintainer@domain.com буде приходити повідомлення про виконані зміни. Опція «-E» команди mail дозволяє не надсилати листа, якщо тіло листа пусте. Таким чином, листи надходитимуть лише якщо була виконана певна робота, що дуже зручно.
Саме час налаштувати віддалене оновлення репозиторію, для чого скористаємося утилітою dupload. Її конфігурація доволі проста, тому я лише наведу власний файл ~/.dupload.conf, який використовує scp для надсилання необхідних файлів.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | package config; $cfg{'repo-lenny'} = { fqdn => "domain.com", login => "user", method => "scp", incoming => "htdocs/debian/incoming-lenny", dinstall_runs => 1 }; $cfg{'repo-squeeze'} = { fqdn => "domain.com", login => "user", method => "scp", incoming => "htdocs/debian/incoming-squeeze", dinstall_runs => 1 }; $cfg{'repo-sid'} = { fqdn => "domain.com", login => "user", method => "scp", incoming => "htdocs/debian/incoming-sid", dinstall_runs => 1 }; |
Надіслати файли на сервер для оновлення репозиторію тепер можна однією командою, вказавши шлях до *.changes файлу:
$ dupload --to mirror-sid debian/rtorrent_1121svn-1.1_amd64.changes
Тепер лишилося дочекатися виконання періодичної задачі і отримати листа в поштову скриньку:
І на додачу, для труЪ і параноїків: якщо ви хочете звести до мінімуму ризик дискредитації вашого репозиторію, слід скористатися наступними порадами:
- Тримайте репозиторій під окремим системним користувачем з відключеною можливістю входу. Також виконуйте періодичні задачі з-під цього облікового запису
- Закрийте можливість перегляду конфігураційних файлів, встановивши права 700 на директорії conf та ~/.gnupg. Для всіх інших директорій встановіть лише права читання. Лише директорія incoming повинна залишитися доступною для запису всім охочим.
- Якщо ваш репозиторій публічно доступний, не забудьте додатково обмежити доступ до директорії conf в конфігураційних файлах вашого web- або ftp-сервера.
- Обмежте коло осіб та список доступних їм операцій по завантаженню нових файлів в репозиторій, скориставшись конфігураційною опцією «Uploaders» в reprepro.
- Не використовуйте один і той же сертифікат для підписування пакетів та репозиторію. Також забороніть обробку пакетів підписаних сертифікатом «для репозиторію».
Мушу запевнити, якщо при дотриманні всіх цих порад репозиторій таки скомпрометують, то це може значити лише одне — хтось заволодів правами root на вашому сервері, і тоді репозиторій стане чи не найменшою проблемою, що вас турбуватиме.
Що ж, на цьому дозвольте відкланятись. Нехай щастить!