mirror of
https://github.com/Poltern/lfs-ru.git
synced 2024-10-20 04:30:41 +03:00
1558778edf
Let's change our policy to match other "rolling release" distros and ease the procedure to fix Glibc security vulnerabilities. Squashed the commits in xry111/update-glibc branch to keep the history clean.
358 lines
29 KiB
XML
358 lines
29 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||
%general-entities;
|
||
]>
|
||
|
||
<sect1 id="ch-system-pkgmgt">
|
||
<?dbhtml filename="pkgmgt.html"?>
|
||
|
||
<title>Управление пакетами</title>
|
||
|
||
<para>Управление пакетами — часто cпрашиваемое дополнение к книге LFS. Менеджер
|
||
пакетов позволяет отслеживать установку файлов, упрощая удаление и обновление
|
||
пакетов. Хороший менеджер пакетов также будет обрабатывать конфигурационные файлы,
|
||
чтобы сохранить пользовательские настройки при переустановке или обновлении пакета.
|
||
Прежде чем вы начнете задаваться вопросом, НЕТ—в этом разделе не будет ни
|
||
говориться, ни рекомендоваться какой-либо конкретный менеджер пакетов. Что он
|
||
действительно предоставляет, так это обзор наиболее популярных методов и того,
|
||
как они работают. Идеальным менеджером пакетов для вас может быть один из этих
|
||
методов или комбинация двух и более методов. В этом разделе кратко упоминаются
|
||
проблемы, которые могут возникнуть при обновлении пакетов.</para>
|
||
|
||
<para>Некоторые причины, по которым менеджер пакетов не упоминается в LFS или BLFS
|
||
представлены ниже:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Рассмотрение управления пакетами отвлекает внимание от целей этих
|
||
книг—обучения тому, как строится система Linux.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Существует множество решений для управления пакетами, каждое из
|
||
которых имеет свои сильные и слабые стороны. Трудно найти такое,
|
||
которое удовлетворит всех.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Есть несколько советов, написанных на тему управления пакетами. Посетите
|
||
проект <ulink url="&hints-root;">Советы</ulink> возможно вы найдете решение,
|
||
которое соответствует вашим потребностям.</para>
|
||
|
||
<sect2 id='pkgmgmt-upgrade-issues'>
|
||
<title>Проблемы с обновлением</title>
|
||
|
||
<para>Менеджер пакетов упрощает обновление до более новых версий после их
|
||
выпуска. Как правило, инструкции в книгах LFS и BLFS можно использовать для
|
||
обновления до более новых версий. Вот некоторые моменты, о которых следует
|
||
помнить при обновлении пакетов, особенно в работающей системе.</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Если нужно обновить ядро Linux (например, с 5.10.17 до 5.10.18 или
|
||
5.11.1), дополнительно пересобирать ничего не нужно. Система продолжит
|
||
нормально работать благодаря четко определенной границе между ядром и
|
||
пользовательским пространством. В частности, заголовки Linux API не нужно
|
||
обновлять вместе с ядром. Вам просто нужно перезагрузить систему, чтобы
|
||
использовать обновленное ядро.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Если необходимо обновить Glibc до более новой версии (например, с Glibc-2.36
|
||
до Glibc-&glibc-version;) необходимо выполнить некоторые дополнительные действия,
|
||
чтобы избежать поломки системы. Подробности читайте в <xref linkend='ch-system-glibc'/>.</para>
|
||
</listitem>
|
||
|
||
<listitem> <para>Если пакет, содержащий общую библиотеку, обновляется и имя
|
||
библиотеки изменилось, то любые пакеты, динамически связанные с библиотекой,
|
||
необходимо перекомпилировать, чтобы связать с более новой библиотекой.
|
||
(Обратите внимание, что между версией пакета и именем библиотеки нет никакой
|
||
связи.) Например, рассмотрим пакет foo-1.2.3, который устанавливает общую
|
||
библиотеку с именем <filename class='libraryfile'>libfoo.so.1</filename>.
|
||
Предположим, вы обновили пакет до более новой версии foo-1.2.4, которая устанавливает
|
||
общую библиотеку с именем <filename class='libraryfile'>libfoo.so.2</filename>,
|
||
все пакеты, которые динамически связаны с <filename class='libraryfile'>libfoo.so.1</filename>,
|
||
должны быть перекомпилированы для связи с <filename class='libraryfile'>libfoo.so.2</filename>,
|
||
чтобы использовать новую версию библиотеки. Вы не должны удалять старые
|
||
библиотеки, пока все зависимые пакеты не будут перекомпилированы.</para>
|
||
</listitem>
|
||
|
||
<listitem><para>Если пакет (прямо или косвенно) связан как со старым, так и
|
||
с новым именем общей библиотеки (например, пакет ссылается как на
|
||
<filename class='libraryfile'>libfoo.so.2</filename>, так и на
|
||
<filename class='libraryfile'>libbar.so.1</filename>, в то время как последний
|
||
ссылается на <filename class='libraryfile'>libfoo.so.3</filename>), пакет может
|
||
работать неправильно, поскольку разные версии общей библиотеки содержат несовместимые
|
||
определения для некоторых имен символов. Это может быть вызвано перекомпиляцией
|
||
некоторых, но не всех, пакетов, связанных со старой общей библиотекой, после
|
||
обновления пакета, предоставляющего общую библиотеку. Чтобы избежать этой проблемы,
|
||
пользователям необходимо как можно скорее пересобрать каждый пакет, связанный с
|
||
общей библиотекой, с обновленной версией (например, с libfoo.so.2 на libfoo.so.3).
|
||
</para></listitem>
|
||
|
||
<listitem> <para>Если пакет, содержащий общую библиотеку, обновляется, а имя
|
||
библиотеки не меняется, но уменьшается номер версии <emphasis role="bold">файла</emphasis>
|
||
библиотеки (например, библиотека по-прежнему называется
|
||
<filename class='libraryfile'>libfoo.so.1</filename>, но имя файла библиотеки изменилось с
|
||
<filename class='libraryfile'>libfoo.so.1.25</filename> на
|
||
<filename class='libraryfile'>libfoo.so.1.24</filename>), следует удалить файл
|
||
библиотеки ранее установленной версии (в данном случае
|
||
<filename class='libraryfile'>libfoo.so.1.25</filename>). В противном случае, команда
|
||
<command>ldconfig</command> (запущенная самостоятельно с помощью командной строки или
|
||
при установке какого-либо пакета) приведёт к сбросу символической ссылки
|
||
<filename class='libraryfile'>libfoo.so.1</filename>,
|
||
которая будет указывать на старый файл библиотеки, потому что кажется, что она имеет
|
||
<quote>более новую</quote> версию, поскольку её номер версии больше. Такая ситуация
|
||
может произойти, если вам нужно понизить версию пакета или авторы изменили
|
||
схему управления версиями файлов библиотеки.</para></listitem>
|
||
|
||
<listitem><para>Если пакет, содержащий общую библиотеку, обновляется, а имя библиотеки
|
||
не меняется, но устраняется серьезная проблема (особенно уязвимость в системе безопасности),
|
||
необходимо перезапустить все работающие программы, связанные с общей библиотекой. Следующая
|
||
команда, запущенная от имени пользователя <systemitem class="username">root</systemitem> после
|
||
завершения обновления, выведет список программ, которые использует старые версии этих библиотек
|
||
(замените <replaceable>libfoo</replaceable> именем библиотеки):</para>
|
||
|
||
<screen role="nodump"><userinput>grep -l '<replaceable>libfoo</replaceable>.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u</userinput></screen>
|
||
|
||
<para>
|
||
Если для доступа к системе используется <application>OpenSSH</application> и он
|
||
связан с обновленной библиотекой, вам необходимо перезапустить службу
|
||
<command>sshd</command>, затем выйти из системы, снова войти в систему и повторно
|
||
выполнить предыдущую команду, чтобы убедиться, что удаленные библиотеки более
|
||
не используются.
|
||
</para>
|
||
|
||
<para revision='systemd'>
|
||
Если демон <command>systemd</command> (работающий как PID 1) связан с обновленной
|
||
библиотекой, вы можете перезапустить его без перезагрузки, запустив
|
||
<command>systemctl daemon-reexec</command> от имени пользователя
|
||
<systemitem class='username'>root</systemitem>.
|
||
</para></listitem>
|
||
|
||
<listitem>
|
||
<para>Если исполняемая программа или библиотека перезаписаны, процессы, использующие
|
||
код или данные из них, могут завершиться сбоем. Правильный способ обновить программу
|
||
или общую библиотеку, не вызывая сбоя процесса, - это сначала удалить его,
|
||
а затем установить новую версию. Команда <command>install</command>,
|
||
предоставляемая <application>Coreutils</application>, уже реализовала это, и
|
||
большинство пакетов используют ее для установки двоичных файлов и библиотек.
|
||
Это означает, что большую часть времени вас не будет беспокоить эта проблема.
|
||
Однако процесс установки некоторых пакетов (в частности, SpiderMonkey в BLFS)
|
||
просто перезаписывает файл, если он существует, и вызывает сбой. Поэтому
|
||
безопаснее сохранить свою работу и закрыть ненужные запущенные программы перед
|
||
обновлением пакета.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Методы управления пакетами</title>
|
||
|
||
<para>Ниже приведены некоторые распространенные методы управления пакетами. Прежде
|
||
чем принять решение о менеджере пакетов, проведите исследование различных методов,
|
||
особенно недостатки каждой конкретной схемы.</para>
|
||
|
||
<sect3>
|
||
<title>Всё у меня в голове!</title>
|
||
|
||
<para>Да, это метод управления пакетами. Некоторым людям не нужен менеджер пакетов,
|
||
потому что они хорошо знакомы с пакетами и знают, какие файлы устанавливаются
|
||
каждым пакетом. Некоторым пользователям также не требуется какое-либо управление
|
||
пакетами, поскольку они планируют пересобирать всю систему при каждом изменении пакета.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Установка в отдельные каталоги</title>
|
||
|
||
<para>Это упрощенный метод управления пакетами, для которого не требуется
|
||
специальная программа управления. Каждый пакет устанавливается в отдельный
|
||
каталог. Например, пакет foo-1.1 устанавливается в
|
||
<filename class='directory'>/opt/foo-1.1</filename>, а символическая ссылка
|
||
создается из <filename>/opt/foo</filename> в
|
||
<filename class='directory'>/opt/foo-1.1</filename>. Когда появляется новая
|
||
версия foo-1.2, она устанавливается в <filename class='directory'>/opt/foo-1.2</filename>
|
||
и предыдущая символическая ссылка заменяется символической ссылкой на новую версию.</para>
|
||
|
||
<para>Переменные окружения, такие как <envar>PATH</envar>, <envar>MANPATH</envar>,
|
||
<envar>INFOPATH</envar>, <envar>PKG_CONFIG_PATH</envar>, <envar>CPPFLAGS</envar>,
|
||
<envar>LDFLAGS</envar> и файл конфигурации <filename>/etc/ld.so.conf</filename>,
|
||
возможно, потребуется расширить, включив соответствующие подкаталоги в
|
||
<filename>/opt/foo-x.y</filename>.</para>
|
||
|
||
<para>
|
||
Этот подход используется в книге BLFS для установки некоторых очень больших пакетов,
|
||
чтобы упростить их обновление. Если вы устанавливаете много таких пакетов, эта схема
|
||
становится неуправляемой. Некоторые пакеты (например, заголовки Linux API и Glibc)
|
||
могут плохо работать с такой структурой. <emphasis role='bold'>Никогда не
|
||
используйте её в масштабах всей системы.</emphasis>
|
||
</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Управление пакетами с использованием символических ссылок</title>
|
||
|
||
<para>Это разновидность предыдущей техники.Каждый пакет устанавливается аналогично,
|
||
но вместо создания символической ссылки на общее имя пакета, каждому файлу создаётся
|
||
символическая ссылка в иерархии каталогов <filename class='directory'>/usr</filename>.
|
||
Это исключает необходимость модификации значений переменных окружения. Хотя такие
|
||
ссылки могут быть созданы пользователем, многие менеджеры пакетов используют именной
|
||
такой подход. Наиболее популярные из них - Stow, Epkg, Graft и Depot.</para>
|
||
|
||
<para>Установку нужно сымитировать, чтобы пакет думал, что он установлен в
|
||
<filename class="directory">/usr</filename>, хотя на самом деле он установлен в
|
||
иерархии <filename class="directory">/usr/pkg</filename>. Установка таким
|
||
способом обычно является нетривиальной задачей. Например, предположим, что
|
||
вы устанавливаете пакет libfoo-1.1. Следующие инструкции могут привести к
|
||
неправильной установке пакета:</para>
|
||
|
||
<screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
|
||
make
|
||
make install</userinput></screen>
|
||
|
||
<para>Установка будет выполнена, но зависимые пакеты не смогут ссылаться на libfoo.
|
||
Если вы скомпилируете пакет, который ссылается на libfoo, вы заметите, что он
|
||
связан с <filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
|
||
вместо <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>, как вы
|
||
ожидаете. Правильный подход заключается в использовании переменной
|
||
<envar>DESTDIR</envar> для управления установкой. Этот подход работает следующим образом:</para>
|
||
|
||
<screen role="nodump"><userinput>./configure --prefix=/usr
|
||
make
|
||
make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
|
||
|
||
<para>Большинство пакетов поддерживают этот подход, но есть и такие, которые
|
||
этого не делают. Для несовместимых пакетов вам может потребоваться либо установить
|
||
пакет вручную, либо вы можете установить проблемные пакеты в
|
||
<filename class='directory'>/opt</filename>.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>На основе временной метки</title>
|
||
|
||
<para>В этом методе файлу присваивается временная метка перед установкой пакета.
|
||
После установки простое использование команды <command>find</command> с
|
||
соответствующими параметрами может создать журнал всех файлов, установленных
|
||
после создания файла с временной метки. Менеджером пакетов, использующим этот
|
||
подход, является install-log.</para>
|
||
|
||
<para>Хотя преимущество этой схемы в том, что она проста, у нее есть два
|
||
недостатка. Если во время установки, файлы устанавливаются с отметкой времени,
|
||
отличной от текущего времени, эти файлы не будут отслеживаться менеджером пакетов.
|
||
Кроме того, эта схема может использоваться только при установке пакетов по одному.
|
||
Журналы ненадежны, если два пакета устанавливаются одновременно на двух разных
|
||
консолях.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Отслеживание сценариев установки</title>
|
||
|
||
<para>При таком подходе, записываются команды, выполняемые сценариями установки.
|
||
Есть два метода, которые можно использовать:</para>
|
||
|
||
<para>Переменная среды <envar>LD_PRELOAD</envar> может быть установлена так,
|
||
чтобы она указывала на библиотеку, которую нужно предварительно загрузить
|
||
перед установкой. Во время установки эта библиотека отслеживает устанавливаемые
|
||
пакеты, присоединяясь к различным исполняемым файлам, таким как <command>cp</command>,
|
||
<command>install</command>, <command>mv</command>, и отслеживая системные вызовы,
|
||
изменяющие файловую систему. Чтобы этот подход работал, все исполняемые файлы
|
||
должны быть динамически связаны без битов suid или sgid. Предварительная загрузка
|
||
библиотеки может вызвать некоторые нежелательные побочные эффекты во время
|
||
установки. Поэтому рекомендуется выполнить некоторые тесты, чтобы убедиться, что
|
||
менеджер пакетов ничего не сломает и что он регистрирует все соответствующие файлы.</para>
|
||
|
||
<para>Другой метод заключается в использовании <command>strace</command>, который
|
||
регистрирует все системные вызовы, сделанные во время выполнения сценариев установки.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Создание архивов пакетов</title>
|
||
|
||
<para>В этой схеме установка пакета имитируется в отдельном дереве, как описано
|
||
ранее в разделе управление пакетами с использованием символических ссылок.
|
||
После установки из установленных файлов создается архив пакета. Затем этот архив
|
||
используется для установки пакета на локальный компьютер или даже на другие компьютеры.</para>
|
||
|
||
<para>Этот подход используется большинством менеджеров пакетов, имеющихся в
|
||
коммерческих дистрибутивах. Примерами менеджеров пакетов, которые следуют этому
|
||
подходу, являются RPM (который, кстати, требуется согласно спецификации <ulink
|
||
url="https://refspecs.linuxfoundation.org/lsb.shtml">Linux
|
||
Standard Base Specification</ulink>), pkg-utils, apt Debian и система Portage
|
||
Gentoo. Описание того, как использовать этот стиль управления пакетами для систем
|
||
LFS, находится по адресу <ulink url="&hints-root;fakeroot.txt"/>.</para>
|
||
|
||
<para>Создание файлов пакетов, содержащих информацию о зависимостях, является
|
||
сложной задачей и выходит за рамки LFS.</para>
|
||
|
||
<para>Slackware использует систему на основе <command>tar</command> для архивов
|
||
пакетов. Эта система намеренно не обрабатывает зависимости пакетов, как это
|
||
делают более сложные менеджеры пакетов. Подробнее об управлении пакетами Slackware
|
||
см. <ulink url="https://www.slackbook.org/html/package-management.html"/>.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Пользовательское управление пакетами</title>
|
||
|
||
<para>Эта схема, уникальная для LFS, была разработана Маттиасом Бенкманом и доступна
|
||
в проекте <ulink url="&hints-root;">Hints</ulink>. В этой схеме каждый пакет
|
||
устанавливается отдельным пользователем в стандартные папки. Файлы, принадлежащие
|
||
пакету, легко идентифицируются путем проверки идентификатора пользователя. Особенности
|
||
и недостатки этого подхода слишком сложны, чтобы описывать их в этом разделе. Для
|
||
получения более подробной информации, пожалуйста, ознакомьтесь с советами по адресу
|
||
<ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>
|
||
|
||
</sect3>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Развертывание LFS на нескольких системах</title>
|
||
|
||
<para>Одним из преимуществ системы LFS является отсутствие файлов, зависящих от
|
||
положения файлов на диске. Клонировать сборку LFS на другой компьютер с той же
|
||
архитектурой, что и у базовой системы, так же просто, как использовать
|
||
<command>tar</command> для архивации раздела LFS, содержащем корневой каталог
|
||
(около 900 МБ в несжатом виде для базовой сборки LFS), скопировать этот файл
|
||
<!-- D. Bryant created LFS 11.2 in October 2022; 900MB is (roughly) the size of his rsync archive. -->
|
||
по сети или с помощью CD / USB носителя в новую систему и распаковать его. После
|
||
этого необходимо изменить несколько конфигурационных файлов. Файлы, которые,
|
||
возможно, потребуется изменить представлены в списке ниже:
|
||
<filename>/etc/hosts</filename>,
|
||
<filename>/etc/fstab</filename>,
|
||
<filename>/etc/passwd</filename>,
|
||
<filename>/etc/group</filename>,
|
||
<phrase revision="systemd">
|
||
<filename>/etc/shadow</filename>, и
|
||
<filename>/etc/ld.so.conf</filename>.
|
||
</phrase>
|
||
<phrase revision="sysv">
|
||
<filename>/etc/shadow</filename>,
|
||
<filename>/etc/ld.so.conf</filename>,
|
||
<filename>/etc/sysconfig/rc.site</filename>,
|
||
<filename>/etc/sysconfig/network</filename>, и
|
||
<filename>/etc/sysconfig/ifconfig.eth0</filename>.
|
||
</phrase>
|
||
</para>
|
||
|
||
<para>Возможно, потребуется собрать собственное ядро для новой системы в зависимости
|
||
от различий в системном оборудовании и исходной конфигурации ядра.</para>
|
||
|
||
<note><para>Поступали некоторые сообщения о проблемах при копировании между похожими,
|
||
но не идентичными архитектурами. Например, набор инструкций для Intel не идентичен
|
||
набору инструкций для процессора AMD, и более поздние версии некоторых процессоров
|
||
могут содержать инструкции, недоступные в более ранних версиях.</para></note>
|
||
|
||
<para>Наконец, новую систему необходимо сделать загрузочной так, как это описано в <xref
|
||
linkend="ch-bootable-grub"/>.</para>
|
||
|
||
</sect2>
|
||
|
||
</sect1>
|