Gentoo Linux Handbook: Работа с Gentoo

Добро пожаловать в Portage

Система Portage — вероятно, самое известное нововведение Gentoo в управлении программным обеспечением. Благодаря высокой гибкости и чрезвычайно богатым возможностям, она зачастую считается лучшим средством управления программным обеспечением из существующих в Linux.

Portage полностью написан на Python и Bash и, следовательно, полностью прозрачен для пользователей, поскольку это скриптовые языки.

Большинство пользователей взаимодействует с Portage с помощью команды emerge. Эта глава не будет дублировать информацию, доступную в emerge man странице. Для полного обзора опций emerge, пожалуйста, обратитесь к странице man:

user $man emerge

Репозиторий Gentoo

Ebuilds

Когда в документации Gentoo говорится о пакетах имеется ввиду программы, которые доступны Gentoo пользователям в Gentoo репозитории. Репозиторий это коллекция ebuild (сборочных файлов) - файлы содержащие всю информацию, которая нужна Portage для управления программным обеспечением (установка, поиск, запросы и так далее). По умолчанию файлы ebuild находятся в .

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

Обновление Gentoo репозитория

Gentoo репозиторий обычно обновляется с помощью rsync, средства быстрой разностной передачи файлов. Обновление выполняется довольно просто, так как в emerge имеется интерфейс для rsync:

root #emerge --sync

Иногда правила файрвола ограничивают rsync в доступе к зеркалу. В этом случае репозиторий Gentoo можно обновлять с помощью ежедневно генерируемых Gentoo снимков. Утилита emerge-webrsync автоматически загрузит и установит последний снимок в систему:

root #emerge-webrsync

Управление программным обеспечением

Поиск программного обеспечения

Есть несколько способов поиска программ в Gentoo репозитории. Один из способов использовать emerge. По умолчанию emerge --search находит имена пакетов, которые совпадают (полностью или частично) с заданным условием поиска.

Например, чтобы найти все пакеты, содержащие «pdf» в названии:

user $emerge --search pdf

Для поиска пакетов еще и по тексту описания используйте опцию --searchdesc (или -S):

user $emerge --searchdesc pdf

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

CODE Пример вывода команды поиска

*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Установка программы

Когда программное обеспечение было найдено, его легко можно установить командой emerge. Например, для установки gnumeric:

root #emerge --ask app-office/gnumeric

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

root #emerge --pretend gnumeric

To do the same, but interactively choose whether or not to proceed with the installation, add the --ask flag:

root #emerge --ask gnumeric

Во время установки пакета, Portage скачает необходимый исходный код из интернета (если необходимо) и по умолчанию сохранит его в /var/cache/distfiles/. После этого он распакует, скомпилирует и установить пакет. Для того чтобы Portage только загрузил исходный код без его установки, добавьте опцию --fetchonly к команде emerge:

root #emerge --fetchonly gnumeric

Поиск документации для установленных пакетов

Многие пакеты поставляются с собственной документацией. Иногда, USE-флаг doc определяет будет ли установлена документация из пакета или нет. Чтобы увидеть есть ли USE-флаг doc в пакете используйте emerge -vp category/package:

root #emerge -vp media-libs/alsa-lib

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild   R    ] media-libs/alsa-lib-1.1.3::gentoo  USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB

Лучший способ настроить doc USE-флаг это настроить его для каждого пакета с помощью /etc/portage/package.use, так документация будет устанавливаться только для требуемых пакетов. Для большего количества информации, прочитайте раздел USE-флаги.

После установки пакета, его документацию, как правило, можно найти в подкаталоге с именем пакета в каталоге /usr/share/doc/:

user $ls -l /usr/share/doc/alsa-lib-1.1.3

total 16
-rw-r--r-- 1 root root 3098 Mar  9 15:36 asoundrc.txt.bz2
-rw-r--r-- 1 root root  672 Mar  9 15:36 ChangeLog.bz2
-rw-r--r-- 1 root root 1083 Mar  9 15:36 NOTES.bz2
-rw-r--r-- 1 root root  220 Mar  9 15:36 TODO.bz2

Более точный способ посмотреть список установленных файлов с документаций это воспользоваться equery с параметром --filter. equery используется для запросов к базе данных Portage и поставляется как часть пакета app-portage/gentoolkit:

user $equery files --filter=doc alsa-lib

 * Searching for alsa-lib in media-libs ...
 * Contents of media-libs/alsa-lib-1.1.3:
/usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2
/usr/share/doc/alsa-lib-1.1.3/NOTES.bz2
/usr/share/doc/alsa-lib-1.1.3/TODO.bz2
/usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2

Параметр --filter можно использовать с другими параметрами, чтобы увидеть место установки множества других типов файлов. Дополнительную информацию можно посмотреть в man-странице equery: man 1 equery.

Удаление программы

Чтобы безопасно удалить пакета из системы, используйте emerge --deselect. Эта команда скажет Portage, что этот пакет теперь не нужен, и его можно удалить во время очистки с помощью --depclean.

root #emerge --deselect gnumeric

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

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

Чтобы сохранить систему в отличной форме (не говоря уже об установке последних обновлений безопасности) необходимо регулярно обновлять систему. Так как Portage проверяет сборочные файлы только в локальном Gentoo репозитория, поэтому сперва нужно обновить репозиторий. После обновления Gentoo репозитория можно обновить систему с помощью emerge --sync. Затем система может быть обновлена с помощью emerge --deep --update @world.

Portage будет искать более новые версии для установленных приложений. Однако, будут проверятся только явно установленные (приложения, перечисленные в /var/lib/portage/world), но не будут тщательно проверятся их зависимости. Чтобы обновить зависимости этих пакетов тоже, добавьте опцию --deep:

root #emerge --update --deep @world

Когда настройки USE в системе были изменены, то рекомендуется также добавить --newuse. В этом случаи Portage проверит требуется ли после этих изменений установить новые пакеты или перекомпилировать существующие:

root #emerge --update --deep --newuse @world

Метапакеты

У некоторых пакетов в Gentoo репозитории нет содержимого, но они используются для установки набора других пакетов. Например, kde-plasma/plasma-meta установит KDE Plasma desktop в систему, устанавливая в качестве зависимостей различные пакеты, которые нужны Plasma.

Удаление такого пакета из системы, запуская emerge --deselect пакет, не принесет должного эффекта, так как его зависимости останутся в системе.

Portage также имеет функциональность для удаления ненужных зависимостей, но поскольку доступное программное обеспечение динамически зависит друг от друга, важно сначала обновить всю систему полностью, в том числе и новые изменения, получившихся из-за изменения USE-флагов. После этого можно запустить emerge --depclean для удаления ненужных зависимостей. Когда это будет сделано, возможно будет необходимо пересобрать приложения, которые раньше были динамически связанны с удаленным теперь программами и теперь больше не нуждаются в них, в последнее время поддержка этого была добавлена Portage.

Все это можно сделать следующими двумя командами:

root #emerge --update --deep --newuse @world

root #emerge --ask --depclean

Лицензии

Начиная с версии Portage 2.1.7 можно принять или отклонить установку программного обеспечения основываясь на лицензии. Все пакеты в дереве содержат запись LICENSE в ebuild. Запуск emerge --search category/package покажет лицензию пакета.

Important
Переменная LICENSE в ebuild является только ориентиром для разработчиков и пользователей Gentoo. Она не является юридически значимым заявлением и не гарантирует, что условия использования соответствуют действительности. Не стоит доверять ей безоговорочно и при необходимости следует проводить полный аудит всех файлов используемого пакета самостоятельно.

If a discrepancy is found in the ebuild, please file a bug to suggest a change to the value(s) assigned to the ebuild's LICENSE variable.}}

По умолчанию, Portage позволяет все лицензии, явным образом одобренные Фондом Свободного Программного Обеспечения (FSF), Инициативой Открытых Исходных Кодов (OSI) или соответствующие Определению Свободного Программного Обеспечения.

Переменная, которая контролирует допустимые лицензии называется ACCEPT_LICENSE. Ее можно настроить в файле /etc/portage/make.conf. В следующем примере показано значение по умолчанию:

FILE /etc/portage/make.confНастройка по умолчанию для ACCEPT_LICENSE

ACCEPT_LICENSE="-* @FREE"

При такой конфигурации пакеты, имеющие свободную лицензию ПО или документации, могут быть установлены. Несвободное ПО не сможет быть установлено.

Можно настроить ACCEPT_LICENSE глобально в файле /etc/portage/make.conf или специально для отдельного пакета в файле /etc/portage/package.license.

Например, чтобы разрешить google-chrome лицензию для пакета www-client/google-chrome добавьте следующее в /etc/portage/package.license:

FILE /etc/portage/package.licenseРазрешение лицензии google-chrome для пакета google-chrome

www-client/google-chrome google-chrome

Это разрешит установку пакета www-client/google-chrome, но не позволит устанавливать пакет www-plugins/chrome-binary-plugins, хотя он имеет туже лицензию.

Or to allow the often-needed sys-kernel/linux-firmware:

FILE /etc/portage/package.licenseAccepting the licenses for the linux-firmware package

# Accepting the license for linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Accepting any license that permits redistribution
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

Important
Сами лицензии хранятся в каталоге /licenses/, а лицензионные группы — в файле /profiles/license_groups. Первая запись в каждой строке, записанная ЗАГЛАВНЫМИ буквами — это название группы лицензий, остальные записи после неё — индивидуальные лицензии.

Группа лицензий в переменной ACCEPT_LICENSE указываются с символом @ перед ней. Возможной настройкой (которая является значением по умолчанию в Gentoo) является разрешение всех лицензий, кроме Соглашений с лицензией конечного пользователя (EULA), которые обычно требуют прочтения и подписания соглашения о принятии условий лицензии. Это можно достичь, приняв все лицензии (через *), после чего удалив лицензии из группы EULA, как указано ниже:

FILE /etc/portage/make.confПозволять все лицензии за исключением EULA

ACCEPT_LICENSE="* -@EULA"

Обратите внимание что такая настройка разрешит несвободное программное обеспечение и документацию.

Когда Portage на что-то ругается

Терминология

Как отмечалось ранее, Portage поддерживает многие возможности и является чрезвычайно мощным инструментом, как и другие инструменты управления программами. Чтобы понять это, разберём несколько аспектов Portage, не вдаваясь в детали.

С помощью Portage разные версии отдельного пакета могут сосуществовать в одной системе. В то время, как другие системы управления стремятся называть пакеты в соответствии с версией (например gtk+2 и gtk+3), Portage использует технологию под названием SLOT. Ebuild присваивает определенный SLOT для одной версии пакета. Ebuild с разными SLOT способны сосуществовать в одной системе. Например, пакет gtk+ имеет разные ebuild для SLOT="2" и SLOT="3".

Есть также пакеты, которые обеспечивают ту же функциональность, но реализуются по-разному. Например, metalogd, sysklogd и syslog-ng это все системные службы журналирования. Приложения, которым нужен «системный журнал», не могут зависеть только от metalogd, так как остальные программы журналирования могут быть равнозначны. В Portage предусмотрены виртуальные пакеты: каждая служба журналирования описана в нем как «эксклюзивная» зависимость от службы журналирования в виртуальном пакете журналирования виртуальной категории, поэтому остальные приложения могут зависеть от пакета virtual/logger. Если ещё не была установлена служба журналирования, то при установке виртуальный пакет «вытянет» первый из указанных в нём пакет журналирования. Если любой пакет журналирования уже был установлен, то в этом случае виртуальная зависимость считается удовлетворенной.

Программное обеспечение в репозитории Gentoo может располагаться в различных ветвях. По умолчанию система устанавливает только пакеты, которые в Gentoo считаются стабильными. Многие программы при обновлении будут добавлены в тестовую ветвь, что означает, что пакет должен быть протестирован до того, как будет отмечен стабильным. Несмотря на то, что ebuild для таких программ есть в репозитории Gentoo, Portage не будет обновлять их до тех пор, пока они не будут помещены в стабильную ветвь.

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

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

Заблокированные пакеты

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

[ebuild  N     ] x11-wm/i3-4.20.1  USE="-doc -test"
[blocks B      ] x11-wm/i3 ("x11-wm/i3" is soft blocking x11-wm/i3-gaps-4.20.1)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
    x11-wm/i3

  (x11-wm/i3-gaps-4.20.1-1:0/0::gentoo, installed) pulled in by
    x11-wm/i3-gaps required by @selected

В файлах ebuild есть специальные поля, сообщающие Portage о зависимостях. Есть две возможные зависимости: сборочные зависимости, объявленные в переменной DEPEND и зависимости выполнения, объявленные в RDEPEND. Когда одна из этих зависимостей явно указывает на несовместимый обычный или виртуальный пакет, это вызывает блокировку.

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

Чтобы исправить блокировку, пользователи могут либо не устанавливать пакет, либо удалить конфликтующий пакет. В данном примере, можно отказаться от установки postfix или сперва удалить ssmtp.

Иногда бывает также, что блокируются пакеты с конкретными версиями, например <media-video/mplayer-1.0_rc1-r2. В этом случае, обновление блокирующего пакета до более новой версии может устранить блокировку.

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

Замаскированные пакеты

CODE Portage предупреждает о замаскированных пакетах

!!! all ebuilds that could satisfy "bootsplash" have been masked.

CODE Portage предупреждает о замаскированных пакетах - причина

!!! possible candidates are:
  
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

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

Причина маскировки	Описание
~arch keyword	Приложение не достаточно протестировано, чтобы его можно было поместить в стабильную ветвь. Подождите несколько дней или недель и попробуйте снова.
-arch keyword или -* keyword	Приложение не работает на вашей архитектуре. Если вы считаете, что оно должно работать, сообщите об ошибке на нашем сайте Bugzilla.
missing keyword	Приложение не было протестировано на вашей архитектуре. Попросите группу портирования для вашей архитектуры проверить пакет, или протестируйте его за них и представьте результат на нашем сайте Bugzilla.
package.mask	В пакете было обнаружена ошибка, нестабильность или еще хуже, и поэтому он был намеренно отмечен как пакет не-для-использования.
profile	Пакет не подходит для текущего профиля. Приложение может сломать систему при установке или просто несовместимо с профилем на данный момент.
license	Лицензия пакета не совместима со значением из ACCEPT_LICENSE. Разрешите эту лицензию или необходимую лицензионную группу, настроив их в /etc/portage/make.conf или /etc/portage/package.license.

Необходимо изменить USE-флаг

CODE Portage предупреждает о необходимости изменить USE-флаг

The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

Сообщение об ошибке может отображаться и так, если --autounmask не установлен:

CODE Ошибка Portage о необходимости изменить USE-флаг

emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Такое предупреждение или ошибка происходят, когда пакет, который требуется установить, зависит не только от другого пакета, но также требует, чтобы этот пакет был скомпилирован с особым USE-флагом (или набором USE-флагов). В данном примере, пакет app-text/feelings должен быть скомпилирован с USE="test", но этот USE-флаг не задан в системе.

Чтобы исправить это, добавьте нужный USE-флаг к глобальным USE-флагам в файле /etc/portage/make.conf или добавьте его для отдельного пакета в файле /etc/portage/package.use.

Отсутствующие зависимости

CODE Portage предупреждает об отсутствующей зависимости

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
  
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.

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

Неоднозначное имя ebuild

CODE Portage предупреждает о неоднозначном имени ebuild

[ Results for search key : listen ]
[ Applications found : 2 ]
  
*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD
  
*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2
  
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

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

Циклические зависимости

CODE Portage предупреждает о циклической зависимости

!!! Error: circular dependencies: 
  
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

Два (или более) пакетов для установки зависят друг от друга и поэтому не могут быть установлены. Это, скорее всего, ошибка в одном из пакетов в репозитории Gentoo. Повторите синхронизацию через некоторое время и попробуйте снова. Также может быть полезным проверить известна ли проблема в Bugzilla, и если нет, сообщите о ней.

Ошибка загрузки

CODE Portage предупреждает об ошибки загрузки

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

Portage не смог загрузить исходный код для данного приложения и попытается продолжить установку других приложений (если это возможно). Эта ошибка может быть из-за неправильно синхронизированного зеркала или, возможно, ebuild указывает на неверное место. Также сервер, где находятся исходные коды, может временно недоступен.

Повторите действие через час, чтобы проверить, повторяется ли еще ошибка.

Защита системного профиля

CODE Portage предупреждает о пакете, который защищен профилем

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

Пользователь попросил удалить пакет, входящий в состав базовых пакетов системы. Он записан в профиле, как необходимый, и поэтому его не надо удалять из системы.

Ошибка проверки контрольных сумм

CODE Ошибка проверки контрольных сумм

>>> checking ebuild checksums
!!! Digest verification failed:

Это признак того, что что-то не так в репозитории Gentoo — часто, возникает из-за того, что сделана ошибка при изменении пакета в репозитории Gentoo.

Когда проверка контрольных сумм завершается ошибкой, не пытайтесь обновить их пакета лично. Запуск ebuild foo manifest не решит проблему; ситуация может ухудшиться.

Вместо этого, подождите час или два, пока репозиторий обновится. Вполне вероятно, что ошибка была замечена сразу, но может пройти некоторое время, пока исправление дойдёт до зеркал. Проверьте Bugzilla, возможно кто-то сообщил о том, что проблема существует или поспрашивайте на #gentoo (webchat) (IRC). Если нет, то создайте ошибку о сломанном ebuild.

После того, как ошибка была исправлена, повторно синхронизируйте репозиторий Gentoo, чтобы загрузить исправленные контрольные суммы.

Important
Не нужно синхронизировать Gentoo репозиторий ebuild-файлов чаще чем раз в день. Как указано в официальной политике сетевого этикета (при выполнении emerge --sync), пользователям, которые синхронизируются слишком часто, временно может быть запрещена синхронизация. Нарушители, которые неоднократно нарушают эту политику, могут быть заблокированы на долгое время. Если нет критической необходимости, лучше просто подождать 24 часа, так повторная синхронизация не будет перегружать rsync-зеркала Gentoo.

← Завершение К содержанию USE-флаги →

Что такое USE-флаги

Идея USE-флагов

При установке Gentoo пользователи делают выбор в зависимости от среды, в которой они работают. Настройка для сервера отличается от настройки для рабочего места. Система для игр отличается от системы для 3D-рендеринга.

Это касается не только того, какие пакеты необходимо устанавливать, но и какие возможности в определённых пакетах должны поддерживаться. Если нет необходимости в OpenGL, то зачем устанавливать OpenGL и обеспечивать его поддержку в других пакетах? Если не планируется использовать KDE, зачем утруждать себя сборкой пакетов с поддержкой KDE, если они могут работать и без неё?

Чтобы помочь в решении, что устанавливать/активировать, а что нет, Gentoo предоставляет пользователю простой способ в описании его окружения. Он даёт пользователю выбор, что ему действительно нужно, а также облегчает работу с Portage для принятия более верных решений.

Определение USE-флага

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

Рассмотрим конкретный пример: USE-флаг kde. Если такого флага нет в переменной USE (или он указан со знаком минуса в начале: -kde), все пакеты, у которых поддержка KDE является необязательной, будут скомпилированы без поддержки KDE. Все пакеты, у которых зависимость от KDE необязательна, будут установлены без установки библиотек KDE (в качестве зависимости).

Если флаг kde определён, тогда эти пакеты будут скомпилированы с поддержкой KDE, а библиотеки KDE будут установлены в виде зависимостей.

При помощи правильного определения USE-флагов система может быть адаптирована под потребности системного администратора.

Использование USE-флагов

Объявление постоянных USE-флагов

Все USE-флаги объявляются в переменной USE. Чтобы облегчить для пользователей поиск и выбор USE-флагов, мы устанавливаем переменную USE в некоторое значение по умолчанию. Это значение определяет коллекцию USE-флагов, которые, по нашему мнению, наиболее часто используются пользователями Gentoo. Эти настройки по умолчанию объявлены в файлах make.defaults, являющиеся частью выбранного профиля.

Профиль, на который определена система, читается из символической ссылки /etc/portage/make.profile. Каждый профиль работает поверх других профилей, поэтому конечный результат в итоге будет суммой всех профилей. В основе всех профилей базовый профиль (/profiles/base).

Для просмотра действующих на данный момент USE-флагов (всех) используйте emerge --info:

root #emerge --info | grep ^USE

USE="a52 aac acpi alsa branding cairo cdr dbus dts ..."

Эта переменная уже содержит достаточно много ключевых слов. Не меняйте файлы make.defaults, чтобы подстроить переменную USE под свои нужды: изменения в этих файлах будут отменены при следующем обновлении репозитория Gentoo!

Чтобы изменить настройки по умолчанию, добавьте или удалите ключевые слова в переменной USE. Это можно сделать глобально, определяя переменную USE в файле /etc/portage/make.conf. В этой переменной можно добавлять нужные или удалять ненужные USE-флаги. Для удаления необходимо указать перед ключевым словом префикс в виде знака «минус» (-).

Например, для отключения поддержки KDE и Qt и включения поддержки LDAP в /etc/portage/make.conf следует указать следующие USE-флаги:

FILE /etc/portage/make.confИзменение USE-флагов в make.conf

USE="-kde -qt5 ldap"

Объявление USE-флагов для отдельных пакетов

Иногда необходимо определить некий USE-флаг для одного или нескольких приложений, но не для всей системы. Для этого отредактируйте /etc/portage/package.use. Как правило, package.use — это один файл, но может быть и каталогом; смотрите совет ниже и man 5 portage для более подробной информации. Следующий пример подразумевает, что package.use — это один файл.

Например, чтобы включить поддержку Blu-ray только в пакете VLC:

FILE /etc/portage/package.useВключение поддержки Blu-ray в VLC

media-video/vlc bluray

Tip
Если package.use существует в виде каталога (а не одного файла), локальные USE-флаги для конкретного пакета могут определены путём простого создания файла в каталоге package.use/. Подойдёт любое имя файла, однако рекомендуется придерживаться определённой схемы. Одной из таких схем является использование имени пакета в качестве названия файла. Например, указание USE-флага bluray для пакета media-video/vlc может определено следующим образом:

root #echo "media-video/vlc bluray" >> /etc/portage/package.use/vlc

Аналогичным образом можно запретить использование USE-флагов для определённого приложения. Например, чтобы отключить поддержку bzip2 в PHP (но оставить такую поддержку для всех остальных пакетов через определение USE-флага в файле make.conf):

FILE /etc/portage/package.useОтключение поддержки bzip2 в PHP

dev-lang/php -bzip2

Объявление временных USE-флагов

Иногда нужно установить USE-флаг на короткое время. Вместо двойного редактирования файла /etc/portage/make.conf (сначала сделать изменение в переменной USE, а потом его отменить), просто определите переменную USE как переменную окружения. Запомните, что эти настройки будут применены только к введённой команде; пересборка или обновление этого приложения (в явном виде или при обновлении системы) отменят изменения, сделанные с помощью временного определения USE-флага.

Следующий пример временно удаляет pulseaudio из переменной USE во время установки SeaMonkey:

root #USE="-pulseaudio" emerge www-client/seamonkey

Приоритет

Конечно, есть приоритет в том, какие настройки будут преобладать над другими настройками USE. Последовательность для настроек USE, отсортированная по приоритету (сперва меньший приоритет):

1. Настройки USE по умолчанию объявляются в файле make.defaults из выбранного профиля
2. Определённые пользователем настройки USE в файле /etc/portage/make.conf
3. Определённые пользователем настройки USE в файле /etc/portage/package.use
4. Определённые пользователем настройки USE в виде переменной окружения.

Чтобы отобразить финальные настройки, как их видит Portage, выполните emerge --info. Эта команда отобразит список соответствующих переменных (включая переменные USE) с их текущими значениями, как их видит Portage.

root #emerge --info

Адаптация всей системы под новые USE-флаги

После изменений USE-флагов система должна быть обновлена, чтобы изменения вступили в силу. Чтобы сделать это, используйте параметр --newuse для emerge:

root #emerge --update --deep --newuse @world

Далее, запустите очистку зависимостей Portage (depclean), чтобы удалить зависимости, которые были необходимы в «старой» системе, но теперь, с новыми USE-флагами, устарели.

Important
Дважды проверьте предоставленный список «устаревших» (obsoleted) пакетов, чтобы убедиться, что не будут удалены нужные пакеты. В следующем примере мы добавили --pretend (-p), чтобы просто отобразить пакеты без их удаления:

root #emerge --pretend --depclean

После завершения работы depclean emerge может предложить пересобрать приложения, которые динамически связаны с общими объектами, удалёнными вместе с устаревшими пакетами. Portage сохранит необходимые библиотеки до тех пор, пока не будет выполнено это действие, чтобы не допустить нарушение работы приложений. Portage хранит список необходимых для пересборки пакетов в наборе preserved-rebuild. Чтобы выполнить пересборку пакетов, запустите:

root #emerge @preserved-rebuild

После того, как эта команда будет завершена, систему можно считать настроенной в соответствии с новыми USE-флагами.

USE-флаги, специфичные для пакета

Просмотр доступных USE-флагов

Возьмём для примера seamonkey: какие USE-флаги он поддерживает? Чтобы получить ответ на этот вопрос, воспользуемся emerge с параметрами --pretend и --verbose:

root #emerge --pretend --verbose www-client/seamonkey

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild  N     ] www-client/seamonkey-2.48_beta1::gentoo  USE="calendar chatzilla crypt dbus gmp-autoupdate ipc jemalloc pulseaudio roaming skia startup-notification -custom-cflags -custom-optimization -debug -gtk3 -jack -minimal (-neon) (-selinux) (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite {-test} -wifi" L10N="-ca -cs -de -en-GB -es-AR -es-ES -fi -fr -gl -hu -it -ja -lt -nb -nl -pl -pt-PT -ru -sk -sv -tr -uk -zh-CN -zh-TW" 216,860 KiB
 
Total: 1 package (1 new), Size of downloads: 216,860 KiB

emerge — не единственная утилита, которую можно использовать для этой задачи. Есть специальная утилита для получения информации о пакете под названием equery из пакета app-portage/gentoolkit.

root #emerge --ask app-portage/gentoolkit

Теперь запустите equery с аргументом uses для получения списка USE-флагов для определённого пакета. Например, для пакета app-portage/portage-utils:

user $equery --nocolor uses =app-portage/portage-utils-0.93.3

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-portage/portage-utils-0.93.3:
 U I
 + + nls       : Add Native Language Support (using gettext - GNU locale utilities)
 + + openmp    : Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE="openmp"
 + + qmanifest : Build qmanifest applet, this adds additional dependencies for GPG, OpenSSL and BLAKE2B hashing
 + + qtegrity  : Build qtegrity applet, this adds additional dependencies for OpenSSL
 - - static    : !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically

Удовлетворение условий REQUIRED_USE

Некоторые пакеты требуют или запрещают определённые комбинации USE-флагов для своей корректной работы. Это выражается через совокупность условий, которые помещены в выражении REQUIRED_USE. Такие условия гарантируют, что все функции и зависимости удовлетворены и сборка будет выполнена корректно и правильно. Если какое-либо из условий не выполняется, emerge предупредит вас об этом и попросит исправить эту проблему.

Пример	Описание
REQUIRED_USE="foo? ( bar )"	Если foo установлен, то bar должен быть тоже установлен.
REQUIRED_USE="foo? ( !bar )"	Если foo установлен, то bar не должен быть установлен.
REQUIRED_USE="foo? ( || ( bar baz ) )"	Если foo установлен, то bar или baz должен быть установлен.
REQUIRED_USE="^^ ( foo bar baz )"	Только один из foo, bar или baz должен быть установлен.
REQUIRED_USE="|| ( foo bar baz )"	Хотя бы один из foo bar или baz должен быть установлен (но можно больше).
REQUIRED_USE="?? ( foo bar baz )"	Установка необязательна, но только один из foo bar или baz может быть установлен.

← Введение в Portage К содержанию Возможности Portage →

Возможности Portage

В Portage есть несколько дополнительных возможностей (features), которые улучшат опыт работы с Gentoo. Многие из этих возможностей полагаются на определённые программы, которые улучшают производительность, надёжность, безопасность и так далее.

Чтобы включить или отключить определённые возможности Portage, отредактируйте /etc/portage/make.conf и измените или установите переменную FEATURES, которая содержит ключевые слова возможностей, разделённые пробелом. В некоторых случаях необходимо установить дополнительные утилиты, на которые опирается эта возможность.

Не все возможности, которые поддерживает Portage, перечислены здесь. Для полного обзора, пожалуйста, обратитесь к man-странице make.conf:

user $man make.conf

Чтобы найти, что на данный момент установлено в FEATURES, запустите emerge --info и поищите переменную FEATURES или отфильтруйте её с помощью grep:

user $emerge --info | grep ^FEATURES=

Распределённая сборка

Использование distcc

distcc — это программа для распределённой сборки по нескольким, не обязательно идентичным, машинам в сети. Клиент distcc посылает всю необходимую информацию на доступные сервера distcc (на которых работает distccd), чтобы те скомпилировали части исходного кода для клиента. В результате получается более быстрая сборка.

Больше информации о distcc (и как он работает с Gentoo) можно найти в статье Distcc.

Установка distcc

Distcc поставляется с графическим монитором для отслеживания заданий, отправляемых компьютером на компиляцию. Данный монитор устанавливается при установленном USE="gtk".

root #emerge --ask sys-devel/distcc

Включение поддержки distcc в Portage

Добавьте distcc в переменную FEATURES в файле /etc/portage/make.conf. Далее, отредактируйте переменную MAKEOPTS и увеличьте число параллельных задач компиляции настолько, насколько это позволяет система. Рекомендуется использовать -jN, где N это число CPU, на которых будет запускаться distccd (включая локальный компьютер), плюс один. Не забывайте, что это просто рекомендация.

Теперь запустите distcc-config и введите список доступных серверов distcc. В качестве простого примера предположим, что среди доступных серверов distcc 192.168.102 (локальный компьютер), а 192.168.1.103 и 192.168.1.104 (два «удалённых» узла):

root #distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Не забудьте также запустить демон distccd:

root #rc-update add distccd default

root #/etc/init.d/distccd start

Кэширование собранных объектов

О ccache

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

Для более подробной информации о ccache, пожалуйста, посетите их домашнюю страницу.

Warning
Известно, что ccache порой вызывает ошибки компиляции. Иногда ccache сохраняет устаревшие объекты кода или поврежденные файлы, что приводит к тому, что некоторые пакеты невозможно установить после этого. Если такое происходит (ошибки вроде «File not recognized: File truncated» появляются в журнале сборки), попробуйте пересобрать приложение с отключённым ccache (FEATURES="-ccache" в /etc/portage/make.conf или единоразово, используя командную строку, как показано ниже) перед тем, как сообщить об ошибке:

root #FEATURES="-ccache" emerge --oneshot <категория/пакет>

Установка ccache

Для установки ccache запустите следующую команду:

root #emerge --ask dev-util/ccache

Включение поддержки ccache в Portage

Откройте /etc/portage/make.conf и добавьте ccache к значению, которое определено в переменной FEATURES. Создайте переменную FEATURES, если она не существует. Далее добавьте новую переменную, которая называется CCACHE_SIZE, и установите ее в 2G:

FILE /etc/portage/make.confВключение поддержки ccache в Portage

FEATURES="ccache"
CCACHE_SIZE="2G"

Чтобы проверить функциональность ccache, запросите его статистику. Поскольку Portage использует другой домашний каталог для ccache, необходимо временно установить переменную CCACHE_DIR:

root #CCACHE_DIR="/var/tmp/ccache" ccache -s

В Portage домашний каталог по умолчанию для ccache — /var/tmp/ccache/; но это можно изменить, настроив переменную CCACHE_DIR в файле /etc/portage/make.conf.

Если ccache запущен автономно (без Portage), он будет использовать каталог по умолчанию ${HOME}/.ccache/, именно поэтому необходимо указать переменную CCACHE_DIR при запросе (Portage) статистики ccache.

Использование ccache отдельно от Portage

Чтобы использовать ccache для компиляции без Portage, добавьте /usr/lib/ccache/bin/ в начало переменной PATH (до /usr/bin). Это можно сделать, отредактировав ~/.bash_profile в домашнем каталоге пользователя. Использование ~/.bash_profile — это только один из способов определения переменных PATH.

FILE ~/.bash_profileНастройка месторасположения ccache перед другими PATH

PATH="/usr/lib/ccache/bin:${PATH}"

Поддержка двоичных пакетов

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

Portage поддерживает установку двоичных пакетов.

Чтобы создать бинарный пакет, воспользуйтесь командой quickpkg, если пакет уже установлен в системе, или скомпилируйте его с параметром --buildpkg или --buildpkgonly.

Чтобы Portage создавал двоичные пакеты для каждого устанавливаемого пакета, добавьте buildpkg в переменную FEATURES.

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

Установка прекомпилированных пакетов

Хотя Gentoo не предоставляет таковые, можно создать централизованный репозиторий двоичных пакетов. Для того, чтобы использовать такой репозиторий, нужно сообщить Portage об этом с помощью переменной PORTAGE_BINHOST, которая указывает на такое хранилище. Например, если бинарные пакеты находятся по адресу ftp://buildhost/gentoo:

FILE /etc/portage/make.confДобавление расположения PORTAGE_BINHOST

PORTAGE_BINHOST="ftp://buildhost/gentoo"

Чтобы установить двоичный пакет, добавьте параметры --getbinpkg и --usepkg в команду emerge. Первая сообщает emerge, что нужно загрузить двоичный пакет из уже определённого ранее сервера, а вторая просит emerge попытаться установить двоичный пакет до загрузки исходного кода и его компиляции.

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

root #emerge --usepkg --getbinpkg gnumeric

Больше информации о двоичных пакетах в emerge можно найти в man-странице emerge:

user $man emerge

Распространение двоичных пакетов для других

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

В ebuild может быть определено ограничение bindist в переменной RESTRICT, если собранные двоичные файлы не подлежат распространению. Иногда такое ограничение обусловлено одним или несколькими USE-флагами.

По умолчанию Portage не маскирует пакеты из-за таких ограничений. Это можно изменить, глобально настроив переменную ACCEPT_RESTRICT в файле /etc/portage/make.conf. Например, чтобы замаскировать пакеты, у которых есть ограничение bindist, добавьте следующую строку в файл make.conf:

FILE /etc/portage/make.confРазрешить только пакеты, доступные для распространения в виде двоичных файлов

ACCEPT_RESTRICT="* -bindist"

Также можно переопределить переменную ACCEPT_RESTRICT, добавив параметр --accept-restrict в команду emerge. Например, --accept-restrict=-bindist временно замаскирует пакеты с ограничением bindist.

Также, в случае распространения пакетов, рекомендуется настроить переменную ACCEPT_LICENSE. Смотрите раздел Лицензии.

Important
Ответственность за соответствие условиям лицензии и соответствие законодательству страны, где предполагается распространять пакет, полностью лежит на пользователе. Переменные метаданных, определённые в ebuild (RESTRICT или LICENSE), сообщат о том, что распространение двоичных пакетов не разрешено, однако, вывод команд Portage или вопросы, на которые отвечали разработчики Gentoo не являются юридическими заявлениями; не стоит полагаться на них. Будьте внимательны при соблюдении законов своей страны.

Загрузка файлов

Проверка архивов исходных файлов

Чтобы перепроверить целостность и (возможно) повторно скачать ранее удаленные/поврежденные архивы исходных файлов (distfiles) для всех установленных пакетов, выполните:

root #emerge --ask --fetchonly --emptytree @world

← USE-флаги К содержанию Система init-скриптов →

Important
The contents of this page do not apply to users that chose a systemd profile in Choosing the right profile.

Уровни запуска

Процесс загрузки системы

Когда загружается система по экрану пробегает много текста. Если присмотреться, заметно, что этот текст (обычно) не меняется от загрузки к загрузке. Последовательность всех этих действий называется последовательностью загрузки и в той или иной степени постоянна.

Во-первых, загрузчик размещает в памяти образ ядра, который указан в файле его конфигурации. После этого загрузчик просит процессор запустить ядро. Когда ядро загружено и запущено, оно инициализирует относящиеся к ядру структуры и задания и запускает процесс init.

Этот процесс удостоверяется, что все файловые системы (определённые в /etc/fstab) смонтированы и готовы к использованию. Затем он выполняет несколько сценариев, находящихся в каталоге /etc/init.d/ и запускающих службы, необходимые для успешного запуска системы.

И, наконец, когда все сценарии выполнены, init подключает терминалы (чаще всего просто виртуальные консоли, которые видны при нажатии Alt+F1, Alt+F2 и так далее), прикрепляя к каждой консоли специальный процесс под названием agetty. Этот процесс впоследствии обеспечивает возможность входа в систему через эти терминалы с помощью login.

Сценарии инициализации

Процесс init запускает сценарии из каталога /etc/init.d/ не просто в случайном порядке. Более того, запускаются не все сценарии из /etc/init.d/, а только те, которые предписано исполнять. Решение о запуске сценария принимается в результате просмотра каталога /etc/runlevels/.

Во-первых, init запускает все сценарии из /etc/init.d/, на которые есть символьные ссылки из /etc/runlevels/boot/. Обычно сценарии запускаются в алфавитном порядке, но в некоторых из них имеется информация о зависимостях от других, указывающая системе на необходимость их предварительного запуска.

Когда все сценарии, указанные в /etc/runlevels/boot/, будут выполнены, init переходит к запуску сценариев, на которые есть символьные ссылки из /etc/runlevels/default/. И снова запуск происходит в алфавитном порядке, пока в сценарии не встретится информация о зависимостях; тогда порядок изменяется для обеспечения правильного порядка запуска. Именно по данной причине команды, используемые во время установки Gentoo Linux, используют default, как в команде rc-update add sshd default.

Как работает init

Конечно, init не принимает решений сам по себе. Ему необходим конфигурационный файл, где описаны необходимые действия. Этот файл — /etc/inittab.

Вспомните последовательность загрузки, описанную чуть ранее: первое действие init — это монтирование всех файловых систем. Это определяется в следующей строке файла /etc/inittab:

FILE /etc/inittabСтрока инициализации

si::sysinit:/sbin/openrc sysinit

Этой строкой процессу init предписывается выполнить /sbin/openrc sysinit для инициализации системы. Самой инициализацией занимается сценарий /sbin/openrc, так что можно сказать, что init делает не слишком много — он просто делегирует задачу по инициализации системы другому процессу.

Во-вторых, init выполняет все сценарии, на которые есть символьные ссылки из /etc/runlevels/boot/. Это определяется следующей строкой:

FILE /etc/inittabВыполнение загрузочных команд

rc::bootwait:/sbin/openrc boot

И снова все необходимые действия выполняются сценарием OpenRC. Заметьте, что параметр, переданный OpenRC (boot), совпадает с названием используемого подкаталога в /etc/runlevels/.

Теперь init проверяет свой конфигурационный файл, чтобы определить, какой уровень запуска нужно запустить. Для этого из /etc/inittab считывается строка:

FILE /etc/inittabВыбор уровня запуска по умолчанию

id:3:initdefault:

В приведенном примере (который подходит для подавляющего большинства пользователей Gentoo) номер уровня запуска — 3. Пользуясь этой информацией, init проверяет, что нужно выполнить для запуска уровня запуска 3:

FILE /etc/inittabОпределения уровней запуска

l0:0:wait:/sbin/openrc shutdown
l1:S1:wait:/sbin/openrc single
l2:2:wait:/sbin/openrc nonetwork
l3:3:wait:/sbin/openrc default
l4:4:wait:/sbin/openrc default
l5:5:wait:/sbin/openrc default
l6:6:wait:/sbin/openrc reboot

В строке, определяющей уровень 3, для запуска служб снова используется сценарий openrc (на этот раз с аргументом default). Опять-таки, обратите внимание, что аргумент, передаваемый openrc, совпадает с названием подкаталога из /etc/runlevels/.

По окончании работы OpenRC init принимает решение о том, какие виртуальные консоли включить и какие команды выполнить в каждой из них:

FILE /etc/inittabОпределение виртуальных консолей

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Доступные уровни запуска

В предыдущем разделе мы увидели, что init применяет нумерацию для определения уровня запуска, который надо использовать. Уровень запуска — это то состояние, в котором запущена система, он содержит набор сценариев (сценарии уровня запуска или сценарии инициализации), которые следует выполнять, при входе и выходе из определенного уровня запуска.

В Gentoo определено семь уровней запуска: три служебных и четыре определяемых пользователем. Служебные называются sysinit, shutdown и reboot. Действия, совершаемые ими, в точности соответствуют их названиям: инициализация системы, выключение системы и её перезагрузка.

Определяемые пользователем уровни — это те, которым соответствуют подкаталоги в /etc/runlevels/: boot, default, nonetwork и single. Уровень boot запускает все службы, необходимые системе и используемые всеми остальными уровнями. Остальные уровни отличаются друг от друга запускаемыми службами: default используется для повседневной работы, nonetwork - для тех случаев, когда не требуется сеть, а single используется при необходимости восстановления системы.

Работа со сценариями инициализации

Сценарии, запускаемые процессом openrc, называются сценариями инициализации. Каждый сценарий из /etc/init.d/ может запускаться с аргументами start, stop, restart, zap, status, ineed, iuse, iwant, needsme, usesme или wantsme.

Для запуска, остановки или перезапуска службы (и всех, зависящих от неё) следует использовать start, stop и restart:

root #rc-service postfix start

Note
Останавливаются или перезапускаются только те службы, которым необходима данная служба. Остальные зависимые службы (те, которые используют службу, но не нуждаются в ней) эта операция не затрагивает.

Если вы хотите остановить службу, но оставить зависимые от неё работающими, можно использовать опцию --nodeps вместе с аргументом stop:

root #rc-service --nodeps postfix stop

Чтобы узнать текущее состояние службы (запущена, остановлена, и так далее), можно использовать аргумент status:

root #rc-service postfix status

Если указано, что служба работает, но вы знаете, что это не так, можно сбросить состояние на stopped , используя аргумент zap:

root #rc-service postfix zap

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

root #rc-service postfix ineed

Аналогично можно узнать, какие службы нуждаются в данной службе (needsme) или могут её использовать (usesme или wantsme):

root #rc-service postfix needsme

Обновление уровней запуска

rc-update

Система инициализации Gentoo использует дерево зависимостей для определения служб, которые запускаются в первую очередь. Так как это очень утомительное занятие, и мы бы не хотели, чтобы пользователь занимался этим вручную, мы разработали утилиты, упрощающие управление уровнями запуска и init-скриптами.

Используя rc-update, можно включать и исключать сценарии инициализации из уровней запуска. Из rc-update автоматически запускается сценарий depscan.sh для перестроения дерева зависимостей.

Добавление и удаление служб

В процессе установки Gentoo вы уже добавляли сценарии инициализации в уровень запуска default. Ранее в данном документе было объяснено, что означает default. Кроме уровня запуска, сценарию rc-update требуется второй аргумент, определяющий действие: add (добавить), del (удалить) или show (показать).

Для того, чтобы добавить или удалить сценарии инициализации, просто введите rc-update с аргументом add или del, затем название сценария и уровня запуска. Например:

root #rc-update del postfix default

По команде rc-update -v show выводится список всех доступных сценариев инициализации с указанием списка уровней запуска, на которых они будут выполняться:

root #rc-update -v show

Вы также можете запустить rc-update show (без -v) чтобы просто просмотреть включенные сценарии инициализации и их уровни запуска.

Настройка служб

Почему необходима дополнительная настройка

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

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

Каталог conf.d

В Gentoo предусмотрен очень простой способ настройки служб: для каждого сценария, предполагающего настройку, в каталоге /etc/conf.d/ есть конфигурационный файл. Например, у сценария, запускающего apache2 (под названием /etc/init.d/apache2) есть конфигурационный файл /etc/conf.d/apache2, где хранятся параметры, передаваемые серверу Apache 2 при запуске:

FILE /etc/conf.d/apache2Пример настроек для сценария инициализации apache2

APACHE2_OPTS="-D PHP5"

Такие конфигурационные файлы содержат только переменные (наподобие /etc/portage/make.conf), облегчая настройку служб. Это также позволяет нам давать больше информации о переменных (в комментариях).

Написание сценариев инициализации

Ещё один полезный ресурс — руководство по написанию сценариев инициализации служб для OpenRC.

Это необходимо?

Нет, написание сценариев инициализации обычно не требуется, так как Gentoo содержит готовые сценарии для всех предоставляемых служб. Однако некоторые пользователи могут установить какую-либо службу, не используя систему Portage; в таком случае, вероятно, придётся создать сценарий самостоятельно.

Не используйте сценарий инициализации, идущий со службой, если он не написан специально для Gentoo: сценарии Gentoo не совместимы со сценариями, используемыми в других дистрибутивах! То есть, если другой дистрибутив не использует OpenRC!

Структура

Основная структура сценария инициализации показана ниже.

CODE Пример структуры init-скрипта (традиционный)

#!/sbin/openrc-run
  
depend() {
# (Информация о зависимостях)
}
  
start() {
# (Команды, необходимые для запуска службы)
}
  
stop() {
# (Команды, необходимые для остановки службы)
}

CODE Пример разметки init-скрипта (обновленный)

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="FooBar Daemon"
 
description="FooBar is a daemon that drinks"
extra_started_commands="drink"
description_drink="Opens mouth and reflexively swallows"
 
depend() {
#  (Информация о зависимостях)
}
 
start_pre() {
#  (Команды, необходимые для запуска службы)
    # Убедимся, что каталог в порядке
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Команды очистки после остановки службы)
    # Очистка любых остатков
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

В любом сценарии инициализации должна быть определена функция start() или переменная command. Все остальные разделы необязательны.

Зависимости

Существуют три настройки, работающие с зависимостями, которые можно определить, и они будут влиять на порядок запуска сценария инициализации: want, use и need. Кроме этих, существуют еще два влияющих на порядок загрузки метода, называющихся before и after. Последние два не определяют зависимости, они не остановят с ошибкой основной сценарий, если выбранный не должен запускаться (или не смог запуститься).

• Настройка use информирует систему init, что данный скрипт использует функциональность некоторого сценария, но строго от него не зависит. Хорошим примером будет use logger или use dns. Если эти службы есть, они будут использоваться, но если у вас нет системы журналирования или DNS-сервера, службы все равно будут работать. Если службы существуют, они будут запущены до того, как запустится сценарий, использующий их.
• Настройка want похожа на use с одним исключением. use учитывает только те службы, которые были добавлены в какой-либо уровень запуска. want попытается запустить любую доступную службу, даже если она не была добавлена в один из уровней запуска.
• Настройка need ­— это жёсткая зависимость. Она означает, что сценарий, которому нужен другой, не запустится, пока другой сценарий не запустится успешно. Также, если другой сценарий будет перезапущен, то этот тоже будет перезапущен.
• При использовании before, данный сценарий запускается до некоторого сценария, если выбранный сценарий — часть того же уровня инициализации. Так, сценарий инициализации xdm, который определен before alsasound будет запущен до сценария alsasound, но только если alsasound запланирован запуститься на том же уровне инициализации. Если alsasound не запланирован для запуска, то эта конкретная настройка не будет иметь эффекта, и xdm запустится в тот момент времени, который система init посчитает лучшим вариантом.
• Похожим образом after информирует систему init, что данный сценарий нужно запустить после некоторого сценария, если выбранный сценарий является частью того же уровня инициализации. Если нет, то настройка не имеет эффекта, и сценарий будет запущен системой init в момент времени, который, как она посчитает, будет наилучшим.

Из изложенного должно быть ясно, что need — это единственная действительная настройка зависимостей, так как она влияет на то, будет ли запущен сценарий или нет. Все остальные являются больше указателями системе init, говорящими в каком порядке сценарии могут (или должны) запускаться.

Теперь, если вы взглянете на существующие сценарии инициализации Gentoo, вы заметите, что некоторые из них имеют зависимости от вещей, которые не являются сценариями. Эти вещи мы называем виртуальными.

Виртуальная зависимость — это зависимость от функций, предоставляемых службой, но не какой-то единственной службой. Сценарий инициализации может зависеть от службы журналирования, но таких достаточно много (metalogd, syslog-ng, sysklogd и тому подобное). Поскольку нельзя нуждаться в каждой из них (ни в одной нормальной системе они не запущены все сразу), мы обеспечили предоставление виртуальной зависимости всеми этими службами.

Например, давайте взглянем на информацию о зависимостях postfix.

FILE /etc/init.d/postfixИнформация о зависимостях службы Postfix

depend() {
  need net
  use logger dns
  provide mta
}

Как можно увидеть, служба postfix:

• требует (виртуальную) зависимость в сети (net, которая предоставляется, например, /etc/init.d/net.eth0)
• использует (виртуальную) зависимость logger (которая предоставляется, например, /etc/init.d/syslog-ng)
• использует (виртуальную) зависимость dns (которая, предоставляется, например, /etc/init.d/named)
• предоставляет (виртуальную) зависимость mta (общая для всех почтовых серверов).

Порядок запуска

Как было описано в предыдущем разделе, можно сказать системе init, в каком порядке она должна запускать (или останавливать) сценарии. Этот порядок поддерживается как через настройки зависимостей use и need, так и через настройки порядка before и after. Так как мы описали их ранее, давайте посмотрим на службу Portmap, как на пример такого сценария инициализации.

FILE /etc/init.d/portmapИнформация о зависимостях службы portmap

depend() {
  need net
  before inetd
  before xinetd
}

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

CODE Использование символа *

depend() {
  before *
}

Если службе необходима возможность записывать данные на локальные диски, она должна потребовать localmount. Если она что-либо поместит в /var/run/, например, PID-файл, она должна запускаться после bootmisc:

CODE Настройка зависимостей на необходимость localmount и запуск после bootmisc

depend() {
  need localmount
  after bootmisc
}

Стандартные функции

Следом за разделом depend() потребуется определить функцию start(). В ней содержатся все команды, необходимые для запуска службы. Рекомендуется применять функции ebegin и eend для сообщений пользователю о том, что происходит:

CODE Пример функции start()

start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Что-нибудь сделать, если рестарт требует больше, чем просто последовательный запуск stop и start
  fi
  
  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Как --exec, так и --pidfile должны использоваться в функциях start и stop. Если служба не создает PID-файл, то по возможности используйте --make-pidfile, хотя это может потребовать дополнительного тестирования. В ином случае не используйте PID-файлы. Можно добавить --quiet к аргументам start-stop-daemon, но это не рекомендуется, если только служба не очень многословная. Использование --quiet может скрыть отладочную информацию, если служба не может запуститься.

Другой интересной настройкой, используемой в вышеприведенном примере является проверка содержимого переменной RC_CMD. В отличие от предыдущей системы инициализации, новая система OpenRC не поддерживает отдельную функциональность restart для каждого скрипта. Вместо этого сценарий должен проверить содержимое переменной RC_CMD, чтобы проверить, вызывается ли функция (как start(), так и stop()) как часть restart, или нет.

Note
Удостоверьтесь, что --exec действительно вызывает службу, а не shell-скрипт, который запускает службы и выходит — это должен делать сам init-скрипт.

Если нужны дополнительные примеры функции start(), пожалуйста, прочитайте исходный код сценариев, находящихся в каталоге /etc/init.d/.

Еще одной функцией, которую можно определить (но не обязательно это делать), является stop(). Система init, применяемая нами, достаточно развита и в состоянии самостоятельно заполнить эту функцию, если используется start-stop-daemon.

CODE Пример функции stop()

stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Если служба запускает некоторый другой сценарий (например, на Bash, Python или Perl), и этот сценарий позднее изменяет имя (например, с foo.py на foo), тогда нужно добавить --name к start-stop-daemon. Нужно определить имя, на которое сценарий изменит свое имя. В приведенном примере, служба запускает foo.py, а потом это имя меняется на foo:

CODE Пример определения службы, которая запускает скрипт foo

start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

У start-stop-daemon есть отличная man-страница, которую можно посмотреть, если нужна дополнительная информация.

user $man start-stop-daemon

Синтаксис сценариев инициализации, применяемых в Gentoo, основан на оболочке POSIX, поэтому можно свободно использовать внутри своих скриптов sh-совместимые конструкции. Остальные конструкции, вроде тех, которые специфичны только для bash, следует выносить за пределы сценария, чтобы быть уверенным, что сценарий будет работать независимо от того, что Gentoo может сделать со своей системой init.

Добавление дополнительных параметров

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

• extra_commands — команду можно запустить при любом состоянии службы
• extra_started_commands — команду можно запустить, когда служба запущена
• extra_stopped_commands — команду можно запустить, когда служба остановлена

CODE Пример определения метода restartdelay

extra_started_commands="restartdelay"
  
restartdelay() {
  stop
  sleep 3    # пауза в 3 секунды перед повторным запуском
  start
}

Important
Функция restart() не может быть переназначена в OpenRC!

Переменные для настройки служб

Для поддержки файлов конфигурации из каталога /etc/conf.d/ ничего дополнительно делать не нужно: при запуске сценария инициализации автоматически подключаются следующие файлы (то есть переменные из них становятся доступны):

• /etc/conf.d/YOUR_INIT_SCRIPT
• /etc/conf.d/basic
• /etc/rc.conf

Кроме того, если сценарий инициализации предоставляет виртуальную зависимость (например, net), то также подключается файл, соответствующий этой зависимости (например, /etc/conf.d/net).

Изменение поведения уровней запуска

Кому это может быть полезным

Большинству пользователей ноутбуков знакома ситуация: дома нужен запуск net.eth0, и наоборот, в дороге запуск net.eth0 не нужен (так как сеть недоступна). В Gentoo можно изменять поведение уровней запуска по своему усмотрению.

Например можно создать второй загружаемый уровень запуска default, в котором будут другие сценарии. Затем, при загрузке, можно выбрать, какой из уровней default следует использовать.

Использование программного уровня (softlevel)

Прежде всего, создайте каталог для второго уровня запуска default. Например, создадим уровень запуска offline:

root #mkdir /etc/runlevels/offline

Добавьте необходимые сценарии в только что созданный уровень запуска. Например, чтобы получить точную копию уровня default, за исключением net.eth0:

root #cd /etc/runlevels/default

root #for service in *; do rc-update add $service offline; done

root #rc-update del net.eth0 offline

root #rc-update show offline

(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Даже несмотря на то, что net.eth0 был удален с уровня запуска offline, udev может попытаться запустить любые устройства, которые найдёт, и запустить соответствующие службы. Данная функциональность называется hotplugging. По умолчанию, Gentoo отключает hotplugging.

Чтобы включить hotplugging, но только для конкретного набора сценариев, используйте переменную rc_hotplug в /etc/rc.conf:

FILE /etc/rc.confВключение hotplugging на интерфейсе WLAN

rc_hotplug="net.wlan !net.*"

Note
Для более детальной информации о службах, инициируемых устройствами, просмотрите комментарии в /etc/rc.conf.

Теперь необходимо отредактировать конфигурацию загрузчика, добавив новую запись для уровня запуска offline. В данной записи добавьте softlevel=offline в качестве параметра загрузки.

Использование загрузочного уровня (bootlevel)

Использование загрузочного уровня полностью аналогично использованию программного уровня. Единственная разница состоит в том, что определяется второй уровень boot вместо второго уровня default.

← Возможности Portage К содержанию Переменные окружения →

Переменные окружения

Введение

Переменная окружения — это именованный объект, который содержит определения, используемые одним или несколькими приложениями. Используя переменные окружения, можно очень легко изменить настройки для одного или нескольких приложений.

Наиболее важные переменные

В следующей таблице перечислен ряд переменных, используемых в системе Linux и описание их использования. Примеры их значений приведены после таблицы.

Variable	Description
PATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых система ищет исполняемые файлы. Если введенное имя — это исполняемый файл (например, ls, rc-update или emerge), но этот файл не находится в каталоге из списка, то система не будет выполнять его (если только не ввести полный путь к команде, например /bin/ls).
ROOTPATH	У этой переменной то же назначение, что и у PATH, но в ней содержатся только те каталоги, которые должны быть проверены, когда root-пользователь вводит команду.
LDPATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых динамический линковщик ищет библиотеки.
MANPATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых команда man ищет страницы man.
INFODIR	Эта переменная содержит разделенный двоеточиями список каталогов, в которых команда info выполняет поиск страниц info.
PAGER	Эта переменная содержит путь к программе, используемой для отображения содержимого файлов (таких как less или more).
EDITOR	Эта переменная содержит путь к программе, используемой для изменения содержимого файлов (таких как nano или vi).
KDEDIRS	Эта переменная содержит разделенный двоеточиями список каталогов, содержащих специфический материал для KDE.
CONFIG_PROTECT	Эта переменная содержит разделенный пробелами список каталогов, которые должны быть защищены Portage при обновлении пакетов.
CONFIG_PROTECT_MASK	Эта переменная содержит разделенный пробелами список каталогов, которые не должны быть защищены Portage при обновлении пакетов.

Ниже приведен пример, содержащий все эти переменные:

CODE Пример значений для указанных переменных

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
# Каталоги, защищаемые во время обновления пакетов.
# Обратная косая черта в конце строк (\) означает, что это одна строка, разделяемая пробелами.
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
# Каталоги, которые _не_ защищаются во время обновления пакетов.
CONFIG_PROTECT_MASK="/etc/gconf"

Определение переменных глобально

Каталог env.d

Для централизации определения переменных в Gentoo используется каталог /etc/env.d/. Внутри каталога есть несколько файлов, такие как 50baselayout, gcc/config-x86_64-pc-linux-gnu и так далее, которые содержат переменные, необходимые программе из названия файла.

Например, когда установлен gcc, ebuild создает файл с названием gcc/config-x86_64-pc-linux-gnu, который содержит определения следующих переменных:

FILE /etc/env.d/gcc/config-x86_64-pc-linux-gnuПеременные по умолчанию для GCC 13

GCC_PATH="/usr/x86_64-pc-linux-gnu/gcc-bin/13"
LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/13:/usr/lib/gcc/x86_64-pc-linux-gnu/13/32"
MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man"
INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info"
STDCXX_INCDIR="g++-v13"
CTARGET="x86_64-pc-linux-gnu"
GCC_SPECS=""
MULTIOSDIRS="../lib64:../lib"

Другие дистрибутивы просят пользователя изменять или добавлять такие определения переменных окружения в /etc/profile или в других местах. С другой стороны, в Gentoo очень просто для пользователя (и для Portage) обслуживать и управлять переменными окружения без необходимости обращать внимание на многочисленные файлы, которые содержат переменные окружения.

Например, при обновлении gcc также обновляется связанный с ним файл /etc/env.d/gcc без какого-либо запроса в сторону администратора.

От этого выигрывает как Portage, так и пользователь. Иногда пользователям необходимо установит определенную переменную окружения для всей системы. Например, возьмем переменную http_proxy. Чтобы не возиться с /etc/profile, пользователь может просто создать файл (скажем /etc/env.d/99local) и написать необходимое определения в нём:

FILE /etc/env.d/99localНастройка глобальной переменной окружения

http_proxy="proxy.server.com:8080"

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

env-update

Несколько файлов в /etc/env.d/ определяют переменную PATH. Это не ошибка: когда выполняется команда env-update, она добавит другие определения перед обновлением переменного окружения, что позволяет просто добавлять для пакетов (или пользователей) свои собственные настройки переменного окружения без вмешательство в уже существующие значениями.

Сценарий env-update добавляет значения из файлов /etc/env.d/ в алфавитном порядке. Имена файлов должны начинаться с двух десятичных чисел.

CODE Порядок обновления, используемый env-update

09sandbox    50baselayout     51dconf
     +------------+----------------+-----------+
CONFIG_PROTECT_MASK="/etc/sandbox.d /etc/gentoo-release /etc/dconf ..."

Объединение переменных происходит не всегда, а только для следующих переменных: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH и PYTHONPATH. Для всех остальных переменных используется последнее значение (в алфавитном порядке файлов в /etc/env.d/).

Можно добавить больше переменных к списку объединяемых переменных, добавив имя переменной в одну из переменных COLON_SEPARATED или SPACE_SEPARATED (также внутри файла /etc/env.d/).

При запуске env-update, сценарий создаст все переменные окружения и поместит их в /etc/profile.env (который используется /etc/profile). Кроме того, сценарий на основе значения LDPATH создаст /etc/ld.so.conf. После этого он запустит ldconfig, чтобы пересоздать файл /etc/ld.so.cache, используемый динамическим компоновщиком.

Чтобы увидеть эффект работы env-update сразу после его запуска, выполните следующую команду, чтобы обновить окружение. Пользователи, которые устанавливали Gentoo сами, вероятно, вспомнят эту команду из инструкции по установке:

root #env-update && source /etc/profile

Note
Команда выше обновит переменные только для текущего терминала, в новых консолях и их потомках. Таким образом, если пользователь работает в X11, ему нужно либо вводить source /etc/profile в каждом новом открытом терминале, либо перезагрузить X, так все новые терминалы получили новые переменные. Если используется менеджер входа, то необходимо стать root и перезагрузить сервис /etc/init.d/xdm.

Important
Нельзя использовать переменные оболочки для определения других переменных. Это означает, что такие вещи как FOO="$BAR" (где $BAR это другая переменная) запрещены.

Определение переменных локально

Для пользователя

Не всегда нужно определять переменную окружения на глобальном уровне. Например, кому-то может понадобится добавить /home/my_user/bin и текущий рабочий каталог (каталог в котором находится пользователь) в переменную PATH, но не нужно чтобы все другие пользователи получили такой же PATH. Для определения переменной окружения локально, используйте ~/.bashrc или ~/.bash_profile:

FILE ~/.bashrcДополнительный PATH для локального использования

# A colon followed by no directory is treated as the current working directory
PATH="${PATH}:/home/my_user/bin:"

Переменная PATH будет обновлена после выхода/входа.

Для сеанса

Иногда необходимы более жесткие ограничения. Например, необходимо использовать двоичные файлы из временного каталога без указания пути к ним или редактирования ~/.bashrc на короткий срок.

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

root #export PATH="${PATH}:/home/my_user/tmp/usr/bin"

← Система init-скриптов К содержанию Файлы и каталоги →