Gentoo Linux ppc64 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 находятся в /var/db/repos/gentoo.
Всякий раз, когда кто-то просит 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
Обратите внимание, что вывод команды возвращает много информации. Поля четко обозначены, поэтому мы не будем вдаваться в подробности их значения:
* 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 покажет лицензию пакета.
Переменная 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. В следующем примере показано значение по умолчанию:
ACCEPT_LICENSE="-* @FREE"
При такой конфигурации пакеты, имеющие свободную лицензию ПО или документации, могут быть установлены. Несвободное ПО не сможет быть установлено.
Можно настроить ACCEPT_LICENSE глобально в файле /etc/portage/make.conf или специально для отдельного пакета в файле /etc/portage/package.license.
Например, чтобы разрешить google-chrome лицензию для пакета www-client/google-chrome добавьте следующее в /etc/portage/package.license:
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:
# 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
Сами лицензии хранятся в каталоге /var/db/repos/gentoo/licenses/, а лицензионные группы — в файле /var/db/repos/gentoo/profiles/license_groups. Первая запись в каждой строке, записанная ЗАГЛАВНЫМИ буквами — это название группы лицензий, остальные записи после неё — индивидуальные лицензии.
Группа лицензий в переменной ACCEPT_LICENSE указываются с символом @
перед ней. Возможной настройкой (которая является значением по умолчанию в Gentoo) является разрешение всех лицензий, кроме Соглашений с лицензией конечного пользователя (EULA), которые обычно требуют прочтения и подписания соглашения о принятии условий лицензии. Это можно достичь, приняв все лицензии (через *
), после чего удалив лицензии из группы 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 также придерживается определенного профиля, который содержит, помимо прочей информации, ещё и список пакетов, необходимых для нормальной работоспособности системы.
Заблокированные пакеты
[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.
Замаскированные пакеты
!!! all ebuilds that could satisfy "bootsplash" have been masked.
!!! 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-флаг
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
не установлен:
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.
Отсутствующие зависимости
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
[ 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 сообщит пользователю о возможных совпадений, чтобы помочь в выборе.
Циклические зависимости
!!! 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, и если нет, сообщите о ней.
Ошибка загрузки
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered. Please see above for details.
Portage не смог загрузить исходный код для данного приложения и попытается продолжить установку других приложений (если это возможно). Эта ошибка может быть из-за неправильно синхронизированного зеркала или, возможно, ebuild указывает на неверное место. Также сервер, где находятся исходные коды, может временно недоступен.
Повторите действие через час, чтобы проверить, повторяется ли еще ошибка.
Защита системного профиля
!!! 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 — часто, возникает из-за того, что сделана ошибка при изменении пакета в репозитории Gentoo.
Когда проверка контрольных сумм завершается ошибкой, не пытайтесь обновить их пакета лично. Запуск ebuild foo manifest не решит проблему; ситуация может ухудшиться.
Вместо этого, подождите час или два, пока репозиторий обновится. Вполне вероятно, что ошибка была замечена сразу, но может пройти некоторое время, пока исправление дойдёт до зеркал. Проверьте Bugzilla, возможно кто-то сообщил о том, что проблема существует или поспрашивайте на #gentoo (webchat) (IRC). Если нет, то создайте ошибку о сломанном ebuild.
После того, как ошибка была исправлена, повторно синхронизируйте репозиторий Gentoo, чтобы загрузить исправленные контрольные суммы.
Не нужно синхронизировать Gentoo репозиторий ebuild-файлов чаще чем раз в день. Как указано в официальной политике сетевого этикета (при выполнении emerge --sync), пользователям, которые синхронизируются слишком часто, временно может быть запрещена синхронизация. Нарушители, которые неоднократно нарушают эту политику, могут быть заблокированы на долгое время. Если нет критической необходимости, лучше просто подождать 24 часа, так повторная синхронизация не будет перегружать rsync-зеркала Gentoo.
Что такое 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. Каждый профиль работает поверх других профилей, поэтому конечный результат в итоге будет суммой всех профилей. В основе всех профилей базовый профиль (/var/db/repos/gentoo/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-флаги:
USE="-kde -qt5 ldap"
Объявление USE-флагов для отдельных пакетов
Иногда необходимо определить некий USE-флаг для одного или нескольких приложений, но не для всей системы. Для этого отредактируйте /etc/portage/package.use. Как правило, package.use — это один файл, но может быть и каталогом; смотрите совет ниже и man 5 portage для более подробной информации. Следующий пример подразумевает, что package.use — это один файл.
Например, чтобы включить поддержку Blu-ray только в пакете VLC:
media-video/vlc bluray
Если 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):
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, отсортированная по приоритету (сперва меньший приоритет):
- Настройки USE по умолчанию объявляются в файле make.defaults из выбранного профиля
- Определённые пользователем настройки USE в файле /etc/portage/make.conf
- Определённые пользователем настройки USE в файле /etc/portage/package.use
- Определённые пользователем настройки USE в виде переменной окружения.
Чтобы отобразить финальные настройки, как их видит Portage, выполните emerge --info. Эта команда отобразит список соответствующих переменных (включая переменные USE) с их текущими значениями, как их видит Portage.
root #
emerge --info
Адаптация всей системы под новые USE-флаги
После изменений USE-флагов система должна быть обновлена, чтобы изменения вступили в силу. Чтобы сделать это, используйте параметр --newuse
для emerge:
root #
emerge --update --deep --newuse @world
Далее, запустите очистку зависимостей Portage (depclean), чтобы удалить зависимости, которые были необходимы в «старой» системе, но теперь, с новыми USE-флагами, устарели.
Дважды проверьте предоставленный список «устаревших» (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 есть несколько дополнительных возможностей (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, пожалуйста, посетите их домашнюю страницу.
Известно, что 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
:
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.
PATH="/usr/lib/ccache/bin:${PATH}"
Поддержка двоичных пакетов
Создание прекомпилированных пакетов
Portage поддерживает установку двоичных пакетов.
Чтобы создать бинарный пакет, воспользуйтесь командой quickpkg, если пакет уже установлен в системе, или скомпилируйте его с параметром --buildpkg
или --buildpkgonly
.
Чтобы Portage создавал двоичные пакеты для каждого устанавливаемого пакета, добавьте buildpkg
в переменную FEATURES.
Более расширенные возможности при создании набора двоичных пакетов можно получить, используя catalyst. Более подробную информацию о catalyst можно прочитать в Catalyst FAQ.
Установка прекомпилированных пакетов
Хотя Gentoo не предоставляет таковые, можно создать централизованный репозиторий двоичных пакетов. Для того, чтобы использовать такой репозиторий, нужно сообщить Portage об этом с помощью переменной PORTAGE_BINHOST, которая указывает на такое хранилище. Например, если бинарные пакеты находятся по адресу ftp://buildhost/gentoo:
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:
ACCEPT_RESTRICT="* -bindist"
Также можно переопределить переменную ACCEPT_RESTRICT, добавив параметр --accept-restrict
в команду emerge. Например, --accept-restrict=-bindist
временно замаскирует пакеты с ограничением bindist
.
Также, в случае распространения пакетов, рекомендуется настроить переменную ACCEPT_LICENSE. Смотрите раздел Лицензии.
Ответственность за соответствие условиям лицензии и соответствие законодательству страны, где предполагается распространять пакет, полностью лежит на пользователе. Переменные метаданных, определённые в ebuild (RESTRICT или LICENSE), сообщат о том, что распространение двоичных пакетов не разрешено, однако, вывод команд Portage или вопросы, на которые отвечали разработчики Gentoo не являются юридическими заявлениями; не стоит полагаться на них. Будьте внимательны при соблюдении законов своей страны.
Загрузка файлов
Проверка архивов исходных файлов
Чтобы перепроверить целостность и (возможно) повторно скачать ранее удаленные/поврежденные архивы исходных файлов (distfiles) для всех установленных пакетов, выполните:
root #
emerge --ask --fetchonly --emptytree @world
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:
si::sysinit:/sbin/openrc sysinit
Этой строкой процессу init предписывается выполнить /sbin/openrc sysinit для инициализации системы. Самой инициализацией занимается сценарий /sbin/openrc, так что можно сказать, что init делает не слишком много — он просто делегирует задачу по инициализации системы другому процессу.
Во-вторых, init выполняет все сценарии, на которые есть символьные ссылки из /etc/runlevels/boot/. Это определяется следующей строкой:
rc::bootwait:/sbin/openrc boot
И снова все необходимые действия выполняются сценарием OpenRC. Заметьте, что параметр, переданный OpenRC (boot), совпадает с названием используемого подкаталога в /etc/runlevels/.
Теперь init проверяет свой конфигурационный файл, чтобы определить, какой уровень запуска нужно запустить. Для этого из /etc/inittab считывается строка:
id:3:initdefault:
В приведенном примере (который подходит для подавляющего большинства пользователей Gentoo) номер уровня запуска — 3. Пользуясь этой информацией, init проверяет, что нужно выполнить для запуска уровня запуска 3:
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 принимает решение о том, какие виртуальные консоли включить и какие команды выполнить в каждой из них:
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
Останавливаются или перезапускаются только те службы, которым необходима данная служба. Остальные зависимые службы (те, которые используют службу, но не нуждаются в ней) эта операция не затрагивает.
Если вы хотите остановить службу, но оставить зависимые от неё работающими, можно использовать опцию --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 при запуске:
APACHE2_OPTS="-D PHP5"
Такие конфигурационные файлы содержат только переменные (наподобие /etc/portage/make.conf), облегчая настройку служб. Это также позволяет нам давать больше информации о переменных (в комментариях).
Написание сценариев инициализации
Ещё один полезный ресурс — руководство по написанию сценариев инициализации служб для OpenRC.
Это необходимо?
Нет, написание сценариев инициализации обычно не требуется, так как Gentoo содержит готовые сценарии для всех предоставляемых служб. Однако некоторые пользователи могут установить какую-либо службу, не используя систему Portage; в таком случае, вероятно, придётся создать сценарий самостоятельно.
Не используйте сценарий инициализации, идущий со службой, если он не написан специально для Gentoo: сценарии Gentoo не совместимы со сценариями, используемыми в других дистрибутивах! То есть, если другой дистрибутив не использует OpenRC!
Структура
Основная структура сценария инициализации показана ниже.
#!/sbin/openrc-run
depend() {
# (Информация о зависимостях)
}
start() {
# (Команды, необходимые для запуска службы)
}
stop() {
# (Команды, необходимые для остановки службы)
}
#!/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.
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, как на пример такого сценария инициализации.
depend() {
need net
before inetd
before xinetd
}
Также можно использовать знак "*", чтобы охватить все службы данного уровня запуска, хотя это не рекомендуется.
depend() {
before *
}
Если службе необходима возможность записывать данные на локальные диски, она должна потребовать localmount. Если она что-либо поместит в /var/run/, например, PID-файл, она должна запускаться после bootmisc:
depend() {
need localmount
after bootmisc
}
Стандартные функции
Следом за разделом depend()
потребуется определить функцию start()
. В ней содержатся все команды, необходимые для запуска службы. Рекомендуется применять функции ebegin
и eend
для сообщений пользователю о том, что происходит:
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()
, пожалуйста, прочитайте исходный код сценариев, находящихся в каталоге /etc/init.d/.
Еще одной функцией, которую можно определить (но не обязательно это делать), является stop()
. Система init, применяемая нами, достаточно развита и в состоянии самостоятельно заполнить эту функцию, если используется start-stop-daemon.
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:
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 — команду можно запустить, когда служба остановлена
extra_started_commands="restartdelay"
restartdelay() {
stop
sleep 3 # пауза в 3 секунды перед повторным запуском
start
}
Функция
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:
rc_hotplug="net.wlan !net.*"
Для более детальной информации о службах, инициируемых устройствами, просмотрите комментарии в /etc/rc.conf.
Теперь необходимо отредактировать конфигурацию загрузчика, добавив новую запись для уровня запуска offline. В данной записи добавьте softlevel=offline
в качестве параметра загрузки.
Использование загрузочного уровня (bootlevel)
Использование загрузочного уровня полностью аналогично использованию программного уровня. Единственная разница состоит в том, что определяется второй уровень boot вместо второго уровня default.
Переменные окружения
Введение
Переменная окружения — это именованный объект, который содержит определения, используемые одним или несколькими приложениями. Используя переменные окружения, можно очень легко изменить настройки для одного или нескольких приложений.
Наиболее важные переменные
В следующей таблице перечислен ряд переменных, используемых в системе 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/. Внутри каталога есть несколько файлов, такие как 50baselayout, gcc/config-x86_64-pc-linux-gnu и так далее, которые содержат переменные, необходимые программе из названия файла.
Например, когда установлен gcc, ebuild создает файл с названием gcc/config-x86_64-pc-linux-gnu, который содержит определения следующих переменных:
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) и написать необходимое определения в нём:
http_proxy="proxy.server.com:8080"
Используя один и тот же файл для всех пользовательских переменных можно получить компактный список переменных, которые были определены пользователем самостоятельно.
env-update
Несколько файлов в /etc/env.d/ определяют переменную PATH. Это не ошибка: когда выполняется команда env-update, она добавит другие определения перед обновлением переменного окружения, что позволяет просто добавлять для пакетов (или пользователей) свои собственные настройки переменного окружения без вмешательство в уже существующие значениями.
Сценарий env-update добавляет значения из файлов /etc/env.d/ в алфавитном порядке. Имена файлов должны начинаться с двух десятичных чисел.
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
Команда выше обновит переменные только для текущего терминала, в новых консолях и их потомках. Таким образом, если пользователь работает в X11, ему нужно либо вводить source /etc/profile в каждом новом открытом терминале, либо перезагрузить X, так все новые терминалы получили новые переменные. Если используется менеджер входа, то необходимо стать root и перезагрузить сервис /etc/init.d/xdm.
Нельзя использовать переменные оболочки для определения других переменных. Это означает, что такие вещи как
FOO="$BAR"
(где $BAR это другая переменная) запрещены.Определение переменных локально
Для пользователя
Не всегда нужно определять переменную окружения на глобальном уровне. Например, кому-то может понадобится добавить /home/my_user/bin и текущий рабочий каталог (каталог в котором находится пользователь) в переменную PATH, но не нужно чтобы все другие пользователи получили такой же PATH. Для определения переменной окружения локально, используйте ~/.bashrc или ~/.bash_profile:
# 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"
Warning: Display title "Gentoo Linux ppc64 Handbook: Работа с Gentoo" overrides earlier display title "Handbook:PPC64/Full/Working".