LINUX.ORG.RU

CentOS Offline Update

 , ,


0

1

По какой-то причине репозитории большинства дистрибутивов и базы пакетов в них устроены таким образом, чтобы усложнить обновление системы изолированной от сети. В большинстве случаев база представляет собой набор файлов, не все из которых ещё и нужны для получения информации об обновлениях, и часто для оффлайн обновления предлагают создать локальный репозиторий/зеркало и обновляться из него, предварительно скачав десяток-другой гигабайтов никому не нужных пакетов. Это, например, меня не устраивает, особенно после использования Gentoo, где процедура оффлайн обновления очень простая.

Порывшись в <любимый_поисковик> я так и не нашёл устраивающих меня руководств по оффлайн-обновлению CentOS (плохо искал? возможно, что где-то это уже есть). Неужели ни для кого не актуально? В итоге опытным путём, посредством ковыряния live образа CentOS 7, выяснил, что для обновления локальной базы достаточно скачать всего несколько файлов, создать ещё пару: cachecookie, mirrorlist.txt - без них Yum будет ругаться, что база повреждена. Итак, предположим, что имеем свежеустановленную систему со стандартным набором ftp репозиториев base, extras, updates. При желании можно расширить bash-скрипт на epel или другие репозитории.

#!/bin/bash

MIRROR=ftp://mirror.yandex.ru/centos/7.2.1511

mkdir -p ./local_repo/x86_64/7
cd ./local_repo/x86_64/7

wget -nc -P "./base" $MIRROR/os/x86_64/repodata/repomd.xml
wget -nc -P "./base" $MIRROR/os/x86_64/repodata/*-x86_64-comps.xml.gz
wget -nc -P "./base" $MIRROR/os/x86_64/repodata/*-primary.sqlite.bz2

wget -nc -P "./extras" $MIRROR/extras/x86_64/repodata/repomd.xml
wget -nc -P "./extras" $MIRROR/extras/x86_64/repodata/*-primary.sqlite.bz2

wget -nc -P "./updates" $MIRROR/updates/x86_64/repodata/repomd.xml
wget -nc -P "./updates" $MIRROR/updates/x86_64/repodata/*-primary.sqlite.bz2

for item in base extras updates; do mkdir ./$item/gen && \
    bunzip2 -k ./$item/*.bz2 && \
    mv ./$item/*.sqlite ./$item/gen/primary_db.sqlite; done

for item in base extras updates; do touch ./$item/cachecookie; done

echo $MIRROR/os/x86_64/ > ./base/mirrorlist.txt
echo $MIRROR/extras/x86_64/ > ./extras/mirrorlist.txt
echo $MIRROR/updates/x86_64/ > ./updates/mirrorlist.txt

Скрипт создаст стуктуру каталогов со всеми необходимыми файлами для дальнейшего получения информации о пакетах, которые предстоит обновить или установить. Притащив полученную директорию на обновляемую машину и закинув её содержимое в «/var/cache/yum/x86_64/7/» (сразу после установки у CentOS база вообще отсутствует) можно спокойно получать список ссылок на пакеты, которые нужно обновить или установить, включая их зависимости. Циклов можно было сделать чуть меньше, а что-то в цикл запихнуть, но во время отладки так было проще.

Затем получаем список ссылок на скачивание пакетов:

# yum list updates | tail -n +3 | cut -d" " -f1 | xargs yumdownloader --urls --resolve | tail -n +4
или в файл
# yum list updates | tail -n +3 | cut -d" " -f1 | xargs yumdownloader --urls --resolve | tail -n +4 > pkgs_urls_list.txt

Но так скачаются все пакеты в один каталог, а нужно распихивать их потом в /var/cache/yum/.../<имя репозитория>/packages поэтому лучше создать отдельные файлы со ссылками для каждого репозитория. Получить список пакетов для обновления из каждого репозитория в отдельности можно командой, например для extras

# yum repository-packages extras list updates

или только названия пакетов

# yum repo-pkgs extras list updates | tail -n +4 | cut -d" " -f1

или получить список ссылок:

# yum repo-pkgs extras list updates | tail -n +4 | cut -d" " -f1 | xargs yumdownloader --urls --resolve | grep tp://

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

yumdownloader --urls --resolve имя_пакета | grep tp://

Остаётся только принести пакеты на обновляемый компьютер, разложить их по соответсвующим «/var/cache/yum/x86_64/7/имя_репозитория/packages» и обновить систему.

★★★★★

что за машина у тебя отделена от сети?

reprimand ★★★★★ ()
Ответ на: комментарий от reprimand

Допустим, что на работе есть комп, у которого нет выхода в инет, а если б и был, то это бы ему не помогло из-за сильного ограничения объёма выделяемого трафика. Gentoo было очень удобно пользоваться в этом плане дома, когда трафик был дорогой.

Для нескольких машин в изолированной локалке ещё имело бы смысл создавать локальное зеркало, но для отдельного компа смысла в этом не вижу.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

комп, у которого нет выхода в инет

вот мне и интересно что же это за компы такие, которым не дают выхода в интернет

reprimand ★★★★★ ()
Ответ на: комментарий от reprimand

Секрет! :)

На самом деле, загляни в любой НИИ, КБ - там такого добра навалом.

grem ★★★★★ ()
Ответ на: комментарий от grem

Секрет! :)

ой, ну конечно, прям таки секрет!

На самом деле, загляни в любой НИИ, КБ - там такого добра навалом.

Во всех подобных заведениях причиной был недостаток финансирование и отсутствие прямой необходимости.

reprimand ★★★★★ ()
Ответ на: комментарий от reprimand

Во всех подобных заведениях причиной был

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

grem ★★★★★ ()

Если список установленных программ на подключенной и не подключенной к интернету машине не отличается, достаточно делать yum update --downloadonly --downloaddir ..., а потом кидать все в локальный репозиторий не забывая делать createrepo.

Если разный, вроде должно подойти yum load-transaction yum_save_tx.XXX --downloadonly --downloaddir ..., с предварительным скачиванием repodata -- не пробовал.

разложить их по соответсвующим «/var/cache/yum/...

Ну это извращение — пропиши в yum.conf локальные репозитории.

arson ★★★★★ ()
Ответ на: комментарий от arson

Если список установленных программ на подключенной и не подключенной

держать где-то ещё, пусть в ВБ, такую же систему для обновления другой почему-то не хочется, а wget на текстовый файл я могу в любой системе натравить

пропиши в yum.conf локальные репозитории

это ещё большее извращение (зачем плодить сущности?), а в описанном случае я получаю такую же структуру файлов, как после обновления базы по сети

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

Допустим, что на работе есть комп...
почему-то не хочется...

Кто-то работает, а кто-то фигней занимается.
Ошибки случаются и в репозиториях, и во время установки. Намного быстрее сначала решить вопросы, а потом все перенести на рабочую машину.

а в описанном случае я получаю такую же структуру файлов

И зачем обезьянничать и копировать эту структуру?! Скопировал пакеты и repodata на флешку - вот тебе и репозиторий. Прописал локальный repo указывающий на флешку и обновляйся. Никаких лишний копирований, рассовываний по директориям не нужно.

arson ★★★★★ ()
Ответ на: комментарий от arson

Ошибки случаются и в репозиториях, и во время установки. Намного быстрее сначала решить вопросы, а потом все перенести на рабочую машину.

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

Скопировал пакеты и repodata

список которых ещё нужно сформировать; зачем копировать repodata с кучей лишних файлов, если можно получить готовую идентичную структуру как после запуска yum check-update?

Прописал локальный repo

И что в таком случае потом покажет команда yum repo-pkgs репозиторий list? Как узнать впоследствии откуда был на самом деле пакет после подключения других репозиториев?

Никаких лишний копирований, рассовываний по директориям не нужно.

зато нужно помнить какой была структура файлов на флешке, а «скопировать и распихать» можно готовым скриптом.

Я ж не говорю, что это единственно правильный и верный способ обновления, но меня интересовала описанная возможность.

Для сравнения могу описать процедуру оффлайнового обновления Gentoo, там всё намного проще.

grem ★★★★★ ()

Ничего не понял, можно же просто рсинкнуть ближайшее зеркало на внешний хард (i.e. http://mirror.yandex.ru/centos/) и указать этот хард в настройках yum. Я по крайней мере так делал на прошлой работе, где у кого-то была безопасность головного мозга и программисты сидели в отдельной сети без выхода в интернет.

d_a ★★★★★ ()
Ответ на: комментарий от d_a

скачав десяток-другой гигабайтов никому не нужных пакетов.

я так сразу и писал, что можно:

скачав десяток-другой гигабайтов никому не нужных пакетов.

но в постановке задачи хотелось обойтись без этого. Способов много, не отрицаю и разной степени удобства. Но в пятницу захотелось странного :)

программисты сидели в отдельной сети без выхода в интернет.

я заглядывал в одну контору, где одна группа тестировщиков сидела в своих отдельных комнатах, куда вход был по магнитным пропускам только для этой группы и выход в инет был только на сайты связанные с тестируемым проектом, в отличии от других групп, у которых выход в инет был свободный.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

Простите, я текст не читал, только картинки посмотрел. Только там не десяток-другой, там побольше, полная репа центоса на интранетовском зеркале для CI, деплоя и всякого такого прочего весит 143 GB прямо сейчас (что впрочем сущие копейки по моим меркам, у меня картинок с анимешными девками больше).

А если хочется совсем странного, то почему бы не посадить робота читать рассылку центоса, там у них автоматически отправляются письма с названиями и контрольными суммами опубликованных обновлённых пакетов, ну а дальше дело техники :) Можно было бы прямо nightly-паки с обновлениями автоматически генерировать, и называть их KBXXXXXX :)

d_a ★★★★★ ()
Последнее исправление: d_a (всего исправлений: 1)
Ответ на: комментарий от d_a

Это у меня по привычке гентушный подход к оффлайновому обновлению, там все distfiles весят 225.7 Гб (~75 тыс файлов) и делать срез зеркала и после его обновлять ни разу желания не возникало за 10 лет.

KBXXXXXX

смех смехом, а их для Windows 7 иногда вручную быстрее найти поисковиком, скачать и установить, чем через центр обновлений он их сам скачает. Особенно это касалось SP1, который почему-то виндой центром обновлений очень медленно скачивался.

grem ★★★★★ ()
Ответ на: комментарий от reprimand

Работа с секреткой. У нас есть один компьютер без физического доступа как к интернету, так и внутренней сети, стоит в отдельном кабинете, вход по спецпропуску. Этот компьютер используется для работы с данными, которые доставляются «спецконвертами». Еще один с физическим доступом к внутренней сети, интернету, который работает по специальным каналам связи. Доступ к нему тоже по спецпропуску. Все остальные компьютеры/пользователи в зависимости от многих факторов имеют свои ограничения.

anonymous ()
Ответ на: комментарий от grem

225.7 Гб (~75 тыс файлов)

Даже такое сольётся за ночь, я так думаю, а рсинком разницу докачивать быстро.

d_a ★★★★★ ()
Ответ на: комментарий от reprimand

ой, ну конечно, прям таки секрет!

Продолжаем верить в теорию о том, что во всех НИИ все разбазарено и нет финансирования? Ну ну.

bookman900 ★★★★★ ()
Ответ на: комментарий от reprimand

что за машина у тебя отделена от сети?

ещё в организации есть изолированные от внешнего мира (интернета) внутренние подсети

grem ★★★★★ ()

ТС, есть решение. но нужно терпение, 2 компьютера и куча свободного места.

1. первый компьютер должен быть подключен к сети. здесь должен быть centos, найди зеркала репозиториев, которые поддерживают rsync. через rsync делай копии репозитория. после пакуешь все, переносишь на флешку/жесткак, несешь на второй комп. там где не поддерживают rsync, все обновляешь через reposync.

2. на втором компе прописываешь новые репозитории у себя. обновляешь информацию с жесткого диска, через rsync.

повторять процедуру каждый день. у нас так и делают. молодые и подающие надежды специалисты.

Nurmukh ★★ ()
Последнее исправление: Nurmukh (всего исправлений: 1)
Ответ на: комментарий от Nurmukh

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

Для Debian есть apt-offline, который даже лучше описанного в теме способа (при сохранении минимизации переносимых объёмов) тем, что он тащит одновременно базу и сами пакеты, которые нужно обновить и даже ещё только хочется установить (и ничего лишнего, то есть тоже требуется мало дополнительного места) за один поход наружу с флешкой, в то время как в моём случае нужно 2 раза нести файлы (базы, потом сами пакеты).

grem ★★★★★ ()
Ответ на: комментарий от grem

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

Nurmukh ★★ ()
Ответ на: комментарий от arson

Ошибки случаются и в репозиториях, и во время установки. Намного быстрее сначала решить вопросы, а потом все перенести на рабочую машину.

Как раз обновился. Была чистая установка версии 7.1511 вышедшей в феврале. Узнал о CentOS много нового: дублирование пакетов во время обновления, запуск отложенных/прерванных транзакций, необходимость в некоторых случаях запускать yum с опцией --skip-broken, поиск дубликатов установленных пакетов (разных версий). Вот с последним не сразу разобраться получилось - дубликатов было много и утилитой «package-cleanup --cleandupes» ничего сделать не вышло - дубликатов было много и вываливалась ошибка «Error: Depsolving loop limit reached», вроде помогло создание файла «yum check duplicates | awk '{ print „sudo yum remove -y “ $NF }' > remove_dubs_1» и ещё один его запуск после повторного пересоздания. И по мелочи пришлось ещё раз переустановить новое ядро, а то отказывалось грузиться.

grem ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.