How to add repository from shell in Debian?

sudo add-apt-repository ppa:yannubuntu/boot-repair

As Ubuntu is based on Debian code base, I was expecting that the same would work in Debian too, but it doesn’t.

• What is the reason for this?
• Is there some other shell command I can use to achieve the same?

Note: I know I can edit /etc/apt/sources.list, but I want to achieve this from the shell. I also want to know why the same command won’t work when the code base is the same.

53 gold badges1024 silver badges1125 bronze badges

asked Aug 20, 2012 at 9:34

Kshitiz Sharma

21 gold badges55 silver badges74 bronze badges

Debian Jessie and later (2014-)

sudo apt-get install software-properties-common

Debian Wheezy and earlier

The program add-apt-repository is available in Debian. It’s in the python-software-properties package:

sudo apt-get install python-software-properties

It was added to that package in version 0.75. The current version in Debian Stable (‘squeeze») is 0.60, so it doesn’t have it. The version currently in Debian Testing («wheezy») is 0.82.7.1debian1, so it’s available there.

answered Aug 20, 2012 at 15:13

Assuming you’re running a non-ancient version of Debian (Etch or later), you can just drop a file in /etc/apt/sources.list.d/ The file name must end with .list; Debian Stretch (not yet released) will likely add .sources with a different format.

The format is the same as the main sources.list file.

The advantage is, especially if this is for some software you’re distributing, you don’t have to worry merging your changes into a possibly-edited /etc/apt/sources.list file (especially hard to deal with if your program is uninstalled). You can use dpkg conffile support to put the file in /etc/apt/sources.list.d/.

answered Aug 20, 2012 at 19:47

20 gold badges231 silver badges277 bronze badges

add-apt-repository can now be found in the software-properties-common package.

answered May 15, 2014 at 21:00

Ubuntu is based on Debian but includes things Debian doesn’t (and in turn are often incorporated into Debian later). The add-apt-repository command is an example which was included in Ubuntu first.

The add-apt-repository actually just executes a couple of commands to add the repository:

• append the repository to /etc/apt/sources.list
• add the repository key to the machine.

A script that sort of does the same that can be found here is quoted below

#!/bin/bash
if [ $# -eq 1 ]
NM=$(uname -a && date)
NAME=$(echo $NM | md5sum | cut -f1 -d" ")
then
    ppa_name=$(echo "$1" | cut -d":" -f2 -s)
    if [ -z "$ppa_name" ]
    then
        echo "PPA name not found"
        echo "Utility to add PPA repositories in your debian machine"
        echo "$0 ppa:user/ppa-name"
    else
        echo "$ppa_name"
        echo "deb http://ppa.launchpad.net/$ppa_name/ubuntu lucid main" >> /etc/apt/sources.list
        apt-get update >> /dev/null 2> /tmp/${NAME}_apt_add_key.txt
        key=$(cat /tmp/${NAME}_apt_add_key.txt | cut -d":" -f6 | cut -d" " -f3)
        apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $key
        rm -rf /tmp/${NAME}_apt_add_key.txt
    fi
else
    echo "Utility to add PPA repositories in your debian machine"
    echo "$0 ppa:user/ppa-name"
fi

18 gold badges83 silver badges151 bronze badges

answered Aug 20, 2012 at 10:13

1 gold badge10 silver badges6 bronze badges

You can do this by adding the entries for the Ubuntu repository to a file in /etc/apt/sources.list.d. But you should not do this, in the same sense that while crossing a busy 6-lane motorway on foot is physically possible, it is generally not recommended.

Mixing repositories from different releases of distributions, even if these distributions use the same package manager, tends not to work well because the different releases have different sets of library versions. While Debian and derivatives (like most distributions) arrange to allow multiple versions of libraries to be installed at the same time, that doesn’t always extend to other packages that sometimes depend on specific versions of the libraries. It might work for a while if you don’t install development packages (development packages tend to have precise library requirements), but sooner or later you’re practically sure to run into conflicts.

Library incompatibilities are why PPA have separate sources of binary packages for each Ubuntu release. Mixing a Debian release and an Ubuntu release is similar to mixing different Ubuntu releases.

If you want Ubuntu’s drivers, the simplest solutions install Ubuntu. Low-level software (kernel, core system utilities, X server and libraries) tends to need to form a coherent whole. It’s usually safe to install a more recent kernel, but you’ll also need to install corresponding X video drivers, at least if you use proprietary drivers, and you need to have the configuration and sometimes patches that the distribution expects (and Debian and Ubuntu don’t configure their kernel in exactly the same way).

If you absolutely want to have some packages from Ubuntu and some packages from Debian — or if you want to have packages from different releases of Debian/Ubuntu (that’s especially useful for developers who want to test their builds on different generation of software), it’s fairly painless to install additional Debian/Ubuntu releases in a chroot, so you run one release for your system but can run applications from another release.

При установке пакетов в линукс на основе дистрибутива Debian (Ubuntu, Linux Mint и др.) пакеты загружаются из одного или нескольких репозиториев программного обеспечения apt. Репозиторий – это сетевой сервер или локальный каталог, содержащий пакеты deb и файлы метаданных.

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

В этой заметке мы покажем Вам два способа добавления репозитория apt в системах на основе дистрибутива Debian. Первый способ заключается в использовании команды add-apt-repository, а второй – в ручном добавлении репозитория с помощью текстового редактора.

В Ubuntu (и всех других дистрибутивах Debian) репозитории программного обеспечения определены в файле /etc/apt/sources.list или в отдельных файлах в директории /etc/apt /sources.list.d/

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

Общий синтаксис принимает следующий вид:

deb http://repo.tld/ubuntu distro component

Первая запись в строке определяет тип архива. Тип архива может быть либо deb, либо deb-src. Deb подразумевает, что репозиторий содержит deb-пакеты, в то время как deb-src подразумевает исходные пакеты.
Вторая запись – это URL репозитория.
Третья запись указывает кодовое имя дистрибутива, например beaver, xenial и так далее.
Последние записи – это компоненты или категории репозитория. Репозитории Ubuntu по-умолчанию разделены на четыре компонента – main, restricted, universe и multiverse. Как правило, сторонние репозитории имеют только одну категорию.

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

Добавление через add-apt-repository

Сначала необходимо убедиться, что у Вас есть команда add-apt-repository. Если при ее выполнении видите: add-apt-repository command not found, значит ее нет, необходимо установить пакет software-properties-common.

$ sudo apt update && sudo apt install software-properties-common

Синтаксис добавления репозитория через add-apt-repository таков:

Где repository – это репозиторий, который необходимо добавить в sources.list (например deb http://repo.tld/ubuntu distro component или PPA репозиторий в формате ppa:/).

Чтобы увидеть все возможности команды add-apt-repository выполните man add-apt-repository в терминале.

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

Допустим, мы хотим установить MongoDB из оффициального репозитория.

Первое, что необходимо сделать – установить public key (публичный ключ):

$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4

Добавим теперь репозиторий MongoDB:

А сейчас уже можно установить MongoDB:

$ sudo apt update && sudo apt install mongodb-org

Чтобы удалить репозиторий, используйте опцию –remove:

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

Personal Package Archives (PPA) это сервис, который позволяет пользователям загружать исходные пакеты Ubuntu, построенные и опубликованные с помощью Launchpad в качестве репозитория apt.

Когда Вы добавляете новый PPA репозиторий, команда add-apt-repository создает новый файл в директории /etc/apt/sources.list.d/

Для примера установим FFmpeg версии 4.x

$ sudo add-apt-repository ppa:jonathonf/ffmpeg-4

Нажмем Enter когда нас попросят об этом.

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

$ sudo apt update && sudo apt install ffmpeg

Ручное добавление репозитория

Если Вы хотите, то можете добавить необходимый репозиторий в файл /etc/apt/sources.list вручную.

Для примера включим репозиторий CouchDB и установим из него пакеты. CouchDB – это бесплатное, отказоустойчивое NoSQL решение с открытым исходным кодом, поддерживаемое Apache Software Foundation.

Откройте файл sources.list любимым редактором:

sudo vim /etc/apt/sources.list

И добавьте в конце файла новой строкой запись:

deb https://apache.bintray.com/couchdb-deb bionic main

Вместо редактирования файла, можно выполнить лишь одну такую команду:

$(lsb_release -cs) выведет кодовое имя Ubuntu. Например, если у Вас Ubuntu 18.04, тогда кодовое имя – bionic.

Более правильным, конечно, будет не добавление строки в файл sources.list, а вынесение репозитория в отдельный файл, который помещается в каталог /etc/apt/sources.list.d/ (как это описывали выше).

Далее нам необходимо загрузить публичный ключ. Это можно сделать командами wget или curl:

Вывод должен быть просто OK, что значит GPG ключ успешно импортирован.

Перед установкой нового пакета, обновим список доступных репозиториев:

$ sudo apt update

А теперь установим:

$ sudo apt install couchdb

Заключение

Мы показали Вам, как добавить репозитории в Linux на базе Debian. Эти же инструкции применимы к любому дистрибутивам Ubuntu, Kubuntu, Linux Mint, Kali Linux, Elementary OS и др.

PPA repositories are one of the things that Ubuntu likes the most. It is a personal repository that allows independent developers a platform to distribute their packages for Ubuntu. However, many of these packages are compatible with Debian and so it is necessary to know how to add them to Debian. This is exactly what you will learn in this post, how to add and remove PPA repositories in Debian.

First of all, it is necessary to know what is a repository in Linux.

In Linux, packages and applications are usually hosted in a repository. These repositories may be official, that is, included with the distribution, or they may be unofficial or unrelated to the distribution.

Читайте также:  Разрушение Telegram Drop: что нужно понимать

In short, a repository is a store or space where packages are hosted. These repositories have specific characteristics that make them compatible with the Linux distribution.

The truth is that it is not so easy that you can include it in an official repository, so the best option is to have one of your own or package it and distribute it through a website or other tool.

PPAs are mainly used in Ubuntu, but it is also possible to add them in Debian.

How to add/remove PPA repositories in Debian

Debian is a quite popular but somewhat closed operating system in package management. While it is true that there are many packages included in Debian, it is also true that many popular applications are not in its repositories.

So, there are times when it is necessary to add a PPA.

For this, we can do it via the terminal, which is a very fast method.

First, install the necessary package to add PPAs in Debian:

apt install software-properties-common

add-apt-repository ppa:ppa_name

add-apt-repository ppa:jonathonf/nimlang

After that, you can refresh APT.

apt update

And finally install any package from this repository:

apt install [package]

And it’s that simple.

Removing a PPA repository on Debian

To remove a repository, we can use the same command but add the -remove

add-apt-repository -remove ppa:ppa_name

Or in this case:

add-apt-repository ppa:jonathonf/nimlang

And with this, the PPA is eliminated.

Method 2: Remove the PPA manually

Another way to remove a PPA is to do it manually by removing its entry in the folder that APT dedicates to software sources.

First, show all the repository files that are in Debian

ls /etc/apt/sources.list.d/

And then, just delete it with the rm command

rm /etc/apt/sources.list.d/[ppa-name]

sudo rm /etc/apt/sources.list.d/jonathonf-ubuntu-nimlang.list

And that’s how simple it is to remove a PPA in Debian.

Adding/Removing PPA on Debian using the GUI

Debian is used both on servers and on the desktop. That’s why you may prefer to use the graphical interface.

From the main menu open the program called Software and Updates and go to the tab Other Software

From this interface, you only have to press one of the buttons according to the operation you need. To add a PPA just click on Add and to remove a PPA just select one and click on Remove.

Conclusion

Adding PPA in Debian is a simple task but it is convenient to know that we add PPA to avoid instabilities. Now that you know you can add some.

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

Что такое репозиторий

Репозиторий – это своеобразное хранилище приложений. У многих GNU/Linux дистрибутивов есть свои репозитории. А также разработчики какого-нибудь отдельного программного обеспечения могут создать свой репозиторий. Но в этом случае такой репозиторий нужно разделить на ветки, одна ветка будет подходить для одной Linux системы, а другая для другой.

В репозиториях, которые подходят для Debian и Ubuntu приложения хранятся в виде архивов. Такие архивы называются пакетами. Эти пакеты имеют особый формат – deb. Есть ещё другой, популярный, формат пакетов – rpm, но системы полагающиеся на такие пакеты я не рассматриваю.

На этом уроке мы познакомимся с подключением системных и сторонних репозиториев. А пакетные менеджеры рассмотрим позже.

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

Пакетные менеджеры, которые умеют устанавливать пакеты из репозиториев, должны знать адреса репозиториев. И эти адреса записываются в конфиг – /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

Файл 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 – один из самых важных файлов для работы репозитория. Когда пакетный менеджер обновляет список пакетов, то он открывает адрес репозитория и читает этот файл. Если этого файла нет, то репозиторий будет помечен как неисправный и не будет использоваться.

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

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

Architectures: amd64 arm64 armhf i386 ppc64el riscv64 s390x

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

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

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

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

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

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

Добавлять репозитории можно в основной конфиг: /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 такой приоритет.

Итог

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

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

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

В этой статье я расскажу как создать своё локальное зеркало репозиториев для Linux, с использованием инструмента – apt-mirror.

Введение

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

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

Создание зеркала репозиториев

Устанавливаем пакет apt-mirror:

# apt install apt-mirror

Apt-mirror написан на языке программирования perl. Посмотреть расположение самого скрипта можно с помощью следующей команды:

# which apt-mirror
/bin/apt-mirror

Так как проект давно заброшен, то в скрипте есть недоработки, например Файлы переводов (i18n/Translation) раньше в репозиториях хранились в виде архива bz2, а сейчас хранятся в виде архива xz. Ещё одна проблема в том, что начиная с Ubuntu Focal (20.04), клиент APT ожидает, что репозиторий предоставят файлы метаданных (command-not-found – cnf). Про эти файлы apt-mirror тоже ничего не знает. Но есть один разработчик, который поддерживает проект apt-mirror, и вы можете использовать его версию скрипта. Найти его скрипт можно здесь. Просто сделайте резервную копию файла /bin/apt-mirror и в оригинал поместите версию скрипта от Stifler6996.

После исправления скрипта нужно произвести настройки apt-mirror. Для этого используется конфиг /etc/apt/mirror.list. В конфиг нужно добавить те репозитории, для которым мы делаем зеркало. Вы также можете изменить пути сохранения файлов, но я оставляю их по умолчанию (/var/spool/apt-mirror):

# nano /etc/apt/mirror.list
############# config ##################
### тут ничего не правлю
############# end config ##############

# Репозитории для ProxMox 6 (на 7 я ещё не перешёл)
deb [arch=amd64] http://download.proxmox.com/debian/pve buster pve-no-subscription
deb http://download.proxmox.com/debian/pbs buster pbs-no-subscription

# Репозитории для Debian 11 (указываю архитектуру, чтобы хоть как-то уменьшить количество скачиваемых пакетов)
deb [arch=amd64] http://deb.debian.org/debian/ bullseye main
deb [arch=amd64] http://security.debian.org/debian-security bullseye-security main
deb [arch=amd64] http://deb.debian.org/debian/ bullseye-updates main

# Репозитории для Ubuntu 22.04
deb [arch=amd64] http://ru.archive.ubuntu.com/ubuntu jammy main restricted
deb [arch=amd64] http://ru.archive.ubuntu.com/ubuntu jammy-updates main restricted
deb [arch=amd64] http://ru.archive.ubuntu.com/ubuntu jammy-security main restricted

clean http://ftp.us.debian.org/debian

И запускаем синхронизацию:

#  apt-mirror

С моими настройками будет скачано 128 GB. Так что убедитесь что у вас хватает мета на жестком диске.

Возможно у вас за 1 раз всё не скачается, процесс может упасть и придется снова выполнить команду apt-mirror. Не волнуйтесь, процесс начнется не с начала, а продолжит скачивать то что ещё не скачалось.

Файлы загружаются в каталог /var/spool/apt-mirror/, можем посмотреть структуру каталогов с помощью утилиты tree (возможно её нужно будет установить):

# tree -d -L 4 /var/spool/apt-mirror/
/var/spool/apt-mirror/
├── mirror
│   ├── deb.debian.org
│   │   └── debian
│   │       ├── dists
│   │       └── pool
│   ├── download.proxmox.com
│   │   └── debian
│   │       ├── pbs
│   │       └── pve
│   ├── ru.archive.ubuntu.com
│   │   └── ubuntu
│   │       ├── dists
│   │       └── pool
│   └── security.debian.org
│       └── debian-security
│           ├── dists
│           └── pool
├── skel
│   ├── deb.debian.org
│   │   └── debian
│   │       └── dists
│   ├── download.proxmox.com
│   │   └── debian
│   │       ├── pbs
│   │       └── pve
│   ├── ru.archive.ubuntu.com
│   │   └── ubuntu
│   │       └── dists
│   └── security.debian.org
│       └── debian-security
│           └── dists
└── var

32 directories

В каталоге mirror находятся сами пакеты. А в каталоге skel – содержится служебная информация. Например, список пакетов можете посмотреть для разных веток в файле Packages:

# less /var/spool/apt-mirror/skel/download.proxmox.com/debian/pve/dists/buster/pve-no-subscription/binary-amd64/Packages
# less /var/spool/apt-mirror/skel/deb.debian.org/debian/dists/bullseye/main/binary-amd64/Packages

Проверить, есть ли у вас битые пакеты можно так:

# cd /var/spool/apt-mirror/mirror/
# md5sum -c /var/spool/apt-mirror/var/MD5 > mirror.log
# grep -v 'OK' mirror.log

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

Публикация своего репозитория

Чтобы использовать этот репозиторий, нужно опубликовать его с помощью веб сервера. Я для этого использую nginx. Устанавливаем веб сервер:

# apt install nginx

Правим основной конфиг nginx. Вам нужно изменить корневой путь и включить autoindex:

# nano /etc/nginx/sites-enabled/default
root /var/spool/apt-mirror/mirror/;
location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
                autoindex on;

# systemctl restart nginx.service

Если в браузере введёте адрес вашего сервера, то увидите следующее:

Прописываем репозиторий на наши сервера

Осталось добавить наш репозиторий на остальные наши сервера. Для этого нужно поправить конфиг /etc/apt/sources.list или создать отдельные конфиги в файле /etc/apt/sources.list.d. Кстати, про Linux репозитории я уже писал в этой статье.

Вот примеры того, как прописывается наш локальный репозиторий:

# так прописываем репозитории для PVE
deb [arch=amd64] http://172.28.90.45/download.proxmox.com/debian/pve/ buster pve-no-subscription
deb [arch=amd64] http://172.28.90.45/download.proxmox.com/debian/pbs/ buster pbs-no-subscription

# так для debian 11
deb [arch=amd64] http://172.28.90.45/deb.debian.org/debian/ bullseye main 
deb [arch=amd64] http://172.28.90.45/deb.debian.org/debian/ bullseye-updates main
deb [arch=amd64] http://172.28.90.45/security.debian.org/debian-security/ bullseye-security main

# так для Ubuntu 22.04
deb [arch=amd64] http://172.28.90.45/ru.archive.ubuntu.com/ubuntu/ jammy main restricted
deb [arch=amd64] http://172.28.90.45/ru.archive.ubuntu.com/ubuntu/ jammy-updates main restricted
deb [arch=amd64] http://172.28.90.45/ru.archive.ubuntu.com/ubuntu/ jammy-security main restricted

Локальное зеркало Linux репозитория (apt-mirror)

В этой статье я расскажу как создать своё локальное зеркало репозиториев для Linux, с использованием инструмента — apt-mirror

Несмотря на то, что в официальных репозиториях Debian можно найти почти всё, что может понадобиться, иногда всё-таки приходится самостоятельно собирать пакеты. Я стараюсь не замусоривать систему программами, установленными из исходных текстов и модулями различных языков программирования, установленными через их стандартные инструменты, вроде cpan, pip или gem.

Собирать пакеты приходится по нескольким причинам:

• В репозитории нет нужного пакета. Иногда бывает можно найти неофициальные репозитории для нужного релиза операционной системы.
• Через репозитории дистрибутива доступна только старая версия пакета, в которой не хватает нужных функций. В этом случае иногда помогают официальные репозитории backport с более свежими версиями пакетов, собранными для предыдущих релизов операционной системы.
• В пакете из репозитория есть ошибка. Даже в стабильном дистрибутиве встречаются ошибки, которые не исправляются ментейнерами. Тут придётся либо обновлять пакет, либо исправлять в нём ошибку.
• В репозитории есть нужная версия пакета, но собранная без поддержки определённой функции. Тут без вариантов — нужно дорабатывать и пересобирать пакет.

Например, в 2013 году я начал настраивать на работе серверы под Debian Wheezy. С тех пор у меня накопилось некоторое количество самосборных пакетов:

• python-grab — не было в репозитории
• python-flask-httpauth — не было в репозитории
• python-pycurl — не было в репозитории
• libdancer-plugin-database-core-perl — не было в репозитории
• libnet-ssh-expect-perl — не было в репозитории
• wordpress-plugin-simple-ldap-login — не было в репозитории
• python-mysqldb — модуль версии 1.2.3 заменён на более свежую версию 1.2.5 из-за некорректной работы с collation utf8_bin: python-mysqldb: utf8_bin collation will not convert to Unicode strings
• libsnmp и компания — пакеты были пересобраны из-за того, что не все производители оборудования с поддержкой SNMPv3 обеспечивают монотонный рост счётчика количества перезагрузок и времени с момента перезагрузки: Стандарт SNMPv3 и суровая действительность USM_TIME_WINDOW
• python-netsnmp — модуль пересобран из-за ошибки в формировании SET-запросов со значениями типа IPv4: Исправление Python-прослойки библиотеки Net-SNMP
• php5 и компания — среди этих пакетов был пакет php5-snmp, зависящий от пакета libsnmp
• openntpd — в пакете была иcправлена ошибка в обработке таймаута ответов от серверов DNS: Таймаут DNS в OpenNTPd
• uwsgi — включена поддержка Linux capabilities: Пересборка uwsgi с поддержкой Linux Capabilities
• zabbix — собрана более свежая версия пакета, наложена серия нестандартных патчей. Например, добавлены отдельные настройки таймаута и количества повторов для опроса по протоколу SNMP: Установка и настройка Zabbix 2.2.0 в Debian Wheezy
• python-paramiko и python-ecdsa — модуль paramiko 1.7.7.1-3.1 обновлён до версии 1.16.0-1, т.к. версия paramiko из репозитория имела ошибки в поддержке протокола SFTP: python-paramiko: sftp connections hangs. Модуль python-ecdsa был тоже обновлён, т.к. более новая версия модуля paramiko требовала и более свежую версию модуля ecdsa.

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

Есть масса способов собрать пакет для Debian:

• Можно доработать пакет с исходными текстами и собрать как новый пакет с исходными текстами, так и собрать из него новые двоичные пакеты.
• Для сборки пакетов с модулями python существует утилита python-stdeb: Создание deb-пакетов для модулей Python
• Для сборки пакетов с модулями perl существует утилита dh-make-perl.
• Можно попробовать сконвертировать готовый пакет из другого формата при помощи утилиты alien.
• Можно попробовать собрать пакет при помощи утилиты checkinstall.
• Наконец, можно просто создать пакет вручную при помощи утилиты dpkg-deb: 5.13 Как мне сделать собственный .deb пакет?

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

Когда утилита aptly ещё не попалась мне на глаза, я делал репозитории при помощи утилиты apt-ftparchive. Не помню подробностей, но точно помню, что была она не очень удобной в использовании.

Потом мне попалась утилита aptly, которая обладала более богатыми возможностями и была более удобна в использовании. Стоит, правда, сказать, что утилита настолько богата возможностями, что удобство использования остаётся довольно относительным. Обновлять репозитории мне приходилось нечасто, поэтому каждый раз я с трудом вспоминал, какими командами я пользовался в прошлый раз. Я стал записывать команды в wiki-страницу и пользоваться своими заметками. Правда, структурированы они были довольно плохо, поэтому в блог я ничего не публиковал. Теперь же решил упорядочить эти заметки и выложить их в блог.

Установка пакета

# apt-get install aptly

Утилита написана на языке go, в скомпилированном виде тянет за собой минимум зависимостей: это утилиты для работы с архивами и утилиты для манипуляции GPG-подписями.

Создание локальных репозиториев

Список репозиториев пока пуст:

$ aptly repo list
No local repositories found, create one with `aptly repo create ...`.

Создадим новый репозиторий с именем stretch:

$ aptly repo create stretch

Local repo [stretch] successfully added.
You can run 'aptly repo add stretch ...' to add packages to repository.

Добавление пакетов в локальный репозиторий

Добавляем в репозиторий stretch все двоичные пакеты из текущего каталога:

$ aptly repo add stretch *.deb
Loading packages...
[+] libauthen-radius-perl_0.26-1ufanet_all added
[+] libnet-ssh-expect-perl_1.09-1_all added
[+] zabbix-agent-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-agent_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-frontend-php_1:3.4.12-1+stretch-ufanet2_all added
[+] zabbix-get-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-get_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-java-gateway_1:3.4.12-1+stretch-ufanet2_all added
[+] zabbix-proxy-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-mysql_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-sqlite3-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-sqlite3_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-sender-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-sender_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-server-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-server-mysql_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-server-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-server-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 added

Следом добавляем в репозиторий stretch все пакеты с исходными текстами из текущего каталога:

$ aptly repo add stretch *.dsc
Loading packages...
[+] libauthen-radius-perl_0.26-1ufanet_source added
[+] libnet-ssh-expect-perl_1.09-1_source added
[+] zabbix_1:3.4.12-1+stretch-ufanet2_source added

По умолчанию программа размещает пакеты и базу данных в каталоге ~/.aptly

Публикация локальных репозиториев

Список опубликованных репозиториев пока пуст:

$ aptly publish list
No snapshots/local repos have been published. Publish a snapshot by running `aptly publish snapshot ...`.

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

$ aptly publish repo stretch ncc
ERROR: unable to publish: unable to guess distribution name, please specify explicitly

Посмотрим текущие настройки репозитория:

$ aptly repo show stretch
Name: stretch
Comment: 
Default Distribution: 
Default Component: main
Number of packages: 23

Укажем дистрибутив репозитория:

$ aptly repo edit -distribution="stretch" stretch
Local repo [stretch] successfully updated.

Опубликуем дистрибутив без PGP-подписи:

$ aptly publish repo -skip-signing=true stretch ncc
Loading packages...
Generating metadata files and linking package files...
Finalizing metadata files...

Local repo stretch has been successfully published.
Please setup your webserver to serve directory '/home/stupin/.aptly/public' with autoindexing.
Now you can add following line to apt sources:
  deb http://your-server/ncc/ stretch main
  deb-src http://your-server/ncc/ stretch main
Don't forget to add your GPG key to apt with apt-key.

You can also use `aptly serve` to publish your repositories over HTTP quickly.

Посмотрим список опубликованных репозиториев:

$ aptly publish list Published repositories:

ncc/stretch [amd64, source] publishes {main: [stretch]}

Опубликованные репозитории находятся в каталоге ~/.aptly/public, откуда их можно скопировать и разместить на веб-сервере. В примере выше локальный репозиторий stretch был опубликован в каталоге ncc, поэтому найти его можно будет в каталоге ~/.aptly/public/ncc

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

Для поиска пакетов, в имени которых присутствует слово zabbix и версия которых выше 1:3.4, а также пакетов, в имени которых присутствует подстрока -perl, можно воспользоваться следующей командой:

$ aptly package search '(Name (~zabbix), Version (>1:3.4)) | Name (~-perl)'

Как видно, скобки используются для группировки выражений, запятая соответствует логическому И, вертикальная черта соответствует логическому ИЛИ. Тильда обозначает совпадение с регулярным выражением, знак больше используется в своём обычном смысле. Более подробно правила фильтрации описаны в документации на странице: Package queries.

Для удаления пакетов из репозиториев используются те же самые выражения, которые используются при поиске пакетов. Например, удалим все пакеты, в имени которых присутствует подстрока zabbix:

$ aptly repo remove stretch 'Name (~zabbix)'
Loading packages...
[-] zabbix-proxy-mysql_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-sender-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-sqlite3-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-server-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix_1:3.4.12-1+stretch-ufanet2_source removed
[-] zabbix-java-gateway_1:3.4.12-1+stretch-ufanet2_all removed
[-] zabbix-server-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-agent-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-server-mysql_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-get_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-frontend-php_1:3.4.12-1+stretch-ufanet2_all removed
[-] zabbix-sender_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-get-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-server-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-agent_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-sqlite3_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 removed

Для удаления пакетов, в имени которых есть подстрока -perl, можно воспользоваться следующей командой:

$ aptly repo remove stretch 'Name (~-perl)'
Loading packages...
[-] libnet-ssh-expect-perl_1.09-1_all removed
[-] libauthen-radius-perl_0.26-1ufanet_source removed
[-] libauthen-radius-perl_0.26-1ufanet_all removed
[-] libnet-ssh-expect-perl_1.09-1_source removed

Перемещение пакетов между локальными репозиториями

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

Например, вот так можно выполнить перемещение всех пакетов, у которых в версии фигурирует подстрока stretch, из репозитория wheezy в репозиторий stretch:

$ aptly repo move wheezy stretch 'Version (~stretch)'
Loading packages...
[o] zabbix-server-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-sender_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-get-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-server-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-frontend-php_1:3.4.12-1+stretch-ufanet2_all moved
[o] zabbix-get_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-sqlite3-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-mysql_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-server-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-java-gateway_1:3.4.12-1+stretch-ufanet2_all moved
[o] zabbix-server-mysql_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-sender-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-sqlite3_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-agent-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-agent_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved

Обновление опубликованного репозитория

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

$ aptly publish update -skip-signing=true stretch ncc
Loading packages...
Generating metadata files and linking package files...
Finalizing metadata files...
Cleaning up prefix "ncc" components main...
Publish for local repo ncc/stretch [amd64, source] publishes {main: [stretch]} has been successfully updated.

Удаление устаревших пакетов

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

$ aptly db cleanup
Loading mirrors, local repos, snapshots and published repos...
Loading list of all packages...
Deleting unreferenced packages (23)...
Building list of files referenced by packages...
Building list of files in package pool...
Deleting unreferenced files (29)...
Disk space freed: 33.61 MiB...
Compacting database...

Удаление опубликованных репозиториев

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

$ aptly publish drop stretch ncc
Removing /home/stupin/.aptly/public/ncc/dists...
Removing /home/stupin/.aptly/public/ncc/pool...

Published repository has been removed successfully.

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

$ aptly publish list
No snapshots/local repos have been published. Publish a snapshot by running `aptly publish snapshot ...`.

Удаление локального репозитория

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

$ aptly repo list
List of local repos:
 * [stretch] (packages: 0)

To get more information about local repository, run `aptly repo show <name>`.

Как видно, в репозитории нет пакетов, поэтому его можно удалить.

Для удаления локального репозитория stretch можно воспользоваться такой командой:

$ aptly repo drop stretch
Local repo `stretch` has been removed.

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

$ aptly repo list
No local repositories found, create one with `aptly repo create ...`.

P. S.

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

Так, на работе всё тот же Debian Wheezy, который вышел в 2013 году, использовался мной аж до 2019 года. За это время успело выйти три новых релиза: Squeezy, Jessie, Stretch. Некоторые коллеги удивлялись, почему я продолжаю использовать этот устаревший релиз. Друге даже не догадывались об этом, т.к. им достаточно, чтобы обновлялся фасад здания, а с ржавыми трубами им дела иметь не приходилось. В 2018 году завершился срок продлённой поддержки Debian Wheezy. В 2019 году репозиторий пропал с зеркал и стало очевидно, что оттягивать обновление больше нельзя. Пришлось отложить всю текущую работу и заняться обновлениями, несмотря молчаливое и явное недовольство окружающих. Нельзя бесконечно копить технический долг — иногда нужно его возвращать.