Сервер обновлений для linux

🤟 Как настроить автоматическое обновление на Ubuntu Linux 18.04

Как настроить автоматические обновления для сервера Ubuntu Linux 18.04 LTS «Bionic Beaver»?

Безопасность сервера Linux действительно важная задача для системных администраторов.

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

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

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

В этом руководстве показано, как автоматически устанавливать обновления безопасности в Ubuntu.

Автоматические обновления для Ubuntu Linux

Обновите сервер, запустив:

sudo apt update && sudo apt upgrade

Установите автоматические обновления в Ubuntu. Введите следующую команду apt

sudo apt install unattended-upgrades apt-listchanges bsd-mailx

Включите автоматические обновления безопасности, запустив:

sudo dpkg-reconfigure -plow unattended-upgrades

Настройте автоматические обновления, введите:

sudo vi /etc/apt/apt.conf.d/50unattended-upgrades

Настройте идентификатор оповещения по электронной почте:

Автоматически перезагружать Ubuntu без подтверждения обновлений ядра:

Наконец, отредактируйте файл /etc/apt/listchanges.conf и установите идентификатор электронной почты:

Сохраните и закройте файл.

Убедитесь, что это работает, выполнив следующую команду:

sudo unattended-upgrades —dry-run

Просмотр журналов автоматического обновления

Теперь, когда вы настроили автоматическое обновление на Ubuntu Server 18.04 LTS.

Пришло время посмотреть логи.

Следовательно, используйте команду grep, команду cat или несколько команд / egrep:

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -f /var/log/unattended-upgrades/unattended-upgrades.log
sudo grep ‘linux-image’ /var/log/unattended-upgrades/unattended-upgrades.log

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

Заключение

Вы узнали, как настроить автоматические обновления для вашего сервера на основе Ubuntu Linux.

Это самый простой способ защитить ваш сервер от уязвимостей.

Этот метод также полезен при администрировании нескольких серверов.

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

Однако для большого количества серверов / виртуальных машин я бы порекомендовал что-то вроде Ansible.

Источник

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 позволяют даже автоматически устанавливать обновления. Однако, единого выбора для всех быть не может, т.к. только администратор должен решить, можно ли обновлять тот или иной сервер автоматически.

Источник