Создание локального репозитория Ubuntu 10.04

Постепенный перевод предприятия на GNU/Linux порождает необходимость соответствующих изменений в инфраструктуре. Сегодня мы решаем проблему глобального обновления клиентских машин путем создания локального репозитория. Процесс изначально документировался как памятка на будущее, потому заранее прошу прощенья за возможные несуразности в тексте. Итак.
Для начала следует определиться, посредством чего лучше сделать это. Интернеты выделяют двух фаворитов rsync и debmirror. Выбрал последний, ввиду его большей гибкости.

1. Получение ключей


Для создания зеркала репозитория необходимо получить ключ «Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>». Для этого в терминале от суперюзера вводим:
gpg --no-default-keyring --keyring trustedkeys.gpg --recv-keys 437D05B5

2. Подготовка пространства


Создаем папку для репозитория:
sudo mkdir /path/to/repository
Важно! Потрудитесь проследить за наличием свободного места в указанном пути. Даже две архитектуры i386 и amd64 займут приличное его количество.

3. Получение пакетов


Зеркалирование проходит в три этапа:
  1. Загрузка индекстых файлов;
  2. Удаление неизвестных файлов (отключается опцией --nocleanup ниже);
  3. Построение списка по индексным архивам и проверка на наличие в локальном репозитории.Для реализации вышеперечисленного создадим файл 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

#Секции.
section=main,restricted,universe,multiverse

#Протокол синхронизации. 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://<ip_address_repository>/ubuntu/

5. Настройка клиентов


Здесь мы применим маленькую хитрость. Дабы не вносить изменений в /etc/apt/sources.list (мало ли что случится). Добавим в файл /etc/hosts пару строчек.
<ip_address_repository> ru.archive.ubuntu.com
<ip_address_repository> 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 система будет опрашивать наш репозиторий на предмет наличия обновлений и обновляться, если таковые будут найдены.

Внимание! При работе с crontab следует не забывать, что после строчек с заданиями обязательно должна быть пустая строка, которая обозначается знаком '#'.
p.s: Прошу прощения за отсутствие прилагаемых изображений, но в данном случае считаю их наличие просто неуместным.
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 26

    +2
    имхо, серверную часть не обязательно от рута запускать.
      +1
      Вы абсолютно правы. При наличии прав доступа на конечную папку и ключа запустить можно из под любого юзера.
      +2
      И устанавливать обновления по крону — это не лучший выход, ибо машинка может быть вырублена. Есть тьма путей, как это обойти, самый простой — устанавливать обновления при загрузке системы.
        +2
        вообще есть anacron, который отслеживает что не отработало задание, пока комп был выключен.
        а если пользователь один, и он же имеет рутовый пароль — аплет в гноме есть, который напоминает об обновлениях.
        0
        Apt-mirror, на мой вкус, попроще будет.
          0
          чем?
            0
            отмена предыдущего реквеста.
            ниже уже пояснили.
            +2
            Хорошая статья, автору спасибо!
              +1
              Полезно, полезно… Надо будет на будущее поместить в закладки…
                0
                apt-mirror
                  +2
                  Расскажите вкратце, чем это лучше прозрачного кеширующего прокси на восьмидесятом порту? Вашим пользователям действительно необходим весь репозиторий?
                    0
                    чуть ниже ответил :)
                    +1
                    Меня пугает перспектива выкачивать изначально 100 Гб пакетов, а потом ещё и постоянно обновлять их все. Ведь большинство из этих пакетов вообще никем будут не востребованы. Тогда зачем их все качать и постоянно обновлять?

                    Более приемлемой мне кажется идея с кэширующим прокси-сервером. Первая обновляющаяся машина в сети тянет обновления из инета через прокси, а уже все остальные скачивают эти файлы по локалке из кэша прокси. Итого качаются только те пакеты, которые хоть кому-то в локалке нужны, и из инета каждый качается единожды (по первому запросу).

                    Для реализации этой идеи предлагаю рассмотреть AptProxy.
                      0
                      Идея хороша, если список пакетов у всех одинаковый, а как же быть если различные группы юзеров работают с определенным набором ПО? Да, можно все суммировать и выкачивать через главную машинку. Но это не спасает от периодической необходимости что-то быстро развернуть. А быстрота может влететь в копеечку, ибо монополизации арендодателей помещений в сфере услуг связи никто не отменял. Это выливается в использовании услуг двух провайдеров. Местный — быстро, но дорого и безлимитный Yota, нормальная скорость работы которого достигается при достаточной разгрузке БС, т.е ночью. Следовательно в рабочее время выкачать нечто более менее увесистое может обернуться проблемой.

                      А что до 100 гигабайт, они получились в моем случае ( сырцы, две архитектуры, и все секции). Гораздо меньше места оно займет, если убрать все лишнее. Старался как можно подробнее расписать скрипт, дабы каждый смог отредактировать его под свои нужды. И да, это всего лишь один из вариантов, на его «православность» не претендую.
                        +1
                        Идея хороша, если список пакетов у всех одинаковый, а как же быть если различные группы юзеров работают с определенным набором ПО?
                        Не понял, какое тут имеет значение одинаковость ПО. Все пакеты, которые нужны хотя бы одному компьютеру, будут выкачиваться через прокси единожды. И всё равно это будет получаться гораздо меньше, чем качать и постоянно обновлять полный репозиторий.
                      0
                      вот вы бы написали, сколько весит ваш репазиторий.
                      и что еще, кроме ру.архива и секьюрити хорошо было бы отзеркалить.

                      Маленький хинт: первичное зеркало репы кошерно делать с внутреннего сервера какого-нибудь крупного частного провайдера. И скорость сто мегабит, и трафик халаявен.
                      Например для обитателей билайна — это ftp.corbina.net (/pub/Linux/ubuntu)
                        0
                        В данном контексте есть ещё и задача кастомизации конфигурации установки (в инсталяторе убунты вроде называется «профилями», типа там десктоп, разработка, итп)
                        Есть ли у «памятка» для этого?
                          +1
                          терминологическая придирка:
                          «гибче» всётаки rsync, поскольку он обеспечивает более базовые операции, с большей степенью свободы конфигурации.
                          а «debmirror» заточен на конкретную задачу, и в данном случае он «проще» или «удобнее», рад чего всегда жертвуется гибкость.
                            0
                            небольшое уточнение — debmirror в качестве одного из бакендов использует rsync, с практически любыми его опциями.

                            А то, что просто взяли и буквально перевели несколько man'ов — это да, это жестоко.
                            +1
                            По пунктам:
                            2. Важно учитывать не только место, но и количество свободных inodes на целевом разделе.
                            3. Запускаем скрипт и консоль на десятки часов занята. Поэтому первоначально скрипт repo_update.sh надо запускать по крону или в screen.
                            5. Браво. Вместо целевого конфига мы рисуем костыль. Если вы рисуете костыль на клиентах, значит их не так много. Тогда какой смысл для десятка-другого компьютеров выкачивать 100ГБ пакетов и потом их ибновлять? Мсье мазохист или прямо на точке обмена трафиком М9 сидит?

                            P.S. Чтобы вылезти из песочницы уже достаточно перевести/скопипастить стандартный howto? Не знал.
                              0
                              По пунктy:
                              3. У Вас особые предпочтения к консоли? Если нет — к Вашим услугам tty2...N. Или ctrl+z & fg, если уж очень невтерпёж
                              0
                              По пунктам:
                              3. В примечании указано примерный размер скачиваемого. Время — индивидуальный параметр. А масло маслянистым и масленным ежеминутно называть я считаю не слишком удачным ходом. Тем не менее подправил, спасибо.
                              5. Никто не мешает Вам поправить sources.list, об этом варианте я намекнул. Моей целью был упор на изменение записей в DNS, дабы клиентов не трогать вовсе, но в предверии отказа от контроллера домена на AD, с DNS приходится повременить. И да, выкачать порядка 30гб репозитория на одну архитектуру и еженочно обновлять ради десятка-другого компьютеров стоит. По крайней мере если у вас подключена Yota.

                              p.s: Вам помог стандартный howto? Мне нет. Вышеописанное — последовательность действий, которая привела к положительному результату и я буду рад, если описанная последовательность поможет кому-либо еще.
                                –1
                                > Моей целью был упор на изменение записей в DNS

                                Правка файла hosts и измнение в DNS — это костыли.

                                И вообще в своём DNS вы предлагаете создавать свою зону ubuntu.com всего с парой записей в ней для локального сервера репозиториев? Вы понимаете, что тогда любые хосты из зоны ubuntu.com ваши клиенты будут пытаться разрешить через ваш DNS (раз там есть такая зона), но они этого сделать не смогут. Т.е. какой-нить www.ubuntu.com, help.ubuntu.com, shop.ubuntu.com и т.д. они уже разрешить через DNS не смогут.

                                Что же теперь для корректной работы вручную поддерживать все записи в DNS-зоне ubuntu.com на своих DNS?
                                  0
                                  Простите, но причем здесь весь домен www.ubuntu.com? Речь идет о доменах третьего уровня, которые являются серверами репозиториев и в DNS на каждый из оных имеются свои записи.
                                    0
                                    Ну тогда напишите точнее, какие именно записи вы собираетесь создавать в DNS и где именно (в каких зонах).
                                    Например: «на внутренних DNS-серверах компании создаётся зона прямого просмотра с именем bbbbb.aaa, в этой зоне создаётся запись типа A с именем сссссс и значением xxx.xxx.xxx.xxx».
                                      0
                                      www.ubuntu.com это и есть домен третьего уровня!

                                Only users with full accounts can post comments. Log in, please.