Инструменты пользователя

Инструменты сайта


linux:overall:apt

Менеджеры пакетов

  # настройка варианта
update-alternatives --config java
 
  # перечень
update-java-alternatives --list
 
  # добавление нового варианта (последние цифры не сильно важны)
update-alternatives --install /usr/bin/java java /usr/lib/jvm/bellsoft-java17/bin/java 333
 
  # тут какая то инфа 
update-alternatives --display java
 
  # расположение jvm
/usr/lib/jvm/

apt

  • install - установка
  • remove - удаление
  • purge - полностью удалит пакет и все конфиги
  • autoremove - тоже очистка ненужного
  • show - информация о пакете
  • reinstall - переустановить пакет
  • list - список установленных пакетов
  • download (source) - скачать пакет (исходный код пакета) в текущую директорию
  • apt-get install –only-upgrade <packagename> - обновить один пакет

Репозитории

:!: Репозитории
  # Добавить репозиторий
add-apt-repository "deb https://target-site stable main"
echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" | tee /etc/apt/sources.list.d/nginx.list
  # или просто в файле **/etc/apt/sources.list**
 
  # Импорт gpg-ключей
  # Актуальный вариант
curl -s <url-адрес_ключа> | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/<новое-имя>.gpg --import
  # Затем
sudo chmod 644 /etc/apt/trusted.gpg.d/<новое-имя>.gpg
  # Старый вариант (может потребоваться установка gnupg2)
wget -q -O - https://target-site/gpg.key | apt-key add -

Main – свободное ПО, официально поддерживаемое компанией Canonical
Restricted – проприетарное ПО (в основном — драйверы устройств), официально поддерживаемое компанией Canonical
Universe – свободное ПО, официально не поддерживаемое компанией Canonical (но поддерживаемое сообществом пользователей)
Multiverse – проприетарное ПО, не поддерживаемое компанией Canonical

  # Ubuntu example
deb http://ru.archive.ubuntu.com/ubuntu/ focal main universe multiverse
deb-src http://ru.archive.ubuntu.com/ubuntu/ focal main universe multiverse

dnf (yum)

  • -qi - получить информацию об установленном пакете
  • -qip - посмотреть файлы документации определенного пакета
  • -qpR - Проверить зависимости rpm пакета перед установкой
  • -ivh - установка
  • -e - удаление (–nodeps)
dnf autoremove - авточистка
dnf info - инфо о пакете
dnf search [-C] - поиск пакетов (отказ от обновления метаданных)
dnf list [installed/available] - перечень пакетов
dnf repolist - перечень репозиториев
dnf clean all - очистка метаданных
dnf update/upgrade - обновление пакетов
dnf makecache - пересоздать кеш пакетов заново
 
dnf remove/erase httpd
dnf -v repolist
dnf list installed | cat -n
 
# Распаковать пакет
sudo rpm2cpio ha_wrapper-1.0.0-20.noarch.rpm | cpio -idmv

snap

:!: Examples
  # Установка
snap install <name> --classic(?) --stable(канал)
snap info <name>
  # Вроде установить версию в режиме разработки чтобы не обновлялась автоматом
snap refresh --devmode --channel 2022.3/stable intellij-idea-community
  # Доступные обнвления
snap refresh --list
  # Обновить пакет
snap refresh opera
  # Удалить пакет
snap revert opera
  # Список пакетов (версий пакета)
snap list
snap list --all opera
  # Внесенные изменения в систему
snap changes
  # Создать снимок
snap save
  # Список снимков
snap saved
snap saved --id=2
  # Проверить целостность снимка
snap check-snapshot 2
  # Восстановить снимок
snap restore 2 
  # Удалить снимок
snap forget 2

dpkg

  • -i имя_файла - установка указанного deb пакета
  • -s пакет - информация о пакете, статус установки, версия, зависимости и т.д.
  • –list - все установленные пакеты
  • –configure -a - очистка от ненужного

При установке deb пакета, в случае отсутствующих зависимостей, можно выполнить команду # apt-get install -f, которая установит все зависимости, после повторить установку # dpkg -i file-name.deb.
Так же, можно скопировать deb-файл в папку /var/cache/apt/archives/ и установить как обычную программу # apt install file-name

RPM Build

rpmbuild урезанная версия rpm, только для сборки, вторая может работать так же, с теми же командами

mock делает сборку в чистой среде, чрутит систему и может разом собирать для нескольких систем/архитектур, настраивается конфигом
Резы в рабочей директории («/var/lib/mock» или «/jenkins_slave/mock»), там как минимум чрутовая система, для резов можно указать отдельные пути, в параметрах «–resultdir» для первого этапа (сборка SRPMS, файлы *.src.rpm) и «–localrepo» для второго, когда генерятся уже готовые rpm

Для сборки src.rpm нужны spec файлы, с описанием параметров сборки из исходников, далее, из этих файлов генерятся готовые rpm пакеты, эти хранятся в «RPMS»

:!: Пример минимального spec, не требующего доп исходников
Name:       hello-world
Version:    1
Release:    1
Summary:    Most simple RPM package
License:    FIXME
 
%description
This is my first RPM package, which does nothing.
 
%prep
# we have no source, so nothing here
 
%build
cat > hello-world.sh <<EOF
#!/usr/bin/bash
echo Hello world
EOF
 
%install
mkdir -p %{buildroot}/usr/bin/
install -m 755 hello-world.sh %{buildroot}/usr/bin/hello-world.sh
 
%files
/usr/bin/hello-world.sh
 
%changelog
# let's skip this for now

Сборка будет так

# Создание рабочих директорий
rpmdev-setuptree
# или так 
mkdir -p my_build_dir/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
 
# Вторым аргументом регулируется уровень сборки, до сурсов, до бинарников и тд
rpmbuild -ba hello-world.spec
:!: Mock

Cборка моком, оба этапа

# Генерация файлов с исходниками (*.src.rpm)
mock -r /my_build_dir/m.cfg --buildsrpm --spec=hello.spec --sources=/my_build_dir/SOURCES
 
  # для указания пути сохранения резов
mock -r /my_build_dir/m.cfg --buildsrpm --spec=hello.spec --sources=/my_build_dir/SOURCES --resultdir=/my_build_dir/SRPMS 
 
 
# Генерация пакетов (chain для списка файлов)
mock -r /my_build_dir/m.cfg --chain $(ls *.src.rpm)
 
  # для указания пути сохранения резов, пар-р "localrepo"
mock -r /my_build_dir/m.cfg --chain $(ls *.src.rpm) --localrepo /my_build_dir/RPMS/x86_64
:!: Параллельные сборки

★ Параллельно запустить сборки с одним конфигом нельзя (одно и тоже название для chroot-папки), блокируется чрут-директория

★ Можно создавать отдельные чруты для каждой сборки, для этого есть пар-р «–uniqueext», добавляет соль в название
UPD: Есть проблема при очистке, тк кеши (/var/cache/mock) все равно создаются общие, если чиститься («–scrub=all») внутри каждой сборки то это аффактит других
Выход это использовать полную изоляцию, параметры «basedir» и «cache_topdir», можно в конфиге можно в команде запуска

★ Нужно передавать на обоих этапах (исходники и пакеты) и при очистке тоже нужно передавать этот индекс

mock -r /my_build_dir/m.cfg --uniqueext=123
 
# Сборка --buildsrpm
mock -r /workdir/sbel.cfg --buildsrpm --spec=/workdir/hello.spec --sources=/workdir/my_build_dir/SOURCES --resultdir=/workdir/my_build_dir/SRPMS --config-opts=basedir='/workdir/build/' --config-opts=cache_topdir='/workdir/build/' --uniqueext=123 
 
 
# Сборка --chain
mock -r /workdir/sbel.cfg --chain $(ls /workdir/my_build_dir/SRPMS//*.src.rpm) --localrepo /workdir/my_build_dir/RPMS/x86_64 --config-opts=basedir='/workdir/build/' --config-opts=cache_topdir='/workdir/build/'
 
 
# Очистка 
mock -r /workdir/sbel.cfg --scrub=all --config-opts=basedir='/workdir/build/' --config-opts=cache_topdir='/workdir/build/' --uniqueext=321

При таком подходе «–uniqueext» лучше все равно передавать, иначе чрут чистится вместе с кешем (который в ту же папку ложится) после первого этапе и втрой выполняется очень долго, (для второго этапа создается новый чрут и без кеша он создается очень долго)

:!: Очистка кеша

★ Mock создает chroot-окружения ОС, в «/var/lib/mock», и общие кеши в «/var/cache/mock», создается по два, второй «bootstrap» служебный, для раскатки туда сначала целевых менеджеров пакетов, чтобы потом этими менеджерами ставить все в итоговую (а не хостовым менеджером)

★ Параметр конфига «cleanup_on_success» чистит только основной чрут и только после первого этапа сборки

★ Команда «mock –clean» - удаляет только основную чрут директорию, в данном случае - «/var/lib/mock/MyOS-x86_64-123» остальные три остаются

★ Команда «mock –scrub» имеет несколько вариантов:

  • «–scrub=chroot» - тоже самое что и «mock –clean»
  • «–scrub=all» - удалит все 4 папки, тобишь и общий кеш тоже (аффектит другие сборки)
  • «–scrub=bootstrap» - удалит только bootstrap но оба, свой и общий (что тоже аффектит)
  • есть еще варианты «cache, root-cache, c-cache, yum-cache» - они тут ничем не помогут

★ Если каждая сборка будет с уникальным названием то чистить нужно обязательно, проблема в том что все доступные команды чистки затрагивают и общий кеш тоже ★ Чистить руками не удается т.к права на папки рутовые, (где то root:mock а где то root:root), в дженкинсе удалить можно только самим моком

mock -r /my_build_dir/m.cfg --uniqueext=123 --scrub=all

Запуск с изоляцией в указанной папке

mock -r /workdir/sbel.cfg --buildsrpm --config-opts=basedir='/mock-chroots/build_job_12' --config-opts=cache_topdir='/mock-chroots/build_job_12' --uniqueext=123 

Как выглядят папки

/mock-chroots/build_job_12/MyOs-x86_64:
drwxr-xr-x 2 root root 4096 Dec 13 06:53 dnf_cache
drwxr-xr-x 2 root root 4096 Dec 13 06:53 yum_cache
-rw-r--r-- 1 root root    0 Dec 13 06:53 yumcache.lock
 
/mock-chroots/build_job_12/MyOs-x86_64-868:
drwxrwxr-x 2 root root 4096 Dec 13 06:53 root
 
/mock-chroots/build_job_12/MyOs-x86_64-bootstrap:
drwxr-xr-x 6 root root 4096 Dec 13 06:53 dnf_cache
drwxrwxr-x 2 root root 4096 Dec 13 06:53 root_cache
drwxr-xr-x 2 root root 4096 Dec 13 06:53 yum_cache
-rw-r--r-- 1 root root    0 Dec 13 06:53 yumcache.lock
 
/mock-chrootsbuild_job_12/MyOs-x86_64-bootstrap-868:
-rw-rw-r--  1 root    root    0 Dec 13 06:53 buildroot.lock
drwxrwsr-x  2 jenkins mock 4096 Dec 13 06:53 results
drwxrwsr-x 12 root    mock 4096 Dec 13 06:53 root
linux/overall/apt.txt · Последнее изменение: 2024/12/13 05:49 — admin