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

HPPA Handbook
Установка
Об установке
Выбор подходящего источника для установки
Настройка сети
Подготовка дисков
Установка stage3
Установка базовой системы
Настройка ядра
Настройка системы
Установка системных утилит
Настройка загрузчика
Завершение
Работа с Gentoo
Введение в Portage
USE-флаги
Возможности Portage
Система init-скриптов
Переменные окружения
Работа с Portage
Файлы и каталоги
Переменные
Смешение ветвей программного обеспечения
Дополнительные утилиты
Дополнительные репозитории пакетов
Расширенные возможности
Настройка сети
Начальная настройка
Расширенная настройка
Модульное построение сети
Беспроводная сеть
Добавляем функциональность
Динамическое управление

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

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

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

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

user $man emerge

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

Ebuilds

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

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

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

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

root #emerge --sync

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

root #emerge-webrsync

Дополнительным преимуществом использования emerge-webrsync, это то что она позволяет администратору загружать снимки Gentoo репозитория, которые подписаны ключом GPG для разрабатываемых релизов Gentoo. Более подробную информацию об этом можно найти в статье возможности Portage в секции проверенные снимки Gentoo репозитория.

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

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

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

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

user $emerge --search pdf

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

user $emerge --searchdesc pdf

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

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

*  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

Во время установки пакета, Portage скачает необходимый исходный код из интернета (если необходимо) и по умолчанию сохранит его в /usr/portage/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 --unmerge. Она попросит Portage удалить все файлы установленные пакетом из системы. Одним исключением из этого являются файлы конфигурации этого приложения, если они были изменены пользователем. Сохранение конфигурационных файлов позволяет пользователям продолжать работать с пакетом, без необходимости настраивать снова пакет, если он будет установлен снова позже.

Предупреждение
Portage не проверяет требуется ли удаляемый пакет для другого пакета. Однако он сообщит когда удаляется важный пакет и его удаление сломает систему.

root #emerge --unmerge gnumeric

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

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

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

root #emerge --update --ask @world

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

root #emerge --update --deep @world

Но все еще это не означает все пакеты: некоторые пакеты в системе необходимы для компиляции и во время создания пакетов, но как только пакет установлен, эти зависимости больше не требуется. Portage называет это "build зависимостями". Чтобы обновить и эти пакеты тоже добавьте опцию --with-bdeps=y:

root #emerge --update --deep --with-bdeps=y @world

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

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

root #emerge --update --deep --with-bdeps=y --newuse @world

Метапакеты

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

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

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

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

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

root #emerge --depclean

root #revdep-rebuild

revdep-rebuild входит в пакет app-portage/gentoolkit; не забудьте установить его:

root #emerge --ask app-portage/gentoolkit

Лицензии

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

По умолчанию, Portage позволяет все лицензии, за исключением лицензионного соглашения с конечным пользователем (EULA), которое требуют прочтения и подписание соглашения о принятии.

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

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

ACCEPT_LICENSE="* -@EULA"

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

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

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

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

www-client/google-chrome google-chrome

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

Важно
Сами лицензии сохранены в каталоге /usr/portage/licenses/, а лицензионные группы сохранены в файле /usr/portage/profiles/license_groups. Первая запись в каждой строке написанная БОЛЬШИМИ буквами это название группы лицензий, а остальные записи после неё, индивидуальные лицензии.

Определяя группы лицензий в переменной ACCEPT_LICENSE, поставьте перед ними знак @. Часто настраивают так, что разрешают только установку свободного программного обеспечения и документации. Чтобы сделать это, удалите все разрешенные лицензии на данный момент (используя -*), а затем разрешите только лицензии из группы FREE:

Файл /etc/portage/make.confПозволять только свободное программное обеспечение и документацию

ACCEPT_LICENSE="-* @FREE"

В этом случае "free", в основном, определяется FSF и OSI. Любой пакет, лицензия которого не соответствует этим требованиям, не будет установлен на системе.

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

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

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

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

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

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

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

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

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

Код Portage предупреждает о заблокированных пакетах (с --pretend)

[blocks B     ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)

Код Portage предупреждает о заблокированных пакетах (без --pretend)

!!! Error: the mail-mta/postfix package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers.

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

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

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

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

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

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

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

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

Код 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-флаг

Код 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 не установлен:

Код Ошибка 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.

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

Код 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

Код 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 сообщит пользователю о возможных совпадений, чтобы помочь выбрать.

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

Код 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, и если нет, сообщите о ней.

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

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

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

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

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

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

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

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

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

Ошибка проверки подписи

Код Ошибка проверки подписи

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

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

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

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

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

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

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

HPPA Handbook
Установка
Об установке
Выбор подходящего источника для установки
Настройка сети
Подготовка дисков
Установка stage3
Установка базовой системы
Настройка ядра
Настройка системы
Установка системных утилит
Настройка загрузчика
Завершение
Работа с Gentoo
Введение в Portage
USE-флаги
Возможности Portage
Система init-скриптов
Переменные окружения
Работа с Portage
Файлы и каталоги
Переменные
Смешение ветвей программного обеспечения
Дополнительные утилиты
Дополнительные репозитории пакетов
Расширенные возможности
Настройка сети
Начальная настройка
Расширенная настройка
Модульное построение сети
Беспроводная сеть
Добавляем функциональность
Динамическое управление

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

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

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

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

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

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

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

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

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

Какие бывают USE-флаги

Есть два типа USE-флагов: глобальные и локальные.

• Глобальные USE-флаги используются множеством пакетов, работают для всей системы. Это то, что большинство людей называют USE-флагами. Список доступных глобальных USE-флагов можно найти на странице основного или локально в файле /usr/portage/profiles/use.desc.
• Локальные USE-флаги используются конкретным пакетом, чтобы определить параметры самого пакета. Список доступных локальных USE-флагов можно найти на странице основного сайта или локально в файле /usr/portage/profiles/use.local.desc.

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

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

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

Профиль, на который ссылается система, читается из симлинка /etc/portage/make.profile. Каждый профиль работает поверх других профилей, поэтому конечный результат в итоге будет суммой всех профилей. В самом верху находится базовый профиль (/usr/portage/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-флаги, или удалить USE-фдаги, которые больше не нужны. Для удаления необходимо добавить перед ключевым словом префикс в виде знака минус (-).

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

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

USE="-kde -qt4 -qt5 ldap"

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

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

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

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

media-video/vlc bluray

Совет
If package.use is pre-existing as a directory (opposed to a single file), packages can have their local USE flags modified by simply creating files under the package.use/ directory. Any file naming convention can work, however it is wise to implement a coherent naming scheme. One convention is to simply use the package name as the title for the child file. For example, setting the bluray USE flag locally for the media-video/vlc package can be performed as follows:

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

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

Файл /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-флагами.

Предупреждение
Запуск команды emerge --depclean опасная операция и должна использоваться с осторожностью. Дважды проверьте предоставленный список "ненужных (obsoleted)" пакетов, чтобы убедиться, что не удаляться нужные пакеты. В следующем примере мы добавили -p, чтобы depclean просто отобразил пакет без их удаления:

root #emerge -p --depclean

После завершения работы depclean, запустите revdep-rebuild, чтобы пересобрать приложения, что снова динамически перелинкует общие объекты, ранее предоставляемые удаляемыми пакетами. revdep-rebuild - это часть пакета app-portage/gentoolkit; не забудьте сперва его установить.

root #revdep-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-флаги для определенного пакета. Например, для пакета gnumeric:

user $equery --nocolor uses =gnumeric-1.12.31

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-office/gnumeric-1.12.31:
 U I
 + + introspection            : Add support for GObject based introspection
 - - libgda                   : Enable database support through gnome-extra/libgda.
 - - perl                     : Enable perl plugin loader.
 + + python                   : Enable python plugin loader.
 + + python_targets_python2_7 : Build with Python 2.7

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

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

Некоторые примеры для выражений REQUIRED_USE предоставлены ниже:

Пример	Описание
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 →

HPPA Handbook
Установка
Об установке
Выбор подходящего источника для установки
Настройка сети
Подготовка дисков
Установка stage3
Установка базовой системы
Настройка ядра
Настройка системы
Установка системных утилит
Настройка загрузчика
Завершение
Работа с Gentoo
Введение в Portage
USE-флаги
Возможности Portage
Система init-скриптов
Переменные окружения
Работа с 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=gnome или 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, пожалуйста посетите их домашнюю страницу

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

Установка ccache

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

root #emerge --ask dev-util/ccache

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

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

Файл /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.

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

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

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

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

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

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

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

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

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

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

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

PORTAGE_BINHOST="ftp://buildhost/gentoo"

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

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

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:

Файл /etc/portage/make.confРазрешить только бинарно-распространяемые пакеты

ACCEPT_RESTRICT="* -bindist"

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

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

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

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

Загрузка пользователем (userfetch)

Portage обычно запускается от пользователя root. Настройка FEATURES="userfetch" позволит Portage бросить привилегии root при загрузке исходного кода и выполнит эту операцию с правами пользователя/группы portage:portage. Это небольшое усиление безопасности.

Если userfetch установлена в FEATURES, убедитесь, что изменили владельца у всех файлов в /usr/portage с помощью команды chown, запущенную с привилегиями root:

root #chown --recursive --verbose portage:portage /usr/portage

Проверенные снимки Gentoo репозитория

Администраторы могут выбрать обновление локального репозитория ebuild-файлов с криптографически проверенного снимка, который выпускаются инфраструктурой Gentoo. Это гарантирует, что ни одно недобросовестное зеркало rsync не добавляет нежелательный код или дополнительные пакеты в репозитории.

Заметка
Ниже приводится обновленный метод для создания и использования метода синхронизации emerge-webrsync используя repos.conf.

Ключи OpenPGP для выпускаемых образов Gentoo (Gentoo release media) теперь доступны в виде бинарного брелка. Он может быть установлен пакетом app-crypt/gentoo-keys:

root #emerge --ask app-crypt/gentoo-keys

Это установит связку ключей в каталог /var/lib/gentoo/gkeys/keyrings/gentoo/release.

Файл /etc/portage/make.confВключение поддержки GPG в Portage

FEATURES="webrsync-gpg"
PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release"

Файл /etc/portage/repos.conf/gentoo.confОчистка переменной sync-uri

[DEFAULT]
main-repo = gentoo
 
[gentoo]
# Отключите синхронизацию настроив auto-sync = no или удалив значение
# В этом конфигурационном файле не устанавливайте значения для переменных с использованием кавычек ('' или "")!
# Для portage-2.2.18 используйте 'websync'
# Для portage-2.2.19 и выше используйте 'webrsync' (websync был переименован в webrsync)
sync-type = webrsync
sync-uri = 
auto-sync = yes

Убедитесь, что пакет app-crypt/gnupg установлен:

root #emerge --ask app-crypt/gnupg

Используйте gpg, чтобы проверить ключи в брелке на корректность:

root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --with-fingerprint --list-keys

Сверьте отпечатки ключей с теми, которые перечислены на официальной странице проекта Gentoo release engineering.

Важно
Если один из ключей установленных пакетом app-crypt/gentoo-keys скоро истечет, запустите gkeys из пакета app-crypt/gkeys для обновления ключа с сервера ключей:

root #emerge --ask app-crypt/gkeys

root #gkeys refresh-key -C gentoo

Повторите следующую команду для каждого ключа, которому вы хотите доверять. (Подставьте идентификатор ключа '0x ...' для ключа, которому вы хотите доверять.)

root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --edit-key 0xDB6B8C1F96D8BF6D trust

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

gpg>4

gpg>quit

Теперь система настроена для синхронизации, используя только проверенные OpenPGP/gpg снимки.
Есть несколько команд, чтобы выполнить синхронизации.

Заметка
Одной из следующих команд достаточно для синхронизации. Для более подробной информации смотрите статью Portage sync.

root #emerge --sync

root #emaint sync -a

root #emaint sync --repo gentoo

root #emerge-webrsync

Verify distfiles

To re-verify the integrity and (potentially) re-download previously removed/corrupted distfiles for all currently installed packages, run:

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

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

HPPA Handbook
Установка
Об установке
Выбор подходящего источника для установки
Настройка сети
Подготовка дисков
Установка stage3
Установка базовой системы
Настройка ядра
Настройка системы
Установка системных утилит
Настройка загрузчика
Завершение
Работа с Gentoo
Введение в Portage
USE-флаги
Возможности Portage
Система init-скриптов
Переменные окружения
Работа с Portage
Файлы и каталоги
Переменные
Смешение ветвей программного обеспечения
Дополнительные утилиты
Дополнительные репозитории пакетов
Расширенные возможности
Настройка сети
Начальная настройка
Расширенная настройка
Модульное построение сети
Беспроводная сеть
Добавляем функциональность
Динамическое управление

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

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

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

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

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

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

Init-скрипты

Сейчас процесс 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:

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

si::sysinit:/sbin/openrc sysinit

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

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

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

rc::bootwait:/sbin/openrc boot

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

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

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

id:3:initdefault:

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

Файл /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 принимает решение о том, какие виртуальные консоли включить и какие команды выполнить в каждой из них:

Файл /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 применяет нумерацию для определения уровня запуска, который надо использовать. Уровень запуска - это то состояние, в котором запущена система, он содержит набор скриптов (скрипты уровня запуска или init-скрипты), которые следует выполнять, при входе и выходе из определенного уровня запуска.

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

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

Работа с init-скриптами

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

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

root #/etc/init.d/postfix start

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

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

root #/etc/init.d/postfix --nodeps stop

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

root #/etc/init.d/postfix status

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

root #/etc/init.d/postfix zap

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

root #/etc/init.d/postfix ineed

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

root #/etc/init.d/postfix needsme

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

rc-update

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

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

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

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

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

root #rc-update del postfix default

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

root #rc-update -v show

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

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

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

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

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

Каталог conf.d

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

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

APACHE2_OPTS="-D PHP5"

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

Написание init-скриптов

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

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

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

Структура

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

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

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

Код Example initscript layout (updated)

#!/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() {
#  (Dependency information)
}

start_pre() {
#  (Commands necessary to prepare to start the service)
    # Ensure that our dirs are correct
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commands necessary to clean up after the service)
    # Clean any spills
    rm -rf /var/cache/foo/*
}

drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

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

Зависимости

Существуют три настройки, работающие с зависимостями, которые можно определить, и они будут влиять на порядок запуска init-скриптов: 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, вы заметите, что некоторые из них имеют зависимости от вещей, которые не являются инициализационными скриптами. Эти вещи мы называем виртуальными.

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

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

Файл /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, как на пример такого init-скрипта.

Файл /etc/init.d/portmapИнформация о зависимостях сервиса portmap

depend() {
  need net
  before inetd
  before xinetd
}

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

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

depend() {
  before *
}

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

Код Настройка зависимостей - нам нужен localmount и мы стартуем после bootmisc

depend() {
  need localmount
  after bootmisc
}

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

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

Код Пример функции 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, или нет.

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

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

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

Код Пример функции 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:

Код Пример определения сервиса, который запускает скрипт 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

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

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

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

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

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

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

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

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

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

• /etc/conf.d/ВАШ_INIT_СКРИПТ
• /etc/conf.d/basic
• /etc/rc.conf

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

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

Кто может выиграть?

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

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

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

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

root #mkdir /etc/runlevels/offline

Добавьте необходимые init-скрипты в только что созданный уровень запуска. Например, чтобы получить точную копию уровня 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:

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

rc_hotplug="net.wlan !net.*"

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

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

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

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

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

HPPA Handbook
Установка
Об установке
Выбор подходящего источника для установки
Настройка сети
Подготовка дисков
Установка stage3
Установка базовой системы
Настройка ядра
Настройка системы
Установка системных утилит
Настройка загрузчика
Завершение
Работа с Gentoo
Введение в Portage
USE-флаги
Возможности Portage
Система init-скриптов
Переменные окружения
Работа с 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 при обновлении.

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

Код Пример содержимого для вышеуказанных переменных

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/. Внутри каталога есть несколько файлов, такие как 00basic, 05gcc, и т.д., которые содержат переменные, необходимые программе из названия файла.

Например, когда установлен gcc, ebuild создает файл с названием 05gcc, который содержит определения следующих переменных:

Файл /etc/env.d/05gccПеременные, которые идут по умолчанию для gcc

PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info"
CC="gcc"
CXX="g++"
LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

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

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

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

Файл /etc/env.d/99localНастройка глобальной переменной

http_proxy="proxy.server.com:8080"

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

env-update

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

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

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

00basic        99kde-env       99local
     +-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

Объединение переменных происходит не всегда, а только для следующих переменных: 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

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

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

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

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

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

Файл ~/.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-скриптов К содержанию Файлы и каталоги →