Локальный сервер обновлений linux

Как настроить и использовать локальный репозиторий обновлений и программ внутри большой сети Ubuntu?

Я работаю в университете. Так, как админа у нас нет, я за него.

С недавних пор стал переводить учебку на Linux. Первыми были студенты. Все машини в старом компютерном класе сели на Xbuntu, в новом на Ubuntu. После установки я столкнулся с одной проблемой: после перезагрузки, система каждой машини отдельно начала закачивать обновления и языковую поддержку. Все бы ничего, только ставил я за один раз сразу на 5 машин. Интернет в тот день был просто кошмарным. Хорошо, что была субота.

В один прекрасный день/час/минуту/секунду, Ubuntu и Xubuntu всех машин стали дружно обновлятся, чем очень сильно заглушили канал Интернет на целый день. Мне это надоело.

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

Задача усложняется тем, что директор, который уже 3 месяца сидит под Ubuntu, просит перевести вообще все машины учебки на Ubuntu/Xubuntu. Другие пакеты он игнорирует. А машин уже около 100. Я представил себе, как они все хором начнут обновлятся и что станет с интернетом.

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

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

1. Как настроить и использовать локальный репозиторий обновлений и программ внутри большой сети Ubuntu & Xubuntu?

2. Как настроить клиентские машины обновлятся именно из локального сервера, а то, чего там не будет (например драйвера), пусть качает сам.

У нас есть 40(100) машин с разными параметрами системы, но с единой Ubuntu, обедененные в одну сеть и имеющие доступ к Интернету.

У нас есть некий сервер, который дает остальным машинам доступ к Интернет. Некий Usergate.

У нас есть некая машина, которая (теоретически) способна раздавать пакеты обновлений.

К сожалению скорость Интернета не дает возможности обновлятся или скачивать пакеты программ каждой машине отдельно.

У нас нет возможности загрузить весь репозиторий (говорят там около 23 гигов)

У нас нет возможности загрузки Операционки из сети.

Источник

Не спотыкается только червяк

Установка локального репозитория в сети с Debian/Ubuntu Linux

06.03.09 00:35 / Обновлено 17.11.10 11:24 | Версия для печати

Linux

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

Вариант с созданием локального зеркала репозитория был сразу отвергнут, потому что при этом трафик не экономился, а совсем наоборот. Зеркало содержало бы избыточный набор пакетов для разных архитектур, плюс каждый день обновлялись бы даже те пакеты, которые в локальной сети не использовались. Теоретически, конечно, можно было настроить и зеркало, но я пошёл по другому пути и установил apt-cacher.

По непроверенной (пока) информации apt-cacher больше не поддерживается, вместо него надо использовать apt-cacher-ng

Как работает apt-cacher

Cтоит на сервере и производит кэширование установочных пакетов (или пакетов обновления) .deb. Этот же сервер прописан на клиентских машинах как источник репозиториев.

Когда пользователь клиентской машины инициирует обновление или установку ПО, его машина подключается к серверу и запрашивает необходимые пакеты. При запрашивании пакета сервер проверяет, есть ли его последняя версия в локальном кэше и если есть, то пакет отправляется пользователю немедленно. В противном случае apt-cacher (apt-cacher-ng) скачивает обновлённую версию пакета, одновременно транслируя его пользователю. Новая версия остаётся в кэше для дальнейшего использования.

То есть, по сути, apt-cacher — это прокси для .deb-пакетов.

Настройка сервера

server — имя локального сервера обновлений.
192.168.0.0/24 — IP-адреса нашей сети.

Запускаем от имени суперпользователя:

Локальный репозиторий почти готов. Осталось отредактировать файл конфигурации /etc/apt-cacher/apt-cacher.conf:

В большинстве случаев этого достаточно.

Ставим apt-cacher на автозапуск. Для этого в файле /etc/default/apt-cacher определяем переменную AUTOSTART.

Для порядка можно сразу добавить в кэш пакеты, которые уже установлены на сервер. Выполняем в консоли:

Чтобы все изменения вступили в силу и сервер репозиториев заработал, надо перезапустить демона.

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

Способ «в лоб» — это отредактировать файл источников приложений /etc/apt/sources.list. В этом файле каждый адрес типа:

Надо заменить на

3142 — номер порта, который по умолчанию слушает apt-cacher.

Второй способ (предпочтительнее) — вместо того, чтобы менять каждую запись в sources.list и в каждом из дополнительных репозиториев, можно в /etc/apt/apt.conf добавить строчку:

Для этого можно выполнить команду:

для apt-cacher или

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

Чтобы проверить связь с репозиторием и обновить источники, выполняем:

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

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

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

Источник

Apt-cacher как корпоративный сервер обновлений для Ubuntu/Kubuntu/*buntu

Замена apt-mirror`у

В чем плюсы apt-cacher`a перед apt-mirror`ом?

Во-первых, в экономии трафика. Зачем качать один и тот же пакет несколько раз, если его уже скачал ваш коллега? Таким образом экономия трафика растет пропорционально количеству народу в конторе использующих *buntu.
Во-вторых, в экономии места на ЖД сервера, на котором установлен apt-cacher. Ведь зачем хранить 22 Гб пакетов на ЖД, если из них используются максимум 10Гб?
В-третьих, в скорости получения обновлений. Сколько раз вы обновляете свое зеркало обновлений? 1 раз в день? Apt-cacher позволяет получать обновления по мере их появления на офф. зеркале. Когда пользователь делает запрос на обновление(apt-get update) apt-caсher лезет на офф. зеркало проверить, нет ли обновлений того что у него лежит в кеше.
Безусловно у apt-cacher есть и минусы.
Первый минус — apt-cacher распределяет закешированные файлы по своей структуре, отличной от структуры debian-репозиториев. Но эту проблему можно решить, если вам важно сохранить структуры репозитория, это описано ниже.
Второй минус — необходимо наличие Веб-сервера Apache. Тут, к сожалению так просто проблему не решить, но я не думаю, что это существенная проблема 🙂

Установка и настройка apt-cacher`a

Сама установка довольно банальна для debian-пакетов
sudo apt-get install apt-cacher

Создадим папку для хранения кэша(т.е. самих пакетов) и назначим ей права
sudo mkdir /var/cache/apt-cacher
sudo chown www-data:www-data /var/cache/apt-cacher/*

Вы можете создать папку в любом месте
под юзером и группой www-data будет запускаться наш apt-cacher, так же под ним надо будет запускать Apache.

С настройкой немного сложнее, разбирать настройку самого apt-cacher`a, будем на примере.
Откроем для редактирования файл /etc/apt-cacher/apt-cacher.conf:
sudo nano /etc/apt-cacher/apt-cacher.conf

Рассмотрим пример конф. файла:
cache_dir=/var/cache/apt-cacher #директория которую мы создали и в котрой будет храниться кэш.
admin_email=root@localhost # мыло админа 🙂
daemon_port=9999 #порт на котором будет висеть наш apt-cacher
group=www-data #группа под которой будет запускаться наш apt-cacher
user=www-data #юзер под которой будет запускаться наш apt-cacher

allowed_hosts=* #хосты доступ с которых разрешен на наш сервер(по-умолчанию разрешено всем)
denied_hosts= #соответственно запрещен.

generate_reports=1 # раз в сутки будут генерироваться отчеты об использовании apt-cacher`a(1-генерить, 0 — нет)

clean_cache=1 #Очистка кэша раз в сутки,
offline_mode=0 #Если 0, то с apt-cacher будет тянуть обновления с офф. сервера, если 1, то раздавать только то что у него в кэше
logdir=/var/log/apt-cacher #папка в которой будут храниться логи доступа к apt-cacher`у
expire_hours=0 # apt-cacher может работать в двух режимах. В первом режиме сервер будет сравнивать expire_hours со временем последнего обновления пакета, и если оно становится меньше, то искать на офф. зеркале обновление для этого пакета, Во-втором режиме сервер будет сравнивать напрямую с офф.сервером, но в этом случае бОльшая вероятность рассинхронизации данных кэша и индексных файлов. Я всегда использую второй вариант, т.к. Для меня важнее получить вовремя обновление. 0 — Второй режим, все что больше 0 — то часы первого режима.
http_proxy= #адрес вашего прокси-сервера(если он у вас есть)
use_proxy=1 #Использовать(1) или нет(0) прокси.
http_proxy_auth= #Авторизация на прокси(формат: user:password)
use_proxy_auth= # Использовать ли авторизацию? (1-да, 0-нет)
limit=0 #Ограничитель скорости. 0 — нет ограничений. 250K — 250кбит/с, 2m — 2мбит/с
debug=0 #Уровень отладки. 0 — маленький лог файл, 1 — большой.
path_map = ubuntu archive.ubuntu.com/ubuntu ; canonical archive.canonical.com/ubuntu ; medibuntu packages.medibuntu.org/ ; #Самый интересный параметр. Настройка зеркал обновления, т.е. Откуда будут тянуться обновления.

Думаю с настройкой самого apt-cacher`a все(ну или почти все) ясно.
Теперь приступим к настройке Apache. Процесс настройки самого Apache я описывать не буду, в Сети много хороших руководств. Для работы всего этого должен быть установлен Perl и включен ExecCGI. Пример моего конфига(файл: /etc/apt-cacher/apache.conf
Alias /apt-cacher /usr/share/apt-cacher/apt-cacher.pl

Options ExecCGI
AddHandler cgi-script .pl
AllowOverride None
order allow,deny
allow from all

Вот. Настройка конф. файлов закончена. Теперь, думаю, самое время приступить к настройке рабочих станций, но для начала опишу как все-таки конвертнуть то, что было в кэше apt-mirror`а в apt-cacher.

Apt-mirror > apt-cacher

У apt-cacher`a есть perl скрипт для конвертации пакетов в формат apt-cacher`a, имя ему apt-cacher-import.pl, и лежит он в /usr/share/apt-cacher. Пользоваться им следующим образом:
/usr/share/apt-cacher/apt-cacher-import.pl -r -c /etc/apt-cacher/apt-cacher.conf /var/my_repos

-r — рекурсивный обход каталога
-c — не обязательный параметр, в котором указывается путь к конф. файлу.
/var/my_repos — директория к репозиторию формата apt-mirror(обычный дебиановский формат репозитория).

В результате этой команды, в папку /var/cache/apt-cacher будут скопированы и переведены в нужный формат все пакеты, которые будут найдены в /var/my_repos
Если вам необходимо оставить дебиановский репозиторий, при этом чтобы репозиторий apt-cacher`a не занимал дополнительного места, к команде добавьте -s, тогда скрипт просто сделает сим-линки на пакеты. НО! Если вы после этого удалите дебиановский репозиторий, то пакеты для apt-cacher`a так же будут не доступны(это же обычные сим-линки)
Если же вы использовали apt-proxy, то у apt-cacher`a тоже имеется скрипт для перевода его репозитория в свой. Скрипт лежит: /usr/share/apt-cacher/apt-cacher/apt-proxy-to-apt-cacher.pl.

Запуск демона и настройка клиентских машин.

Запустить сервер как обычно просто:
sudo /etc/init.d/apt-cacher start

Если вы не допустили синтаксических и иных ошибок в конфигурациях apache и apt-cacher`a, то сервер радостно запуститься, о чем сообщит вам не менее радостным сообщением [OK], если же произошла ошибка, то сервер сделает грустную гримасу и сообщит [FAIL]. Тогда вам придется все перечитать заново и возможно немного по`google`ить.
Чтобы проверить запуск можно зайти на localserver:9999 (где localserver — сервер на котором запущен apt-cacher).

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

Собственно нужно всего лишь добавить 1 строку(и закоментировать остальные) в файл /etc/apt/sources.list:
deb http://localserver:9999/ubuntu intrepid multiverse restricted main universe

Тут все как и в обыном репозитории, указываете что вам нужно обновлять, какой дистрибутив и т.п. Localserver — это сервер на котором запущен apt-cacher.

Если вы включили статистику, то её можно посмотреть localserver:9999/reports

Источник

Автоматизация обновления серверов с Debian/Ubuntu

А оно нам надо?

Конечно, если у Вас всего один «сервер», которым кроме Вас или соседа никто не пользуется, то следить за обновлениями довольно просто. Когда же речь заходит о десятках-сотнях серверов, становится очевидной проблема поддержания их в актуальном состоянии.

Обновления с заплатками в Debian/Ubuntu выходят почти каждый день. Уследить за всем этим бывает очень не просто. Вот тут и могут пригодиться описанные ниже программы.

apticron

apticron has detected that some packages need upgrading on:

example.com
[ 127.0.1.1 192.168.0.1 ]

The following packages are currently pending an upgrade:

acpid 1.0.4-5etch1
apache2-utils 2.2.3-4+etch10

Reading changelogs.
— Changes for acpid —
acpid (1.0.4-5etch1) oldstable-security; urgency=high

* Added upstream’s patch to fix CVE-2009-0798

— Michael Meskes Wed, 29 Apr 2009 12:26:56 +0200

— Changes for apache2 (apache2-utils) —
apache2 (2.2.3-4+etch10) oldstable-security; urgency=low

* Fix regression: A segfault could happen in mod_deflate in conjunction with
mod_php when a client aborts the connection.

— Stefan Fritsch Wed, 29 Jul 2009 11:39:06 +0200

You can perform the upgrade by issuing the command:

as root on example.com

It is recommended that you simulate the upgrade first to confirm that
the actions that would be taken are reasonable. The upgrade may be
simulated by issuing the command:

aptitude -s -y dist-upgrade

Из письма видно, что нужно обновить acpid и apache2-utils. Кроме этого в письме есть и описания изменений. Это очень удобно, когда Вы не получаете эти сведения из других источников (например, из списка рассылки debian-security-announce).

cron-apt

CRON-APT RUN [/etc/cron-apt/config]: Wed Jul 29 04:00:01 EEST 2009
CRON-APT SLEEP: 1172, Wed Jul 29 04:19:33 EEST 2009
CRON-APT ACTION: 0-update
CRON-APT LINE: /usr/bin/apt-get update -o quiet=2
CRON-APT ACTION: 3-download
CRON-APT LINE: /usr/bin/apt-get autoclean -y
Reading package lists.
Building dependency tree.
Reading state information.
CRON-APT LINE: /usr/bin/apt-get dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
Reading package lists.
Building dependency tree.
Reading state information.
The following packages will be upgraded:
dbus dbus-x11 dhcp3-client dhcp3-common libdbus-1-3
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/957kB of archives.
After this operation, 8192B disk space will be freed.
Download complete and in download only mode

Видно, что cron-apt скачал, но не устанавливал (!) обновления для dbus и dhcp.

unattended-upgrades

// allowed (origin, archive) pairs
Unattended-Upgrade::Allowed-Origins <
«Debian stable Debian-Security»;
>;

// never update the packages in this list
Unattended-Upgrade::Package-Blacklist <
// «vim»;
>;

Дополнительно, в секции Unattended-Upgrade::Package-Blacklist, можно указать список пакетов, которые нельзя обновлять. В данном примере там закомментированный vim.

После этого надо сказать apt, что мы хотим воспользоваться unattended-upgrade. Для этого создадим файл /etc/apt/apt.conf.d/10periodic и добавим туда следующие строки:

APT::Periodic::Update-Package-Lists «1»;
APT::Periodic::Download-Upgradeable-Packages «1»;
APT::Periodic::AutocleanInterval «1»;
APT::Periodic::Unattended-Upgrade «1»;

В итоге мы получим ежедневное обновление списка пакетов, загрузку доступных обновлений, удаление deb-файлов из кэша уже установленных пакетов и самое главное — автоматическую установку пакетов.

У unattended-upgrade есть один маленький недостаток — утилита никому (кроме лог-файла) не сообщает о том, что же собственно она сделала. Для того, чтобы узнавать о том, что она обновила, можно воспользоваться возможностью утилиты logrotate — отправкой лог-файлов на почту. Для этого пропишем следующие строки в файл /etc/logrotate.d/unattended-upgrades:

/var/log/unattended-upgrades/unattended-upgrades.log <
rotate 7
daily
mailfirst
mail mail@example.com
compress
missingok
notifempty
>

2009-08-01 17:50:57,596 INFO Initial blacklisted packages:
2009-08-01 17:50:57,596 INFO Starting unattended upgrades script
2009-08-01 17:50:57,596 INFO Allowed origins are: [«[‘Debian’, ‘stable’, ‘Debian-Security’]»]
2009-08-01 17:51:08,294 INFO Packages that are upgraded: libbind9-40 libisc45 libisccfg40 dnsutils libtiff4 liblwres40 bind9-host libisccc40 libdns45
2009-08-01 17:51:08,294 INFO Writing dpkg log to ‘/var/log/unattended-upgrades/unattended-upgrades-dpkg_2009-08-01_17:51:08.294492.log’
2009-08-01 17:51:11,169 INFO All upgrades installed

Как видно из лога, подробности (вывод dpkg) записаны в отдельный файл: unattended-upgrades-dpkg_2009-08-09_17:51:08.294492.log.

Заключение

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

Источник