Получение обновлений для рабочих мест в локальной сети

Когда у вас в сети имеется более чем одно рабочее место c установленным Mandriva Linux, возникает вопрос об доставке на них обновлений. Это можно сделать несколькими способами:

1. Настроить источники пакетов на каждом рабочем месте и проводить обновление децентрализовано;

2. Воспользоваться возможностью urpmi, а именно функцией parallel;

3. Воспользоваться возможностями FUSE посредством модуля LftpFS подключив FTP, HTTP, FISH, SFTP, HTTPS, FTPS ресурсы, как сетевой диск с возможностью кеширования и предоставить его в общее использование;

4. Организовать централизованное получение необходимых пакетов на сервере для последующего предоставления их рабочим местам.

Рассмотрим положительные и отрицательные стороны перечисленных пунктов:

1. В случае подключения внешних источников каждое рабочее место должно иметь выход в Интернет, общий объем получаемых данных из Интернет для обновления будет суммарно равен объему полученных пакетов для каждого рабочего места. Этот способ не критичен, если Интернет предоставляется по безлимитным тарифам и если канал доступа к Интернет достаточно широкий, чтобы не нагружать каналы связи при получении обновлений.

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

3. В случае использования модуля LftpFS для FUSE можно подключить удаленный источник пакетов и предоставить доступ на него рабочим местам в локальной сети. При настройке кеша, скачиваемые пакеты будут кешироваться в указанной директории и повторно скачены не будут, за исключением случаев, когда срок действия кеша истекает. Стабильность данного решения не гарантируется.

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

В данной статье будет рассмотрен четвертый вариант более подробно.

Данный метод будет работать по следующей структуре:
1. На сервере необходимо организовать общий ресурс на который рабочие места в локальной сети будут размещать свой базу данных установленных пакетов, создавая архив с определенным именем.
2. На сервере необходимо организовать общий ресурс с которого рабочие места будут забирать необходимые пакеты для установки.
3. На рабочих местах необходимо запланировать выполнение скрипта по архивированию и размещению базы данных установленных пакетов на ресурсе сервера. При этом архив должен иметь установленное имя, для корректного определения версии дистрибутива. Также на рабочем месте необходимо запланировать задание для автоматического получения и установки требуемых для обновления пакетов.
4. На сервере необходимо запланировать задание загрузки с внешних источников требуемых для рабочих мест пакетов и размещение их в установленном месте.

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

И так, имя архива будет иметь следующий вид: hostname-release-arch.tar.bz2

Во-вторых, общий ресурс можно сделать любым доступным способом, но на мой взгляд лучше всего организовать его посредством NFS. На этом общем ресурсе может размещаться как локальное зеркало дистрибутива, так и директория, содержащая скаченные пакеты, и директория, содержащая архивы баз установленных пакетов на рабочих местах. Данное централизованное размещение директорий облегчит манипуляцию с данными на них.

И так, предоставим в общий доступ по NFS следующую директорию: /home/updater
Точкой монтирования на рабочих местах будет, предположительно: /mnt/updater
Структура каталога updater:
RPMS/release/arch/
mandriva/official/release/arch/
rpmbases/


Рассмотрим скрипт создания архива базы установленных пакетов

#!/bin/sh

#Error level:
#1 - Каталог размещения архива базы установленных пакетов не обнаружен
#2 - Создание архива прошло не удачно

#устанавливаем каталог точки монтирования ресурса сервера
ROOTSERVERMEDIA=/mnt/updater

#Определяем номер релиза
PRODUCT=`sed "s/.*release \([0-9.]*\).*/\1/g" /etc/mandriva-release`

#Определяем архитектуру релиза
[[ `uname -m ` == 'x86_64'  ]] && ARCH=x86_64 || ARCH="i586"

#Устанавливаем место расположения базы rpm
rpmbase=/var/lib/rpm

#Устанавливаем директорию хранения архивов базы установленных пакетов
rpmbasefolder=rpmbases

#Устанавливаем имя файла архива базы установленных пакетов
filenamebases="$HOSTNAME-$PRODUCT-$ARCH.tar.bz2"

#Если директория  хранения архивов базы установленных пакетов не доступна - выходим
[[ -d "$ROOTSERVERMEDIA/$rpmbasefolder" ]] || exit 1

#Создаем архив
tar -cjf "$ROOTSERVERMEDIA/$rpmbasefolder/$filenamebases" "$rpmbase"

#Если при создании архива была ошибка выходм с ошибкой 2, если нет то с ошибкой 0
[[ $? == 0 ]] || exit 2
exit 0


Для того чтобы запланировать еждневное архивирование базы установленных пакетов, данный скрипт размещаем в директорию: /etc/cron.daily/

Для получения обновлений в автоматическом режиме следует добавить в директорию /etc/cron.daily/ следующий скрипт:

#!/bin/bash

#устанавливаем каталог точки монтирования ресурса сервера
ROOTSERVERMEDIA=/mnt/updater

#Определяем номер релиза
PRODUCT=`sed "s/.*release \([0-9.]*\).*/\1/g" /etc/mandriva-release`

#Определяем архитектуру релиза
[[ `uname -m ` == 'x86_64'  ]] && ARCH=x86_64 || ARCH="i586"

#Определяем место разполоежние источника обновления
updatfolder=$ROOTSERVERMEDIA/RPMS/$PRODUCT/$ARCH

#Проверяем наличие директории для получения обновления, если отсутсвует, то выходм с ошибкой 1
[[ -d $updatfolder ]] || exit 1

#Проверяем наличие добавленного источника обновления
[[ `fgrep -q updater /etc/urpmi/urpmi.cfg;echo $?` == "1" ]] && urpmi.addmedia --update updater $updatfolder

#Производим автоматическое обновление всех источников и последующую установку доступных пакетов обновлений
urpmi --auto-update --auto-select --auto

exit 0


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

#!/bin/bash

#устанавливаем каталог точки монтирования ресурса сервера
ROOTSERVERMEDIA=/mnt/updater

#Устанавливаем директорию хранения архивов базы установленных пакетов
rpmbasefolder=rpmbases

getrpms ()
{
TEMPRPMSROOT="$TMP/TEMPRPMSROOT"
RPMS=$ROOTSERVERMEDIA/RPMS/$1/$2
[[ -d "$RPMS" ]] || mkdir -p "$RPMS"
[[ -d $TEMPRPMSROOT ]] ||  mkdir -p "$TEMPRPMSROOT"

URL="http://mirror.yandex.ru/mandriva/official/$1/$2"
tar xjf $3 -C $TEMPRPMSROOT/
ret=1
while [ "$ret" == "1" ]
do
urpmi.removemedia -a
urpmi.addmedia --urpmi-root "$TEMPRPMSROOT" --distrib "$URL"
ret=$?
done
mount --bind $RPMS $TEMPRPMSROOT/var/cache/urpmi/rpms
ret=1
while [ "$ret" == "1" ]
do
urpmi --resume --noclean --no-install  --urpmi-root "$TEMPRPMSROOT" --downloader wget --download-all --auto --auto-select
ret=$?
done
umount $TEMPRPMSROOT/var/cache/urpmi/rpms
rm -rf $TEMPRPMSROOT
genhdlist2 --allow-empty-media --clean --xml-info --quiet $RPMS
}

for i in $ROOTSERVERMEDIA/$rpmbasefolder/*
do
    RELEASE=`echo $i | sed "s/.*-\([0-9.]*\)-.*/\1/g"`
    ARCH=`echo $i | sed "s/.*-\(i586\|x86_64\).*/\1/g"`
    getrpms $RELEASE $ARCH $i
    rm -f $i
done

exit 0


Выше приведенный скрипт размещаем в директорию /etc/cron.daily/ для выполнения скрипта ежедневно.
В целом данный набор скриптов поможет организовать автоматическую установку обновлений пакетов на рабочие места в локальной сети, при этом избежав лишнее потребление трафика.

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

Комментарии Вконтакте facebook

Комментарии (6)

rss свернуть / развернуть
+
0
Перед самым выходом Мандривы 2010.1, мы закоммитили поддержку zeroconf, но она не особо документирована…
avatar

eugeni_dodonov

  • 22 ноября 2010, 03:39
+
0
Ну, она стояла в планах и я ее находил… Но надо просто понять, как она работает…
avatar

akdengi

  • 22 ноября 2010, 07:52
+
0
Когда писал этот топик, поддержки zeroconf еще не было. Если интересно, могу покопаться в этом направлении и сделать дополнение к этому топику (все равно в отпуске с сегодняшнего дня).
avatar

BDag

  • 22 ноября 2010, 11:53
+
0
Сделайте — сейчас как раз начинаю разрабатывать «школьный сервер» и это пригодилось бы
avatar

akdengi

  • 22 ноября 2010, 12:04
+
0
Добавил новый readme в urpmi в cooker'е.
avatar

eugeni_dodonov

  • 22 ноября 2010, 16:43
+
0
Прочитал приложенный readme. Как и было анонсировано в спецификации посредством zeroconf можно находить и подключать источники пакетов, расположенные в пределах сети. Эта функция полезна только для того, чтобы пользователи могли подключить требуемые источники самостоятельно не прибегая к каким-либо ухищрениям по поиску требуемых источников. Но данный функционал не отменяет тот факт что для централизованного обновления разных версий дистрибутива нужно либо предоставить пользователю возможность скачивать обновления самостоятельно, либо содержать на сервере зеркало каждой используемой версии дистрибутива, либо придумывать хитрые «костыли» для загрузки и установки только требуемых пакетов.

Данный вывод сделан из файла readme и спецификации к 2010.1 релизу. Если я ошибаюсь, то прошу пояснить.

PS: также есть интересный проект в рамках urpmi — urpmi-ldap, но судя по описанию на WIKI это тоже хранилище описания источников.

PSS: Мне кажется в рамках централизованного обновления рабочих мест должен существовать модуль расширения urpmi для хранения базы пакетов не локально в директории /var/lib/urpmi, а в базе данных на сервере, тем самым облегчив администратору работу по сбору и анализу требуемых пакетов. Так же имея централизованное место сбора данной информации в сочетании с хранением в ней путей источников пакетов и необходимых параметров для каждого клиента позволит избежать создания много промежуточных скриптов по настройке конечных рабочих мест.
avatar

BDag

  • 22 ноября 2010, 19:56
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.
Блоги, Полезные советы и секреты, Получение обновлений для рабочих мест в локальной сети