Обновление программного обеспечения в репозитории Ubuntu.! Обновление программы в журнале FBS

Из этой статьи вы узнаете что такое репозитории в Linux. Мы научимся их настраивать на примере Debian 11 и Ubuntu 22.04.

Цели статьи

1. Рассмотреть различные ветки официальных репозиториев.
2. Подробно рассказать, как настраивать репозитории в debian.
3. Показать на примере, как настроить локальный репозиторий.
4. Составить список актуальных репозиториев для старых версий Debian.

Для любого сервера необходимо иметь возможность оперативно получить актуальное свежее программное обеспечение. Я расскажу, как настраивать список репозиториев в Debian — добавлять, удалять, редактировать разные repository в sources.list. Разберем внимательно эту тему, обратив внимание на различные нюансы, которые присутствуют, как и в любом другом деле.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный тест.

Данная статья является частью единого цикла статьей про сервер Debian.

Для любого сервера необходимо иметь возможность оперативно получить актуальное свежее программное обеспечение. Установка репозиториев epel, rpmforge и др. repo для CentOS решает вопрос получения rpm пакетов для последующей настройки и обновления функционала сервера. Так что уделим внимание этому вопросу и разберемся в тонкостях, которые тут присутствуют, как и в любом другом вопросе.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный тест.

Данная статья является частью единого цикла статьей про сервер Centos.

Очистка системы от ненужных пакетов

Удаление ненужных пакетов

Когда мы устанавливаем пакет то устанавливаются и его зависимости. А при удалении пакета зависимости остаются и больше не используются. Чтобы удалить подобные пакеты, которые установились, но больше не нужны в системе применяются команды apt-get autoremove или apt autoremove. Например:

$ sudo apt-get autoremove
$ sudo apt autoremove

Очистка кэша

При установке какого-нибудь пакета, он вначале скачивается в каталог /var/cache/apt/archives/, а затем устанавливается в систему. Эти установочные файлы тоже можно удалять, освобождая место на диске. Для этого используйте команды apt-get clean или apt clean, например

$ sudo apt-get clean
$ sudo apt clean

Мягкая очистка кэша

Помимо clean есть более мягкая команда autoclean. Она удалит только те скаченные пакеты, у которых версия ниже чем в репозитории, остальные пакеты не удалятся:

$ sudo apt-get autoclean
$ sudo apt autoclean

Подключение репозиториев в CentOS

Добавить репозиторий в CentOS можно тремя разными способами:

1. Добавив секцию [repository] в файл /etc/yum.conf
2. Создав .repo файл в директории /etc/yum.repos.d
3. Установив rpm пакет с информацией о репозитории

Как уже было сказано ранее, первый способ использовать не рекомендуется самими разработчиками. Наиболее быстрый и удобный третий способ. Если rpm пакета для добавления репозитория не существует, то используется вручную второй способ.

Установка remi repo в CentOS

Les RPM de Remi repository поддерживает последние версии MySQL и PHP (бэкпорты федоровских rpm). Пакеты этого репозитория необходимо использовать с осторожностью, так как они заменяют базовые пакеты.

Установка репозитория remi в centos:

1. # wget http://rpms.remirepo.net/enterprise/remi-release-7.rpm

2. # rpm -Uvh remi-release-7*.rpm

# cd /etc/yum.repos.d
# ls -l | grep remi
-rw-r--r--. 1 root root 698 Jul 23 17:54 remi-php70.repo
-rw-r--r--. 1 root root 2382 Jul 23 17:54 remi.repo
-rw-r--r--. 1 root root 449 Jul 23 17:54 remi-safe.repo

Remi’s RPM repository репозиторий установлен.

Удалить репозиторий в CentOS

Для того, чтобы удалить репозиторий из системы, необходимо узнать его id с помощью команды yum repolist. Об этом я писал в предыдущем разделе. Затем с помощью утилиты yum-config-manager, которая входит в пакет yum-utils выполним удаление:

# yum-config-manager --disable remi-safe
bash: yum-config-manager: command not found

Если получаете такую ошибку, то установите пакет yum-utils:

# yum -y install yum-utils

Удаление репозитория в centos:

# yum-config-manager --disable remi-safe

Теперь проверяем список активных репозиториев:

Удаленного репозитория remi-safe нет. Значит все в порядке, отключение репозитория прошло успешно.

Для того, чтобы обновить кэш yum после изменения репозиториев, можно воспользоваться следующими командами:

Очистить кеш:

# yum clean all

Пересоздать кеш:

# yum makecache

Yandex mirror для CentOS

mirror.yandex.ru — сайт компании Яндекс, зеркало репозитариев популярных дистрибутивов Linux, FreeBSD и других проектов, в том числе CentOS. Работает по протоколам HTTP, FTP и rsync.

Можно использовать, что я неоднократно делал, yandex mirror для сетевой установки CentOS. Путь к установочному образу: http://mirror.yandex.ru/centos/7/os/x86_64/images/

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

Напоминаю, что данная статья является частью единого цикла статьей про сервер Centos.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Работа с отдельными пакетами

Установить пакет из репозитория можно с помощью команд apt-get install <имя пакета> или apt install <имя пакета>. При этом установится пакет и его зависимости. Пример:

$ sudo apt-get install apache2
$ sudo apt install apache2

Удаление пакета без удаления конфигов

Чтобы удалить пакет обычно используют команды apt-get remove <имя пакета> или apt remove <имя пакета>. Но эти команды удалят только само приложение, не удалив его конфиги. Пример:

$ sudo apt-get remove apache2
$ sudo apt remove apache2

Удаление пакета вместе с конфигами

А чтобы удалить приложение вместе с его конфигами используйте команды apt-get purge <имя пакета> или apt purge <имя пакета>, например:

$ sudo apt-get purge apache2
$ sudo apt purge apache2

Для переустановки используйте команды apt-get install –reinstall <имя пакета> или apt install –reinstall <имя пакета>.

$ sudo apt-get install --reinstall apache2
$ sudo apt install --reinstall apache2

Обновление отдельного приложения

Если нам нужно обновить не всю систему а отдельный пакет, то тут нужно использовать знакомую команду apt-get install <имя пакета> или apt install <имя пакета>. При этом, если пакета нет в системе то он установится, а если есть то обновится. Пример:

$ sudo apt-get install apache2
$ sudo apt install apache2

Скачивание пакета без установки

$ apt-get download apache2
$ apt download apache2

При этом зависимости скачиваться не будут.

Если вы хотите чтобы система больше не обновляла какой-то отдельный пакет то выполните apt-mark hold <имя пакета>, например:

$ sudo apt-mark hold apache2

К сожалению с помощью apt это проделать невозможно.

Обновление системы

Обновление кэша пакетов

В Debian и Ubuntu прежде чем обновлять систему, нужно выяснить, какие обновления доступны в репозиториях. Это так называемое обновление кэша пакетов. Выполняется оно с помощью команды apt-get update или apt update. Пример:

$ sudo apt-get update
$ sudo apt update

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

Получаем список возможных обновлений

Если есть пакеты, которые можно обновить, то мы можем посмотреть их с помощью команды apt list –upgradable, а опция -a выводит больше информации. С помощью apt-get это проделать невозможно.

$ sudo apt list --upgradable -a

Обновление системы (без возможности удаления пакетов)

Перед обновлением расскажу про зависимости пакетов. Работа некоторых приложений зависит от других приложений или библиотек. Поэтому почти каждый пакет имеет список зависимостей других пакетов. Обычно вручную с зависимостями не работают. Просто пакетные менеджеры (apt или apt-get) при установке определённого пакета также устанавливают пакеты от которых зависит этот пакет.

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

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

Без возможности удаления пакетов вы можете выполнить обновление с помощью команд apt-get upgrade и apt upgrade. Например:

$ sudo apt-get upgrade
$ sudo apt upgrade

Обновление системы (с возможностью удаления пакетов)

Если вы все-таки хотите обновить пакеты и вас не пугает удаление некоторых пакетов, то выполните следующие команды: apt-get dist-upgrade или apt dist-upgrade. Но это более рискованно, так что обратите особое внимание на то, какие пакеты будут удалены. Ведь удаление некоторых пакетов может просто сломать вашу систему. Пример:

$ sudo apt-get dist-upgrade
$ sudo apt dist-upgrade

Архитектура пакетов

Если вы ещё раз посмотрите на файл Release в репозитории, то можете заметить там строчку:

Architectures: amd64 arm64 armhf i386 ppc64el riscv64 s390x

Здесь прописаны архитектуры пакетов, которые хранятся в репозитории. Прописывая источник репозитория, например в конфиге /etc/apt/sources.list вы можете указать определённую архитектуру, чтобы предотвратить скачивание и установку пакетов для других архитектур.

Это делается таким способом:

### Пример для Debian ###
deb [arch=amd64] http://deb.debian.org/debian/ bullseye main

Репозитории в CentOS

Для начала давайте поясним, что такое репозитории и для чего они нужны. Вот что говорит wikipedia на этот счет:

Репозито́рий, хранилище — место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети.

Существуют репозитории для хранения программ, написанных на одном языке (например, CPAN для Perl) или предназначенных для одной платформы. Многие современные операционные системы, такие как OpenSolaris, FreeBSD и большинство дистрибутивов Linux, имеют официальные репозитории, но также позволяют устанавливать пакеты из других мест. Большинство репозиториев бесплатны, однако некоторые компании предоставляют доступ к собственным репозиториям за платную подписку.

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

В нашем случае репозиторий — хранилище пакетов для операционной системы CentOS. Существуют repository от разработчика системы, их называют официальные. Набор rpm пакетов там обычно ограничен и версии не самые свежие. Для установки дополнительного софта используют сторонние репозитории. Их поддерживать могут как другие компании, так и группы энтузиастов.

Управлением пакетами и репозиториями в CentOS занимается утилита yum. Ее конфигурационный файл находится в /etc/yum.conf. Этот файл содержит секцию [main], в которой указываются глобальные настройки программы. Так же он может содержать одну или несколько секций [repository], в которой хранятся настройки репозиториев. Тем не менее, рекомендуется информацию о репозиториях хранить в каталоге /etc/yum.repos.d/ в специальных файлах .repo.

Минимальное содержание файла .repo следующее:

[repository]
name=repository_name
baseurl=repository_url

Другие ползные параметры, которые могут быть указаны в repo файле:

Вот содержание стандартного файла с репозиториями CentOS /etc/yum.repos.d/CentOS-Base.repo:

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Sources List Generator (генератор списка репозиториев)

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

Пример такого генератора, который вы можете установить себе и настроить для использования — debgen. Исходники раньше были на github, но потом пропали. А вот его готовая реализация с наполнением — https://debgen.simplylinux.ch/.

Я не знаю, кто ведет подобные List Generator и можно ли им доверять. Всегда проверяйте список репозиториев, который будет сгенерирован для вас. По сути, это обычный текстовый файл, который вы скопируете себе.

К примеру, я указал в List Generator, что мне надо подготовить список репозиториев со следующими параметрами:

1. Репозиторий Stable
2. Ветка main (просто отключил ветки contrib и non-free)
3. Mirror — Russia
4. Включить репозитории Security и Updates
5. Добавить repo для софта — Docker, MariaDB, Nginx, NodeJS, Php, Webmin

В итоге получил вот такой sources.list

#------------------------------------------------------------------------------#
# OFFICIAL DEBIAN REPOS
#------------------------------------------------------------------------------#
###### Debian Main Repos
deb http://ftp.ru.debian.org/debian/ stable main
deb http://ftp.ru.debian.org/debian/ stable-updates main
deb http://security.debian.org/ stable-security main
#------------------------------------------------------------------------------#
# UNOFFICIAL REPOS
#------------------------------------------------------------------------------#
###### 3rd Party Binary Repos
###Docker CE
deb [arch=amd64] https://download.docker.com/linux/debian bullseye stable
###MariaDB
deb [arch=i386,amd64] http://mirror.23media.de/mariadb/repo/10.6/debian bullseye main
deb-src [arch=i386,amd64] http://mirror.23media.de/mariadb/repo/10.6/debian bullseye main
###nginx
deb [arch=amd64,i386] http://nginx.org/packages/debian/ bullseye nginx
deb-src [arch=amd64,i386] http://nginx.org/packages/debian/ bullseye nginx
###NodeJs
deb https://deb.nodesource.com/node_12.x bullseye main
deb-src https://deb.nodesource.com/node_12.x bullseye main
###PHP
deb https://packages.sury.org/php/ bullseye main
###Webmin
deb http://download.webmin.com/download/repository sarge contrib

К нему еще список gpg ключей для импорта. В принципе, к списку у меня претензий нет. Все по делу. Нужно только проверить php и mariadb repository. Мне предложенные не знакомы.

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

Локальный репозиторий

Есть несколько способов создать локальный репозиторий Debian. Из того, что я пробовал, самым простым и удобным мне показался apt-mirror, но у него есть один баг, если его использовать как зеркало официальных репозиториев. Он не качает переводы в формате .gz и.xz, только .bz2. В итоге, когда будете использовать локальный репозиторий в качестве зеркала официального, получите ошибку:

File not found updates/main/i18n/Translation-en (2: No such file or directory)

Другой простой вариант — использовать reprepro. Я не буду подробно останавливаться на настройке локального репозитория для Debian, так как это отдельная тема. По хорошему, репозиторий надо подписать gpg ключом, опубликовать с помощью http или ftp, может еще как-то. Я только кратко покажу, как это делается, чтобы вы понимали, что это вообще такое. А если реально нужен будет локальный репозиторий, вы без проблем найдете его подробную настройку. Там нет ничего сложного.

# apt install reprepro

Дальше создаем каталог для локального репозитория и конфиг.

# mkdir -p /mnt/repo/debian/conf
# touch /mnt/repo/debian/conf/distributions

Конфиг делаем примерно следующего содержания.

Codename: bullseye
Suite: stable
Version: 11.x
Origin: Debian
Label: Debian 11.x
Description: Debian Stable Updates Repository
Architectures: amd64 source
Components: main
DebIndices: Packages Release . .gz .bz2
DscIndices: Sources Release . .gz .bz2
Contents: . .gz .bz2

Выполняем инициализацию репозитория.

# cd /mnt/repo/debian
# reprepro export
# reprepro createsymlinks

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

# reprepro -b /mnt/repo/debian --ask-passphrase includedeb bullseye /home/package.deb

Для того, чтобы подключить локально новый репозиторий, его нужно добавить в sources.list.

deb [trusted=yes] file:/mnt/repo/debian bullseye main

После этого выполняете обновление кэша пакетов и увидите в списке репозиториев свой локальный.

Посмотрим на корову 🙂

А еще с помощью apt-get и apt мы можем посмотреть на корову:

$ apt moo (__) (oo) /------\/ / | || * /\---/\ ~~ ~~
..."Have you mooed today?"...
$ apt-get moo (__) (oo) /------\/ / | || * /\---/\ ~~ ~~
..."Have you mooed today?"...

Вариант использования официальных репозиториев

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

Вообще в Debian дан список самых безопасных репозиториев по умолчанию. Можем лишь закомментировать репозитории с исходниками, так как скорее всего вам они пока не понадобятся. Напомню, что такие строки начинаются со слова deb-src. А если понадобятся вы их просто раскомментируете. После правки у нас осталось 3 источника пакетов:

alex@deb:~$ egrep -v '^#|^$' /etc/apt/sources.list | cat -n 1 deb http://deb.debian.org/debian/ bullseye main 2 deb http://security.debian.org/debian-security bullseye-security main 3 deb http://deb.debian.org/debian/ bullseye-updates main

Ubuntu при установке прописала намного больше своих репозиториев. Но их тоже можно свести к трем. Например, я считаю нужным отключить universe, multiverse и jammy-backports репозитории на сервере. После правки список репозиториев также состоит из 3-ёх строк:

alex@ubu:~$ egrep -v '^#|^$' /etc/apt/sources.list | cat -n 1 deb http://ru.archive.ubuntu.com/ubuntu jammy main restricted 2 deb http://ru.archive.ubuntu.com/ubuntu jammy-updates main restricted 3 deb http://ru.archive.ubuntu.com/ubuntu jammy-security main restricted

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

$ sudo apt update

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

А если хотите обновить систему, то выполните команду:

$ sudo apt upgrade

Эта команда уже скачивает все обновления и устанавливает их.

Кстати утилита apt – это и есть менеджер пакетов. Рассмотрим её и другие менеджеры пакетов в следующих статьях.

Установка epel repo в CentOS

Полностью epel репозиторий называется так — Extra Packages for Enterprise Linux. Это хранилище пакетов, созданное группой специалистов операционной системы Fedora. Пакеты из epel репозитория никогда не конфликтуют и не переустанавливают базовые пакеты RHEL. Поддерживаются пакеты для следующих операционных систем:

• Red Hat Enterprise Linux (RHEL)
• CentOS
• Scientific Linux (SL)
• Oracle Linux (OL)

Установить репозиторий epel в CentOS проще всего, так как epel-release package включен в стандартный Extras repository CentOS, который доступен по-умолчанию. На сегодняшний день это самый популярный неофициальный репозиторий для CentOS.

Установка репозитория epel в centos:

# yum -y install epel-release

Теперь если проверим папку /etc/yum.repos.d, увидим там файл epel.repo, в котором будет информация о новом подключенном репозитории.

Ветки main, contrib, non-free

Каждый официальный репозиторий Debian имеет по 3 ветки:

1. main состоит из DFSG-compliant пакетов, которым не требуется другое ПО из других источников. Эти пакеты считаются частью дистрибутива Debian. Они полностью свободны для любого использования.
2. contrib пакеты так же содержат DFSG-compliant ПО, но их зависимости могут требовать дополнительное ПО, которое может быть в других источниках, например ветке non-free.
3. non-free содержит все остальное ПО, которое не соответствует DFSG.

DFSG — Debian Free Software Guidelines, критерии Debian по определению свободного ПО. В любом случае, пакеты из всех трех веток main, contrib и non-free полностью протестированы и подготовлены для работы с дистрибутивом Debian.

Теперь, зная всю теорию по репозиториям в Debian, мы можем проанализировать файл sources.list, который мы получили после установки. В нем подключены 3 репозитория с ветками main.

deb http://deb.debian.org/debian bullseye main
deb-src http://deb.debian.org/debian bullseye main

Это stable repo текущего релиза. Далее идет security repository для установки свежих обновлений безопасности.

deb http://deb.debian.org/debian-security/ bullseye-security main
deb-src http://deb.debian.org/debian-security/ bullseye-security main

И в завершении stable-updates для получения стабильных обновлений до очередного Point Release текущего дистрибутива.

deb http://deb.debian.org/debian bullseye-updates main
deb-src http://deb.debian.org/debian bullseye-updates main

Признаюсь честно, я много лет администрировал сервера с Debian, а до конца не понимал, что у меня записано в sources.list. Разобрался полностью только сейчас, когда писал статью. До этого просто копировал по привычке конфиги с репами. Догадывался о чем там речь, но точно не знал. Теперь восполнил пробел и поделился с вами информацией.

Возможные ошибки

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

Репозиторий не содержит файла Release

Текст ошибки, по идее, дает готовый ответ. В репозитории нет обязательного файла Release. Но суть в том, что он скорее всего есть. Дело тут чаще всего в том, что вы добавили к себе репозиторий, который не содержит указанной вами ветки. К примеру, вы добавили репозиторий в дистрибутив Buster, а в репозитории нет поддержки этого дистрибутива. Предыдущие есть, а этого нет.

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

Зеркало официального репозитория yandex mirror

В рунете популярен репозиторий Яндекса под названием andex.Mirror — https://mirror.yandex.ru. Это зеркало популярных дистрибутивов Linux, Freebsd и других проектов, в том числе и Debian. Работает по протоколам HTTP, FTP и rsync.

deb http://mirror.yandex.ru/debian bullseye main
deb-src http://mirror.yandex.ru/debian bullseye main
deb http://mirror.yandex.ru/debian bullseye-updates main
deb-src http://mirror.yandex.ru/debian bullseye-updates main
deb https://mirror.yandex.ru/debian-security bullseye-security main
deb-src https://mirror.yandex.ru/debian-security bullseye-security main

Repository yandex mirror можно так же использовать для сетевой установки систем.

Обновление репозиториев с помощью yum

После добавления новых репозиториев в систему, никаких дополнительных действий производить не требуется, в отличие от debian based систем, где после добавления репозиториев, необходимо обновить кэш доступных пакетов с помощью команды apt-get update. Если выполнить команду yum update, то начнется сразу обновление пакетов. То есть смысл команды совсем другой. В CentOS кэш пакетов обновляется каждый раз, когда производится какое-то действие с помощью yum. Например, при выводе списка доступных репозиториев, обновляется список пакетов.

Показать список активных репозиториев в centos

# yum repolist

Архив репозиториев для старых версий

В официальном репозитории Debian располагаются пакеты для текущего релиза (stable), для прошлого релиза (oldstable) и для будущего релиза (testing). Для всех старых релизов репозитории отправляются в архив — http://archive.debian.org/debian/, который заморожен. Обновлений к релизам из архива больше нет. Но если вам по какой-то причине нужен репозиторий для старой версии Debian, вы можете им воспользоваться.

Ниже представляю готовые настройки репозиториев для прошлых версий.

Debian 9 stretch

Репозитории Debian 9 stretch пока еще находятся в основных репозиториях:

deb http://deb.debian.org/debian stretch main
deb-src http://deb.debian.org/debian stretch main
deb http://deb.debian.org/debian-security/ stretch/updates main
deb-src http://deb.debian.org/debian-security/ stretch/updates main
deb http://deb.debian.org/debian stretch/updates main
deb-src http://deb.debian.org/debian stretch/updates main

В скором времени они тоже переедут в архив. Случится это в июне 2022 года, когда кончится период длительной поддержки. Тогда их можно будет подключить по следующим адресам:

deb http://archive.debian.org/debian/ stretch main non-free contrib
deb-src http://archive.debian.org/debian/ stretch main non-free contrib
deb http://archive.debian.org/debian-security/ stretch/updates main contrib
deb-src http://archive.debian.org/debian-security/ stretch/updates main contrib

Debian 8 jessie

Репозитории Debian 8 jessie:

deb http://archive.debian.org/debian/ jessie main non-free contrib
deb-src http://archive.debian.org/debian/ jessie main non-free contrib
deb http://archive.debian.org/debian-security/ jessie/updates main contrib
deb-src http://archive.debian.org/debian-security/ jessie/updates main contrib

Debian 7 wheezy

Репозитории Debian 7 wheezy:

deb http://archive.debian.org/debian/ wheezy main non-free contrib
deb-src http://archive.debian.org/debian/ wheezy main non-free contrib
deb http://archive.debian.org/debian-security/ wheezy/updates main contrib
deb-src http://archive.debian.org/debian-security/ wheezy/updates main contrib

Debian 6 squeeze

Репозитории Debian 6 squeeze:

deb http://archive.debian.org/debian/ squeeze main non-free contrib
deb-src http://archive.debian.org/debian/ squeeze main non-free contrib
deb http://archive.debian.org/debian-security/ squeeze/updates main contrib
deb-src http://archive.debian.org/debian-security/ squeeze/updates main contrib

Получение информации о пакетах из репозиториев

Список пакетов в репозиториях

Чтобы получить список пакетов в репозиториях можно выполнить apt list. Так как это не административное действие, то можно не использовать sudo. Например:

$ apt list

Кстати, утилита apt-get это выполнить не может.

Поиск пакета по ключевому слову

Если мы примерно знаем название приложения, которое нам нужно, то можем попытаться найти пакет используя ключевое слово. При этом поиск идет не только по названию пакетов, но и по его содержимому. Такой поиск выполняется с помощью команд apt-cache search <ключевое слово> или apt search <ключевое слово>.

Пример (так как вывод может быть большим, то я использую less):

$ apt-cache search apache | less
$ apt search apache | less

Смотрим информацию о пакете

Зная имя пакета, можем посмотреть информацию о нём с помощью команд apt-cache show <имя пакета> или apt show <имя пакета>.

Пример (так как вывод может быть большим, то я использую less):

$ apt-cache show apache2 | less
$ apt show apache2 | less

Поиск зависимостей

Зависимости можно посмотреть в информации о пакете с помощью уже рассмотренных команд apt-cache show <имя пакета> или apt show <имя пакета>. Но для этого есть ещё одна команда: apt-cache depends <имя пакета> или apt depends <имя пакета>. Например:

$ apt-cache depends apache2
$ apt depends apache2

Типы официальных репозиториев в Debian

Как я уже показал выше, в sources.list используются псевдонимы, либо классы релиза, а так же разные ветки наборов пакетов. С псевдонимами релизов все понятно. Они названы в честь персонажей мультфильма История игрушек (Toy story) — Wheezy, Jessie, Stretch, Buster, Bullseye и т.д. А вот насчет классов релизов поговорим отдельно. Существуют следующие официальные классы релизов Debian.

Stable

Стабильная ветка официального текущего релиза Debian. То есть это самая свежая и актуальная версия, которую рекомендуется использовать. Официальный репозиторий стабильной ветки содержит проверенный набор программ, зачастую не очень свежих версий. Это плата за надежность. В production рекомендуется использовать пакеты именно из репозитория stable.

В этом репозитории регулярно публикуются все актуальные обновления текущего релиза. Он формируется из ветки Testing, которая в момент релиза новой версии превращается в Stable.

Oldstable

Oldstable — кодовое имя предыдущего stable repository. Для этого репозитория выпускаются обновления безопасности. Ветка Oldstable формируется из Stable предыдущего релиза на момент публикации нового.

Testing

Testing содержит в себе текущее состояние разработки нового стабильного релиза. После его выхода, testing становится stable. Пакеты в testing попадают из репы unstable. В общем случае использовать репозиторий testing следует только для тестовых целей, чтобы посмотреть на новый релиз.

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

Unstable (sid)

Sid это repository с самым свежим программных обеспечением. Проблема только в том, что оно еще не протестировано достаточным образом для использования. Если вы точно уверены, что вам нужен новый софт и он не сломает вам систему, можете поставить его из unstable репозитория. Но в общем случае, делать это не рекомендуется.

Даже если софт из unstable не повредит работе системы, он может нарушить зависимости пакетов, так что потом может быть затруднительно вернуться на stable repo.

Experimental

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

Backports

Backports repository выступает как некий компромисс между стабильностью основной ветки и свежим набором программ из ветки testing. Репозиторий backports содержит пакеты преимущественно из testing и немного из unstable (только для обновлений безопасности).

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

Если вам нужен софт из веток testing и unstable, лучше использовать backports. Репозиторий создан как раз для того, чтобы не прыгать между этими ветками.

Это все, что касается деления репозиториев по классам релизов. Есть еще небольшое разделение, которое явно нигде не описано и сразу не догадаешься, как оно работает и устроено.

Важное замечание. Я не рекомендую в качестве репозиториев указывать классы релизов — stable, oldstable и т.д. Всегда явно указывайте название релиза — bullseye, buster, stretch и т.д. Иначе в случае выхода нового релиза, вы при обычном обновлении получите обновление релиза, даже если не собирались его обновлять.

Security updates

Существует отдельный репозиторий только для security updates. Добавить его можно следующим образом:

deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free

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

Stable-updates

Еще один отдельный репозиторий для установки пакетов через механизм stable-updates. Добавить его можно следующим образом.

deb http://deb.debian.org/debian bullseye-updates main
deb-src http://deb.debian.org/debian bullseye-updates main

Через этот repository вы будете по мере выпуска получать обновления, которые готовятся к публикации в очередном обновлении релиза. Так называемые Point Releases — 10.1, 10.2 и т.д. Случаются они не часто, примерно раз в 2-3 месяца, но проверенные для них обновления можно получить ранее как раз с помощью stable-updates.

Конфиги со списком репозиториев

Пакетные менеджеры, которые умеют устанавливать пакеты из репозиториев, должны знать адреса репозиториев. И эти адреса записываются в конфиг – /etc/apt/sources.list. А также можно создавать дополнительные конфиги с расширением .list в каталоге /etc/apt/sources.list.d/. Всё это справедливо и для Debian и для Ubuntu.

Если помните, в процессе установки систем мы выбирали репозиторий:

• для Debian – deb.debian.org;
• для Ubuntu – ru.archive.ubuntu.com.

alex@ubu:~$ egrep -v '^#|^$' /etc/apt/sources.list | cat -n 1 deb http://ru.archive.ubuntu.com/ubuntu jammy main restricted 2 deb http://ru.archive.ubuntu.com/ubuntu jammy-updates main restricted 3 deb http://ru.archive.ubuntu.com/ubuntu jammy universe 4 deb http://ru.archive.ubuntu.com/ubuntu jammy-updates universe 5 deb http://ru.archive.ubuntu.com/ubuntu jammy multiverse 6 deb http://ru.archive.ubuntu.com/ubuntu jammy-updates multiverse 7 deb http://ru.archive.ubuntu.com/ubuntu jammy-backports main restricted universe multiverse 8 deb http://ru.archive.ubuntu.com/ubuntu jammy-security main restricted 9 deb http://ru.archive.ubuntu.com/ubuntu jammy-security universe 10 deb http://ru.archive.ubuntu.com/ubuntu jammy-security multiverse
alex@deb:~$ egrep -v '^#|^$' /etc/apt/sources.list | cat -n 1 deb http://deb.debian.org/debian/ bullseye main 2 deb-src http://deb.debian.org/debian/ bullseye main 3 deb http://security.debian.org/debian-security bullseye-security main 4 deb-src http://security.debian.org/debian-security bullseye-security main 5 deb http://deb.debian.org/debian/ bullseye-updates main 6 deb-src http://deb.debian.org/debian/ bullseye-updates main

Этот файл состоит из строк, а строки состоят из следующих столбцов:

Классы релизов в Debian

Рассматривая выше ветки репозиториев Debian мы увидели следующее:

• bullseye;
• bullseye-updates;
• bullseye-security.

Но, помимо кодовых имён версий системы, в названиях веток, можно использовать специальные классы релизов:

• stable – ссылается на текущей стабильный репозиторий Debian, сейчас это bullseye. Как только выйдет новая версия Debian, то stable будет ссылаться на более новую версию;
• oldstable – ссылается на предыдущий стабильный репозиторий;
• testing – ссылается на специальную ветку репозитория для разработки нового стабильного релиза;
• unstable – ссылается на самые свежие, но не протестированные пакеты;
• experimental – здесь хранятся пакеты, которые только начали разрабатывать;
• backports – ссылается на testing и unstable, но только для обновлений безопасности.

То есть вы можете изменить свои репозитории на testing, и быть на острие прогресса:

### Это только пример, существует большая вероятность что система очень скоро повредится из за непроверенных обновлений ###
deb http://deb.debian.org/debian/ testing main
deb-src http://deb.debian.org/debian/ testing main
deb http://security.debian.org/debian-security testing-security main
deb-src http://security.debian.org/debian-security testing-security main
deb http://deb.debian.org/debian/ testing-updates main
deb-src http://deb.debian.org/debian/ testing-updates main

Исправление проблем с пакетами

Исправление ошибок с зависимостями

Если в процессе установки некоторого пакета или при обновлении всей системы вы столкнётесь с проблемой с зависимостями. То можете воспользоваться командами apt-get -f install или apt -f install. Эти команды пытаются решить проблемы с зависимостями путём удаления или установки новых пакетов.

$ sudo apt-get -f install
$ sudo apt -f install

Только внимательно смотрите на список удаляемых пакетов!

Добавить новый repository в debian

Теперь от теории перейдем к практике. Давайте вручную добавим новый репозиторий в Debian. К примеру, нам нужно установить на сервер стабильную версию MariaDB. Для этого добавим ее репозиторий. Это можно сделать либо в файле sources.list, но лучше создать отдельный в sources.list.d. Назовем его MariaDB.list.

deb [arch=amd64,arm64,ppc64el] http://mirror.mephi.ru/mariadb/repo/10.6/debian bullseye main
deb-src http://mirror.mephi.ru/mariadb/repo/10.6/debian bullseye main

После подключения репозитория, надо добавить его gpg ключ.

# curl -LsSO https://mariadb.org/mariadb_release_signing_key.asc
# chmod -c 644 mariadb_release_signing_key.asc
# mv -vi mariadb_release_signing_key.asc /etc/apt/trusted.gpg.d/

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

# apt update

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

# apt search mariadb-server

Как я уже говорил, для настройки нового репозитория, вы могли просто добавить эти же 2 строки с параметрами в sources.list напрямую. Разницы никакой нет.

Файл Release

Он содержит информацию о данной ветке репозитория, например для Ubuntu Jammy файл содержит следующее:

Origin: Ubuntu
Label: Ubuntu
Suite: jammy
Version: 22.04
Codename: jammy
Date: Thu, 21 Apr 2022 17:16:08 UTC
Architectures: amd64 arm64 armhf i386 ppc64el riscv64 s390x
Components: main restricted universe multiverse
Description: Ubuntu Jammy 22.04
MD5Sum: *** а здесь контрольные суммы для каждого пакета из репозитория ***

Файл Release – один из самых важных файлов для работы репозитория. Когда пакетный менеджер обновляет список пакетов, то он открывает адрес репозитория и читает этот файл. Если этого файла нет, то репозиторий будет помечен как неисправный и не будет использоваться.

Добавление сторонних репозиториев

Добавлять репозитории можно в основной конфиг: /etc/apt/sources.list или создавать отдельные конфиги в каталоге /etc/apt/sources.list.d/. Сам я считаю что правильнее для каждого стороннего репозитория создавать отдельные конфиги.

Например, чтобы подключить репозиторий nginx создайте следующий конфиг. Для Debian:

alex@deb:~$ sudo nano /etc/apt/sources.list.d/nginx.list
deb http://nginx.org/packages/debian bullseye nginx 

Или для Ubutnu:

alex@ubu:~$ sudo nano /etc/apt/sources.list.d/nginx.list
deb http://nginx.org/packages/ubuntu jammy nginx

Допустим, мы прописали дополнительный репозиторий для nginx, но как системе понять из какого репозитория брать пакет для установки? Ведь пакеты для nginx есть и в системном репозитории и в репозитории от самого nginx. Чтобы ответить на этот вопрос придумали приоритеты репозиториев.

Чтобы задать приоритет репозитория нужно создать файл /etc/apt/preferences.d/XX<имя_репозитория>, где XX это номер файла, чем он выше, тем обработается позднее, то есть будет иметь приоритет над другими настройками.

По нашему примеру для nginx нужно создать следующий файл:

$ sudo nano /etc/apt/preferences.d/99nginx
Package: *
Pin: origin nginx.org
Pin: release o=nginx
Pin-Priority: 900

• Package: имя пакета. Можно поставить знак * чтобы применить приоритет для всех пакетов из этого репозитория. Также можно указать несколько имён через пробел;
• Pin: опции прикрепления. Существует много опций, я разберу лишь некоторые:
  • origin “имя автора или поставщика”;
  • release o=nginx – означает что в файле Release репозитория есть поставщик (Origin = o) с именем nginx;
  • release l=Debian – означает что в файле Release репозитория есть Label (l) с именем Debian;
• Pin-Priority: приоритет.

То-есть Package и Pin это условия для назначения приоритета, а Pin-Priority это действие (назначение приоритета). В нашем примере получается следующее: если имя пакета любое, но владелец репозитория nginx.org и в файле Release прописано “Origin: nginx“, то для таких пакетов ставим приоритет 900.

Приоритет может быть в следующих диапазонах:

• P >= 1000 – пакет будет установлен из этого репозитория, даже если это приведет к понижению версии уже установленного пакета;
• 990 <= P < 1000 – пакет будет установлен из этого репозитория, если не установлена более новая версия;
• 500 <= P < 990 – пакет будет установлен, если нет пакета принадлежащего к целевому выпуску или не установлена более новая версия;
• 100 <= P < 500 – пакет будет установлен, если нет кандидатов из других репозиториев или установленного пакета более новой версии;
• 0 < P < 100 – пакет будет установлен, только если он ещё не установлен (любой версии) и если нет кандидатов из других репозиториев;
• P < 0 – пакет не будет установлен ни при каких условиях;
• P = 0 – не используется.

Приоритеты с 500 по 990 и с 990 по 1000 очень похожи. Чтобы их отличить нужно понять что такое целевой выпуск. Для Ubuntu или Debian это название версии дистрибутива. Например для Ubuntu – jammy, а для Debian – bullseye. Но это имя ещё нужно задать таким способом:

alex@deb:~$ sudo nano /etc/apt/apt.conf.d/default
APT::Default-Release "bullseye";
alex@ubu:~$ sudo nano /etc/apt/apt.conf.d/default
APT::Default-Release "jammy";

Открытый ключ репозитория

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

alex@deb:~$ sudo apt update
Пол:1 http://nginx.org/packages/debian bullseye InRelease [2 860 B]
Ошб:1 http://nginx.org/packages/debian bullseye InRelease Следующие подписи не могут быть проверены, так как недоступен открытый ключ: NO_PUBKEY ABF5BD827BD9BF62
Пол:2 http://security.debian.org/debian-security bullseye-security InRelease [44,1 kB]
Сущ:3 http://deb.debian.org/debian bullseye InRelease
Пол:4 http://deb.debian.org/debian bullseye-updates InRelease [39,4 kB]
Чтение списков пакетов… Готово
W: Ошибка GPG: http://nginx.org/packages/debian bullseye InRelease: Следующие подписи не могут быть проверены, так как недоступен открытый ключ: NO_PUBKEY ABF5BD827BD9BF62
E: Репозиторий «http://nginx.org/packages/debian bullseye InRelease» не подписан.
N: Обновление из этого репозитория нельзя выполнить безопасным способом, поэтому по умолчанию он отключён.
N: Информацию о создании репозитория и настройках пользователя смотрите в справочной странице apt-secure(8).

И тут мы видим ошибку, что нам не хватает открытого ключа. Я привёл пример для Debian, но в Ubuntu будет подобная ситуация. Дело в том что современные репозитории шифруются с помощью закрытого ключа и чтобы его использовать, нам нужно установить в систему открытый ключ.

Чтобы это сделать, вначале установим необходимые инструменты:

### Для Debian ###
alex@deb:~$ sudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring
### Для Ubuntu ###
alex@ubu:~$ sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring

Внимание! Утилита gnupg2 для Ubuntu доступна только в репозитории universe, если вы закомментировали эти источники, то разкомментируете их. Это строчки:
deb http://ru.archive.ubuntu.com/ubuntu jammy universe
deb http://ru.archive.ubuntu.com/ubuntu jammy-updates universe
И не забудьте применить изменения, выполнив:
$ sudo apt update

А дальше скачаем открытый ключ (с помощью wget):

$ wget https://nginx.org/keys/nginx_signing.key

Дальше выполняется конвейер команд, это когда вывод одной команды идет на вход другой команде. Такие конвейеры мы будем проходить позже. Но всё равно постараюсь объяснить следующую команду. С помощью cat мы читаем файл ключа, и прочитанное передаём утилите gpg. Утилита gpg переводит прочитанное в необходимый формат и передаёт вывод уже следующей команде tee. Утилита tee (под sudo) сохраняет полученный текст в файл. В конце добавляем >/dev/null, чтобы не было никакого вывода на терминал. Вот сама команда:

$ cat nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

### Пример для wget ###
$ wget -O- https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
### Пример для curl ###
$ curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

alex@deb:~$ sudo nano /etc/apt/sources.list.d/nginx.list
deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/debian bullseye nginx

И пробуем ещё раз применить изменения:

alex@deb:~$ sudo apt update
Сущ:1 http://security.debian.org/debian-security bullseye-security InRelease
Сущ:2 http://deb.debian.org/debian bullseye InRelease
Сущ:3 http://deb.debian.org/debian bullseye-updates InRelease
Пол:4 http://nginx.org/packages/debian bullseye InRelease [2 860 B]
Пол:5 http://nginx.org/packages/debian bullseye/nginx amd64 Packages [7 633 B]
Получено 7 633 B за 1с (9 420 B/s)
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово
Все пакеты имеют последние версии.

На этот раз всё прошло успешно.

Кстати, если вы хотите в источнике пакетов прописать архитектуру и открытый ключ, то это делается через пробел:

### Пример ###
deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/debian bullseye nginx

Проверка добавленного репозитория

Ну и чтобы понять из какого репозитория будет установлен пакет, выполните команду:

alex@deb:~$ apt-cache policy nginx
nginx: Установлен: (отсутствует) Кандидат: 1.20.2-1~bullseye Таблица версий: 1.20.2-1~bullseye 990 990 http://nginx.org/packages/debian bullseye/nginx amd64 Packages 1.20.1-1~bullseye 990 990 http://nginx.org/packages/debian bullseye/nginx amd64 Packages 1.18.0-6.1 990 990 http://deb.debian.org/debian bullseye/main amd64 Packages

Из вывода становится ясно что пакет nginx ещё не установлен в систему, а кандидатом на установку является пакет с версией 1.20.2 из репозитория http://nginx.org/packages/debian. Приоритет у всех пакетов, кстати стал равным = 990. Это произошло после того, как мы установили целевой выпуск = bullseye. Так как все репозитории относятся к этому выпуску, то на назначенный мною приоритет система перестала смотреть, а назначила репозиториям для bullseye такой приоритет.

Подключение rpmforge repo в CentOS

Полное название rpmforge репозитория — RepoForge. По информации с сайта wiki.centos.org этот архив больше не поддерживается и не рекомендуется к установке. Но лично я нигде больше не нашел об этом информацию, в том числе и на официальном сайте repoforge.org. Данный репозиторий содержит следующие наборы совместимых RHEL пакетов:

• Servers (eg. monitoring, troubleshooting, management)
• Desktops (eg. office, leisure, multi-media)
• Development (eg. perl, python, ruby libraries)

Установка rpmforge на centos:

1. Устанавливаем GPG ключ:

   # rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

2. Идем на страницу загрузки и копируем ссылку rpm пакета под нужную нам архитектуру.
3. Устанавливаем скопированный rpm пакет:

   # yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

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

# yum -y install http://repository.it4i.cz/mirrors/repoforge/redhat/el7/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

Проверяем директорию /etc/yum.repos.d:

# ls -l | grep rpmforge
-rw-r--r--. 1 root root 739 Jun 12 2014 mirrors-rpmforge
-rw-r--r--. 1 root root 717 Jun 12 2014 mirrors-rpmforge-extras
-rw-r--r--. 1 root root 728 Jun 12 2014 mirrors-rpmforge-testing
-rw-r--r--. 1 root root 1128 Jun 12 2014 rpmforge.repo

Все в порядке rpmforge репозиторий установлен.

Список репозиториев в sources. list

Изначально, содержимое sources.list будет зависеть от того, какой источник для пакетов вы выбрали во время установки debian. К примеру, в моем случае для системы Debian 10 он выглядит следующим образом.

deb http://mirror.corbina.net/debian/ buster main
deb-src http://mirror.corbina.net/debian/ buster main
deb http://security.debian.org/debian-security buster/updates main
deb-src http://security.debian.org/debian-security buster/updates main
# buster-updates, previously known as 'volatile'
deb http://mirror.corbina.net/debian/ buster-updates main
deb-src http://mirror.corbina.net/debian/ buster-updates main

Для Debian 11 bullseye немного изменился формат записи для репозитория security. Теперь он выглядит так:

deb http://security.debian.org/ bullseye-security main

В общем случае файл sources.list имеет следующую структуру:

deb http://site.example.com/debian distribution component1 component2 component3
deb-src http://site.example.com/debian distribution component1 component2 component3

Про псевдонимы релизов и наборы пакетов мы поговорим ниже более подробно в соответствующем разделе.

Помимо основного файла sources.list, репозитории могут располагаться в отдельных файлах в директории /etc/apt/sources.list.d. Формат файлов такой же, как и у основного. Обычно туда добавляют отдельно в каждый файл набор источников для какой-то определенной программы. Например, proxmox размещает в отдельном файле свой платный репозиторий.

# cat /etc/apt/sources.list.d/pve-enterprise.list
deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise

Заключение

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

Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Итог

Мы узнали что такое репозитории. Узнали что есть официальные репозитории для системы и они прописываются в конфиг /etc/apt/sources.list. А также есть сторонние репозитории и для них лучше создавать свои конфиги в каталоге /etc/apt/sources.list.d/.

Научились добавлять сторонний репозиторий на примере nginx. Узнали про приоритеты репозиториев и открытые ключи. А также узнали что такое целевой выпуск.

Из этой статьи вы узнаете что такое репозитории в Linux. Мы научимся их настраивать на примере Debian 11 и Ubuntu 22.04

Итог

Мы узнали множество команд с помощью которых можем устанавливать и удалять пакеты в систему, а также обновлять её. И проделывать другие вещи.

А также мы узнали что перед установкой deb пакеты скачиваются в каталог /var/cache/apt/archives/. И у пакетов есть зависимости, которые apt или apt-get определяет и автоматически устанавливает.

Пакетные менеджеры apt и apt-get

На этом уроке рассмотрим пакетные менеджеры apt и apt-get. Которые используются для работы с пакетами приложений в Linux