Translated page systemd-custom

This commit is contained in:
Poltern 2023-06-08 23:48:47 +05:00
parent c2e8c53d13
commit 3ca8ee1299
3 changed files with 131 additions and 157 deletions

View File

@ -60,7 +60,7 @@
<note> <note>
<para>Имена интерфейсов зависят от реализации и конфигурации демона udev, запущенного в системе. <para>Имена интерфейсов зависят от реализации и конфигурации демона udev, запущенного в системе.
Udev-демон для LFS (установленный в <xref linkend="ch-system-eudev"/>) не будет запускаться до тех Udev-демон для LFS (установленный в <xref linkend="ch-system-systemd"/>) не будет запускаться до тех
пор, пока не загрузится система LFS. Таким образом, не правильно определять имена интерфейсов, пор, пока не загрузится система LFS. Таким образом, не правильно определять имена интерфейсов,
используемых в системе LFS, путем запуска этой команды в хост-дистрибутиве, используемых в системе LFS, путем запуска этой команды в хост-дистрибутиве,
<emphasis>даже в среде chroot</emphasis>.</para> <emphasis>даже в среде chroot</emphasis>.</para>

View File

@ -8,30 +8,28 @@
<sect1 id="ch-config-systemd-custom" revision="systemd"> <sect1 id="ch-config-systemd-custom" revision="systemd">
<?dbhtml filename="systemd-custom.html"?> <?dbhtml filename="systemd-custom.html"?>
<title>Systemd Usage and Configuration</title> <title>Настройка и использование Systemd</title>
<indexterm zone="ch-config-systemd-custom"> <indexterm zone="ch-config-systemd-custom">
<primary sortas="e-Systemd">Systemd Customization</primary> <primary sortas="e-Systemd">Systemd Customization</primary>
</indexterm> </indexterm>
<sect2> <sect2>
<title>Basic Configuration</title> <title>Базовая настройка</title>
<para>The <filename>/etc/systemd/system.conf</filename> file contains a set <para>Файл <filename>/etc/systemd/system.conf</filename> содержит параметры для управления
of options to control basic systemd operations. The default file has all основными операциями systemd. Изначально все записи в этом файле закомментированы с
entries commented out with the default settings indicated. This file is указанием настроек по умолчанию. В этом файле может быть изменен уровень логирования, а также
where the log level may be changed as well as some basic logging settings. некоторые базовые настройки ведения файлов логов. Смотрите страницу руководства
See the <filename>systemd-system.conf(5)</filename> manual page for details <filename>systemd-system.conf(5)</filename> для получения подробной информации по каждому параметру.</para>
on each configuration option.</para>
</sect2> </sect2>
<sect2> <sect2>
<title>Disabling Screen Clearing at Boot Time</title> <title>Отключение очистки экрана во время загрузки</title>
<para>The normal behavior for systemd is to clear the screen at <para>Обычным поведением systemd является очистка экрана по окончании загрузки. При желании
the end of the boot sequence. If desired, this behavior may be такое поведение можно изменить, выполнив следующую команду:</para>
changed by running the following command:</para>
<screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/getty@tty1.service.d <screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/getty@tty1.service.d
@ -40,41 +38,38 @@ cat &gt; /etc/systemd/system/getty@tty1.service.d/noclear.conf &lt;&lt; EOF
TTYVTDisallocate=no</literal> TTYVTDisallocate=no</literal>
EOF</userinput></screen> EOF</userinput></screen>
<para>The boot messages can always be reviewed by using the <para>Сообщения, отображаемые при загрузке всегда можно просмотреть, используя команду
<userinput>journalctl -b</userinput> command as the <userinput>journalctl -b</userinput> от имени пользователя
<systemitem class="username">root</systemitem> user.</para> <systemitem class="username">root</systemitem> user.</para>
</sect2> </sect2>
<sect2> <sect2>
<title>Disabling tmpfs for /tmp</title> <title>Отключение tmpfs для /tmp</title>
<para>By default, <filename class="directory">/tmp</filename> is created as <para>По умолчанию каталог <filename class="directory">/tmp</filename> монтируется как
a tmpfs. If this is not desired, it can be overridden by executing the tmpfs. Если такое поведение нежелательно, его можно переопределить, выполнив
following command:</para> следующую команду:</para>
<screen role="nodump"><userinput>ln -sfv /dev/null /etc/systemd/system/tmp.mount</userinput></screen> <screen role="nodump"><userinput>ln -sfv /dev/null /etc/systemd/system/tmp.mount</userinput></screen>
<para>Alternatively, if a separate partition for <para>В качестве альтернативы, если требуется отдельный раздел для
<filename class="directory">/tmp</filename> is desired, specify that <filename class="directory">/tmp</filename> укажите его в <filename>/etc/fstab</filename>.</para>
partition in a <filename>/etc/fstab</filename> entry.</para>
<warning> <warning>
<para> <para>
Do not create the symbolic link above if a separate partition is used Не создавайте символическую ссылку, указанную выше, если используется отдельный раздел
for <filename class="directory">/tmp</filename>. This will prevent the для <filename class="directory">/tmp</filename>. Это помешает монтированию корневой файловой
root file system (/) from being remounted r/w and make the system системы (/) в режиме r/w и сделает систему непригодной для загрузки.
unusable when booted.
</para> </para>
</warning> </warning>
</sect2> </sect2>
<sect2> <sect2>
<title>Configuring Automatic File Creation and Deletion</title> <title>Настройка автоматического создания и удаления временных файлов</title>
<para>There are several services that create or delete files or <para>Существует несколько служб, которые создают или удаляют файлы или каталоги:</para>
directories:</para>
<itemizedlist> <itemizedlist>
<listitem><para>systemd-tmpfiles-clean.service</para></listitem> <listitem><para>systemd-tmpfiles-clean.service</para></listitem>
@ -82,37 +77,30 @@ EOF</userinput></screen>
<listitem><para>systemd-tmpfiles-setup.service</para></listitem> <listitem><para>systemd-tmpfiles-setup.service</para></listitem>
</itemizedlist> </itemizedlist>
<para>The system location for the configuration files is <para>Системные файлы конфигурации расположены в
<filename>/usr/lib/tmpfiles.d/*.conf</filename>. The local <filename>/usr/lib/tmpfiles.d/*.conf</filename>. Локальные конфигурационные файлы находятся в
configuration files are in <filename class="directory">/etc/tmpfiles.d</filename>. Файлы в
<filename class="directory">/etc/tmpfiles.d</filename>. Files in <filename class="directory">/etc/tmpfiles.d</filename> переопределяют файлы с таким же именем в
<filename class="directory">/etc/tmpfiles.d</filename> override <filename class="directory">/usr/lib/tmpfiles.d</filename>. Смотрите подробности по формату файла
files with the same name in в руководстве <filename>tmpfiles.d(5)</filename>.</para>
<filename class="directory">/usr/lib/tmpfiles.d</filename>. See
<filename>tmpfiles.d(5)</filename> manual page for file format
details.</para>
<para> <para>
Note that the syntax for the Обратите внимание, что синтаксис файлов в
<filename>/usr/lib/tmpfiles.d/*.conf</filename> files can be <filename>/usr/lib/tmpfiles.d/*.conf</filename> может сбивать с толку.
confusing. For example, the default deletion of files in the /tmp directory Например, по умолчанию, удаление файлов в каталоге /tmp находится в
is located in <filename>/usr/lib/tmpfiles.d/tmp.conf</filename> with файле <filename>/usr/lib/tmpfiles.d/tmp.conf</filename> в строке:
the line:
<screen role="nodump">q /tmp 1777 root root 10d</screen> <screen role="nodump">q /tmp 1777 root root 10d</screen>
The type field, q, discusses creating a subvolume with quotas which q, в поле type, указывает что необходимо создать подраздел с квотами, которые применимы только
is really only applicable to btrfs filesystems. It references type v к файловым системам btrfs. Он ссылается на type v который, в свою очередь, ссылается на type d (каталог).
which in turn references type d (directory). This then creates the Затем создается указанный каталог, если он отсутствует, и настраиваются разрешения и владелец. Содержимое
specified directory if it is not present and adjusts the permissions каталога будет очищаться через указанный интервал времени, если указан аргумент age.
and ownership as specified. Contents of the directory will be
subject to time based cleanup if the age argument is specified.
</para> </para>
<para> <para>
If the default parameters are not desired, then the file should Если параметры по умолчанию не нужны, файл следует скопировать в
be copied to <filename class="directory">/etc/tmpfiles.d</filename> <filename class="directory">/etc/tmpfiles.d</filename> и отредактировать по желанию. Например:
and edited as desired. For example:
<screen role="nodump"><userinput>mkdir -p /etc/tmpfiles.d <screen role="nodump"><userinput>mkdir -p /etc/tmpfiles.d
cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d</userinput></screen> cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d</userinput></screen>
@ -121,11 +109,10 @@ cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d</userinput></screen>
</sect2> </sect2>
<sect2> <sect2>
<title>Overriding Default Services Behavior</title> <title>Переопределение поведения служб по умолчанию</title>
<para>The parameters of a unit can be overridden by creating a directory <para>Параметры юнита можно переопределить, создав каталог и файл конфигурации в
and a configuration file in <filename <filename class="directory">/etc/systemd/system</filename>. Например:</para>
class="directory">/etc/systemd/system</filename>. For example:</para>
<screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/foobar.service.d <screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/foobar.service.d
@ -135,114 +122,107 @@ Restart=always
RestartSec=30</literal> RestartSec=30</literal>
EOF</userinput></screen> EOF</userinput></screen>
<para>See <filename>systemd.unit(5)</filename> manual page for more <para>Дополнительную информацию смотрите на странице руководства
information. After creating the configuration file, run <filename>systemd.unit(5)</filename>. После создания файла конфигурации запустите
<userinput>systemctl daemon-reload</userinput> and <userinput>systemctl <userinput>systemctl daemon-reload</userinput> и <userinput>systemctl
restart foobar</userinput> to activate the changes to a service.</para> restart foobar</userinput>, чтобы активировать изменения в службе.</para>
</sect2> </sect2>
<sect2> <sect2>
<title>Debugging the Boot Sequence</title> <title>Отладка порядка загрузки служб</title>
<para>Rather than plain shell scripts used in SysVinit or BSD style init <para>Вместо простых сценариев оболочки, используемых в системах инициализации SysVinit или BSD,
systems, systemd uses a unified format for different types of startup systemd использует унифицированный формат для различных типов запускаемых файлов (или юнитов).
files (or units). The command <command>systemctl</command> is used to Команда <command>systemctl</command> используется для запуска, остановки, управления состоянием
enable, disable, control state, and obtain status of unit files. Here и получения статуса юнит-файлов. Ниже несколько примеров часто используемых команд:</para>
are some examples of frequently used commands:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para><command>systemctl list-units -t <replaceable>&lt;service&gt;</replaceable> [--all]</command>: <para><command>systemctl list-units -t <replaceable>&lt;service&gt;</replaceable> [--all]</command>:
lists loaded unit files of type service.</para> выводит список загруженных юнит-файлов типа service.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><command>systemctl list-units -t <replaceable>&lt;target&gt;</replaceable> [--all]</command>: <para><command>systemctl list-units -t <replaceable>&lt;target&gt;</replaceable> [--all]</command>:
lists loaded unit files of type target.</para> выводит список загруженных юнит-файлов типа target.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><command>systemctl show -p Wants <replaceable>&lt;multi-user.target&gt;</replaceable></command>: <para><command>systemctl show -p Wants <replaceable>&lt;multi-user.target&gt;</replaceable></command>:
shows all units that depend on the multi-user target. Targets are показывает все юнит-файлы, зависящие от multi-user target (многопользовательского режима).
special unit files that are analogous to runlevels under Target - специальные юнит-файлы, которые аналогичны уровням запуска в SysVinit.</para>
SysVinit.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><command>systemctl status <replaceable>&lt;servicename.service&gt;</replaceable></command>: <para><command>
shows the status of the servicename service. The .service extension systemctl status <replaceable>&lt;servicename.service&gt;</replaceable></command>:
can be omitted if there are no other unit files with the same name, показывает статус службы servicename. Расширение .service можно опустить, если нет
such as .socket files (which create a listening socket that provides других юнит-файлов с таким же именем, например, .socket (которые создают прослушивающий
similar functionality to inetd/xinetd).</para> сокет, обеспечивающий функции аналогичные inetd/xinetd).</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</sect2> </sect2>
<sect2> <sect2>
<title>Working with the Systemd Journal</title> <title>Работа с журналом Systemd</title>
<para>Logging on a system booted with systemd is handled with <para>Вход в систему, загруженную с помощью systemd, обрабатывается с помощью systemd-journald
systemd-journald (by default), rather than a typical unix syslog daemon. (по умолчанию), а не классическим демоном системного журнала unix. При желании, вы можете добавить
You can also add a normal syslog daemon and have both operate side by обычный демон системного журнала и заставить их работать бок о бок. Программа systemd-journald
side if desired. The systemd-journald program stores journal entries in a сохраняет записи журнала в двоичном формате, а не в обычном текстовом. Для разбора лога предоставляется
binary format rather than a plain text log file. To assist with команда <command>journalctl</command>. Ниже несколько примеров часто используемых команд:</para>
parsing the file, the command <command>journalctl</command> is provided.
Here are some examples of frequently used commands:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para><command>journalctl -r</command>: shows all contents of the <para><command>journalctl -r</command>: показывает все содержимое журнала в обратном
journal in reverse chronological order.</para> хронологическом порядке.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><command>journalctl -u <replaceable>UNIT</replaceable></command>: <para><command>journalctl -u <replaceable>UNIT</replaceable></command>:
shows the journal entries associated with the specified UNIT показывает записи журнала, связанные с указанным юнит-файлом.</para>
file.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><command>journalctl -b[=ID] -r</command>: shows the journal <para><command>journalctl -b[=ID] -r</command>: показывает записи журнал с момента последней
entries since last successful boot (or for boot ID) in reverse успешной загрузки (или для идентификатора загрузки) в обратном порядке хронологический порядоке.</para>
chronological order.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><command>journalctl -f</command>: provides functionality similar <para><command>journalctl -f</command>: предоставляет функциональность, аналогичную tail -f
to tail -f (follow).</para> (режим следования).</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</sect2> </sect2>
<sect2> <sect2>
<title>Working with Core Dumps</title> <title>Работа с дампами ядра</title>
<para>Core dumps are useful to debug crashed programs, especially <para>Дампы ядра полезны для отладки аварийно завершившихся программ, особенно,
when a daemon process crashes. On systemd booted systems the core когда происходит сбой процесса демона. В системах с systemd дампы ядра обрабатывается
dumping is handled by <command>systemd-coredump</command>. It will командой <command>systemd-coredump</command>. Команда запишет дамп в журнал и сохранит
log the core dump in the journal and store the core dump itself in сам дамп ядра в <filename class="directory">/var/lib/systemd/coredump</filename>.
<filename class="directory">/var/lib/systemd/coredump</filename>. Чтобы получить и обработать дамп, предоставляется инструмент <command>coredumpctl</command>.
To retrieve and process core dumps, the <command>coredumpctl</command> Несколько примеров часто используемых команд:
tool is provided. Here are some examples of frequently used commands:
</para> </para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para><command>coredumpctl -r</command>: lists all core dumps in <para><command>coredumpctl -r</command>: выводит список всех дампов в обратном
reverse chronological order.</para> хронологическом порядке.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><command>coredumpctl -1 info</command>: shows the information <para><command>coredumpctl -1 info</command>: отображает информацию из последнего
from the last core dump.</para> дампа ядра.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><command>coredumpctl -1 debug</command>: loads the last core <para><command>coredumpctl -1 debug</command>: загружает последний дамп ядра
dump into <ulink url="&blfs-book;general/gdb.html">GDB</ulink>. <ulink url="&blfs-book;general/gdb.html">GDB</ulink>.
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
<para>Core dumps may use a lot of disk space. The maximum disk space <para>Дампы ядра могут занимать много места на диске. Можно ограничить место на диске,
used by core dumps can be limited by creating a configuration file in занимаемое дампами ядра, создав конфигурационный файл в
<filename class="directory">/etc/systemd/coredump.conf.d</filename>. <filename class="directory">/etc/systemd/coredump.conf.d</filename>.
For example:</para> Например:</para>
<screen role="nodump"><userinput>mkdir -pv /etc/systemd/coredump.conf.d <screen role="nodump"><userinput>mkdir -pv /etc/systemd/coredump.conf.d
@ -251,61 +231,55 @@ cat &gt; /etc/systemd/coredump.conf.d/maxuse.conf &lt;&lt; EOF
MaxUse=5G</literal> MaxUse=5G</literal>
EOF</userinput></screen> EOF</userinput></screen>
<para>See the <filename>systemd-coredump(8)</filename>, <para>Смотрите следующие страницы руководства для получения дополнительной информации
<filename>coredumpctl(1)</filename>, and информация <filename>systemd-coredump(8)</filename>,
<filename>coredump.conf.d(5)</filename> manual pages for more <filename>coredumpctl(1)</filename>, и
information.</para> <filename>coredump.conf.d(5)</filename>.</para>
</sect2> </sect2>
<sect2> <sect2>
<title>Long Running Processes</title> <title>Длительно выполняющиеся процессы</title>
<para>Beginning with systemd-230, all user processes are killed when a user <para>Начиная с версии systemd-230, все пользовательские процессы завершаются, когда завершается
session is ended, even if nohup is used, or the process uses the пользовательская сессия, даже если используется nohup или процесс использует функции
<function>daemon()</function> or <function>setsid()</function> functions. <function>daemon()</function> или <function>setsid()</function>.Это намеренный переход от
This is a deliberate change from a historically permissive environment to a исторически разрешительной среды к более ограничительной. Нововведение может вызвать проблемы,
more restrictive one. The new behavior may cause issues if you depend on если вы применяете долго работающие программы (такие как, <command>screen</command> или
long running programs (e.g., <command>screen</command> or <command>tmux</command>), чтобы оставаться активным после завершения вашей пользовательской сессии.
<command>tmux</command>) to remain active after ending your user session. Есть три способа разрешить процессам работать после того, как сеанс пользователя завершен.</para>
There are three ways to enable lingering processes to remain after a user
session is ended.</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
<emphasis>Enable process lingering for only selected users</emphasis>: <emphasis>Включить долгосрочные процессы для выбранных пользователей</emphasis>:
Normal users have permission to enable process lingering Обычные пользователи имеют разрешение на включение долгосрочных процессов с помощью
with the command <command>loginctl enable-linger</command> for their команды <command>loginctl enable-linger</command> для самих себя. Системные администраторы
own user. System administrators can use the same command with a могут использовать ту же команду с аргументом <parameter>user</parameter> для включения
<parameter>user</parameter> argument to enable for a user. That user lingering'а пользователю. После этого пользователь может использовать команду
can then use the <command>systemd-run</command> command to start <command>systemd-run</command>, чтобы запустить длительный процесс. Например: <command>systemd-run --scope
long running processes. For example: <command>systemd-run --scope --user /usr/bin/screen</command>. Если вы разрешите выполнение долгосрочных процессов
--user /usr/bin/screen</command>. If you enable lingering for your пользователю, то user@.service останется даже после завершения всех сеансов входа в
user, the user@.service will remain even after all login sessions are систему и автоматически запустится при загрузке системы. Это является преимуществом, потому
closed, and will automatically start at system boot. This has the что явно разрешает и запрещает запуск процессов после завершения сеанса пользователя, но
advantage of explicitly allowing and disallowing processes to run нарушает обратную совместимость с такими инструментами, как <command>nohup</command> и
after the user session has ended, but breaks backwards compatibility утилитами, которые используют <function>daemon()</function>.
with tools like <command>nohup</command> and utilities that use
<function>daemon()</function>.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
<emphasis>Enable system-wide process lingering</emphasis>: <emphasis>Включенить долгосрочные процессы в системе(глобально)</emphasis>:
You can set <parameter>KillUserProcesses=no</parameter> in Вы можете установить <parameter>KillUserProcesses=no</parameter> в
<filename>/etc/systemd/logind.conf</filename> to enable process lingering <filename>/etc/systemd/logind.conf</filename> для включения лолгосрочных процессов
globally for all users. This has the benefit of leaving the old глобально для всех пользователей. Преимуществом этого метода является то, что
method available to all users at the expense of explicit control. вы оставляете старый метод доступным всем пользователям за счет явного контроля.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
<emphasis>Disable at build-time</emphasis>: You can disable <emphasis>Отключить во время сборки</emphasis>: вы можете запретить завершение процессов
lingering by default while building systemd by adding the switch при сборке systemd, добавив ключ <parameter>-Ddefault-kill-user-processes=false</parameter>
<parameter>-Ddefault-kill-user-processes=false</parameter> to the в команде <command>meson</command> для systemd. Это полностью отключает возможность systemd
<command>meson</command> command for systemd. This completely убивать пользовательские процессы во время сеанса.
disables the ability of systemd to kill user processes at session
end.
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>

View File

@ -11,13 +11,13 @@
<title>Целевые архитектуры LFS</title> <title>Целевые архитектуры LFS</title>
<para>Основными целевыми архитектурами LFS являются процессоры AMD/Intel x86 <para>Основными целевыми архитектурами LFS являются процессоры AMD/Intel x86
(32-разрядные) и x86_64 (64-разрядные). С другой стороны, известно, что (32-разрядные) и x86_64 (64-разрядные). Однако, известно, что
инструкции в этой книге с некоторыми изменениями работают с процессорами инструкции, приведенные в этой книге, с некоторыми изменениями работают с процессорами
Power PC и ARM. Для создания системы, использующей один из этих процессоров, Power PC и ARM. Для создания системы, использующей один из этих процессоров,
основным предварительным условием, в дополнение к указанным на следующей основным предварительным условием, в дополнение к описанным на следующей
странице, является существующая система Linux, такая как более ранняя странице, является существующая система Linux, например, собранная ранее LFS,
установка LFS, Ubuntu, Red Hat/Fedora, SuSE или другой дистрибутив, Ubuntu, Red Hat/Fedora, SuSE или другой дистрибутив,
который нацелен на требуемую архитектуру. Также обратите внимание, что ориентированный на имеющуюся у вас архитектуру. Также обратите внимание, что
32-разрядный дистрибутив можно установить и использовать в качестве 32-разрядный дистрибутив можно установить и использовать в качестве
хост-системы на 64-разрядном компьютере AMD/Intel.</para> хост-системы на 64-разрядном компьютере AMD/Intel.</para>
@ -46,6 +46,6 @@ LAMP-сервера или брандмауэра, 32-разрядной сбо
для сборки базовой системы. Некоторые редакторы LFS/BLFS поддерживают для сборки базовой системы. Некоторые редакторы LFS/BLFS поддерживают
ответвление LFS для мультибиблиотек, которое доступно по адресу <ulink ответвление LFS для мультибиблиотек, которое доступно по адресу <ulink
url="https://www.linuxfromscratch.org/~thomas/multilib/index.html"/>. Но это url="https://www.linuxfromscratch.org/~thomas/multilib/index.html"/>. Но это
продвинутая тема.</para> более продвинутая тема.</para>
</sect1> </sect1>