
- •Расширенные возможности Portage
- •А. Установка Gentoo
- •1. Об установке Gentoo Linux
- •1.А. Введение.
- •2. Выбор правильного источника установки.
- •2.А. Требования к железу
- •2.B. Установочные cd Gentoo
- •2.С. Скачайте, запишите, и загрузитесь с установочного cd Gentoo
- •3. Конфигурация сети
- •3.A. Автоматическое определение сети
- •3.B. Автоматическая конфигурация сети
- •3.С. Ручная настройка сети
- •4. Подготовка дисков
- •4.A. Введение в блочные устройства
- •4.B. Разрабатываем схему разделов
- •4.C. Использование fdisk для разбивки вашего диска
- •4.D. Использование parted для разбивки вашего диска
- •4.E. Создаем файловые системы
- •4.F. Монтирование
- •5. Установка файлов Gentoo
- •5.A. Устанавливаем tar-архив Stage3
- •5.B. По умолчанию: Используем Stage3 из Интернета
- •5.C. Устанавливаем Portage
- •5.D. Настройка опций компиляции
- •6. Установка базовой системы Gentoo
- •6.A. Чрутинг
- •6.B. Конфигурируем Portage
- •7. Конфигурация ядра
- •7.A. Временная зона
- •7.B. Устанавливаем исходники
- •7.C. По умолчанию: Ручная конфигурация
- •7.D. Альтернатива: Используем genkernel
- •7.E. Модули ядра
- •8. Конфигурация системы
- •8.A. Информация о файловой системе
- •8.B. Информация о сети
- •8.C. Системная информация
- •9. Установка необходимых системных приложений
- •9.A. Системный логгер
- •9.B. Опционально: Демон Cron
- •9.C. Опционально: Индексация файлов
- •9.D. Опционально: Удаленный Доступ
- •9.E. Программы работы с файловой системой
- •9.F. Программы работы с сетью
- •10. Конфигурация загрузчика
- •10.A. Делаем выбор
- •10.B. По умолчанию: Используем grub
- •10.C. Альтернатива: Используем lilo
- •10.D. Перезагружаем систему
- •11. Окончание установки Gentoo
- •11.A. Работа с пользователями
- •11.B. Очистка диска
- •12. Куда идти дальше?
- •12.A. Документация
- •12.B. Gentoo в сети
- •B. Работа с Gentoo
- •1. Введение в Portage
- •1.A. Добро пожаловать в Portage
- •1.B. Дерево Portage
- •1.C. Поддержка приложений
- •1.D. Лицензии
- •1.E. Когда Portage ругается...
- •2.A. Что такое use-флаги?
- •2.B. Использование use-флагов
- •3. Возможности Portage
- •3.A. Возможности Portage
- •3.B. Распределенная компиляция
- •3.C. Кеширование компиляции
- •3.D. Поддержка бинарных пакетов
- •3.E. Скачивание файлов
- •3.F. Загрузка проверенных образов дерева Portage
- •4. Инициализационные скрипты
- •4.A. Уровни запуска
- •4.B. Работаем с rc-update
- •4.C. Конфигурирование сервисов
- •4.D. Пишем инициализационные скрипты
- •4.E. Изменение поведения уровня запуска
- •5. Переменные окружения
- •5.A. Переменные окружения?
- •5.B. Определение переменных глобально
- •5.C. Определение переменных локально
- •C. Работа с Portage
- •1. Файлы и каталоги
- •1.A. Файлы Portage
- •1.B. Сохраненные файлы
- •1.C. Компиляция приложений
- •1.D. Возможности логгинга
- •2. Конфигурирование через переменные
- •2.A. Конфигурация Portage
- •2.B. Опции, специфичные для компиляции
- •2.C. Защита файлов конфигурации
- •2.D. Опции скачивания
- •2.E. Конфигурация Gentoo
- •2.F. Поведение Portage
- •3. Смешение веток приложений
- •3.A. Использование одной ветви
- •3.B. Смешиваем стабильную ветку и ветку для тестирования
- •3.C. Используем замаскированные пакеты
- •4. Дополнительные программы для Portage
- •5. Отход от официального дерева
- •5.A. Использование поднабора дерева Portage
- •5.B. Добавляем неофициальные ебилды
- •5.C. Приложения, не обрабатываемые Portage
- •6. Расширенные возможности Portage
- •6.A. Введение
- •6.B. Переменные окружения для каждого пакета
- •6.C. Вмешиваемся в процесс установки
- •6.D. Выполняем задачи после --sync
- •6.E. Изменяем настройки профиля
- •6.F. Применение нестандартных патчей
- •D. Конфигурация сети Gentoo
- •1. Начинаем
- •1.A. Начинаем
- •2. Расширенная конфигурация
- •2.A. Расширенная конфигурация
- •2.B. Сетевые зависимости
- •2.C. Имена и значения переменных
- •3. Модульная сеть
- •3.A. Сетевые модули
- •3.B. Обработчики интерфейсов
- •3.F. Связывание
- •3.G. Мосты (Поддержка 802.1d)
- •3.I. Туннелирование
- •3.J. Vlan (Поддержка 802.1q)
- •4. Беспроводные сети
- •4.A. Введение
- •4.D. Определение конфигурации сети на каждый essid
- •5. Добавление функциональности
- •5.A. Хуки стандартных функций
- •5.B. Хуки функций Wireless Tools
- •6. Обслуживание сети
- •6.A. Обслуживание сети
4.B. Работаем с rc-update
Что такое rc-update?
Инициализационная система Gentoo использует дерево зависимостей, чтобы решить, какой сервис должен быть запущен первым. Так как такую сложную задачу мы бы не хотели давать пользователям делать вручную, мы создали инструменты, которые упрощают администрирование уровней запуска и инициализационных скриптов.
С помощью rc-update вы можете добавлять и удалять инициализационные скрипты к уровню доступа. Программа rc-update затем автоматически попросит depscan.sh перестроить дерево зависимостей.
Добавляем и удаляем сервисы
Вы уже добавляли инициализационные скрипты к уровню запуска «default» в течение установки Gentoo. В то время вы, наверное, не знали, что означает «default», но теперь вы знаете. Скрипт rc-update требует второй аргумент, который определяет действие — add, del или show.
Чтобы добавить или удалить инициализационный скрипт, просто дайте rc-update аргумент add или del, за которым идет имя инициализационного скрипта и уровень запуска. Например:
Код 2.1: Удаляем Postfix с уровня запуска Default |
# rc-update del postfix default |
Команда rc-update -v show покажет все существующие инициализационные скрипты, и список, на каких уровнях запуска они будут выполнены:
Код 2.2: Получаем информацию об инициализационных скриптах |
# rc-update -v show |
Вы также можете запустить rc-update show (без -v) чтобы просто просмотреть включенные инициализационные скрипты и их уровни запуска.
4.C. Конфигурирование сервисов
Зачем нужна дополнительная конфигурация?
Инициализационные скрипты могут быть достаточно сложными. Поэтому не нужно, чтобы пользователи редактировали инициализационные скрипты явно, так они будут более защищены от ошибок. Однако важно уметь конфигурировать такие скрипты. Например, вы можете захотеть дать больше опций самому сервису.
Второй причиной иметь конфигурацию вне инициализационного скрипта является возможность обновить инициализационные скрипты без страха того, что ваши изменения в конфигурации будут отменены.
Каталог /etc/conf.d
Gentoo дает легкий способ для конфигурации сервиса: каждый инициализационный скрипт, который может быть сконфигурирован, имеет файл в /etc/conf.d. Например, инициализационный скрипт apache2 (называемый /etc/init.d/apache2) имеет конфигурационный файл, называемый /etc/conf.d/apache2, который может содержать опции, которые вы хотите передать серверу Apache2 при запуске:
Код 3.1: Переменная, определенная в /etc/conf.d/apache2 |
APACHE2_OPTS="-D PHP5" |
Такой конфигурационный файл содержит только переменные (почти как /etc/make.conf), что делает очень простым занятием конфигурирование сервисов. Он также позволяет дать больше информации о переменных (как комментарии).
4.D. Пишем инициализационные скрипты
А мне нужно?
Нет, написание инициазационного скрипта обычно не нужно, так как Gentoo дает уже готовые для использования инициализационные скрипты для всех сервисов. Однако, вы можете установить сервис без использования Portage. В таком случае вы, скорее всего, должны будете создать инициализационный скрипт.
Не используйте инициализационный скрипт, который идет с сервисом, если он не написан специально для Gentoo: инициализационные скрипты Gentoo не совместимы с инициализационными скриптами, используемыми другими дистрибутивами!
Структура
Базовая структура инициализационного скрипта показана ниже:\
Код 4.1: Базовая структура инициализационного скрипта |
#!/sbin/runscript
depend() { (Информация о зависимостях) }
start() { (Команды, необходимые для запуска сервиса) }
stop() { (Команды, необходимые для остановки сервиса) } |
Любой инициализационный скрипт требует определения функции start(). Все остальные секции являются опциональными.
Зависимости
Существует две настройки, работающие с зависимостями, которые вы можете определить, и они будут влиять на порядок запуска инициализационных скриптов: use и need. Кроме этих двух, существует также еще два влияющих на порядок загрузки метода, называющиеся before и after. Последние два, в общем, определяют даже и не зависимости, они не заставят выдать ошибку скрипт, если тот скрипт, что в них описан вообще не должен запуститься (или не запустится).
Настройка use информирует систему init, что данный скрипт использует функциональность некоторого скрипта, но не строго от него зависит. Хорошим примером будет use logger или use dns. Если эти сервисы есть, они будут хорошо использоваться, но если у вас нет логгера, или DNS-сервера, сервисы все равно будут работать. Если сервисы существуют, они будут запущены до того, как запустится скрипт, использующий их.
Настройка need это жесткая зависимость. Она означает, что скрипт, которому нужен другой скрипт, не запустится, пока другой скрипт не запустится успешно. Также, если другой скрипт будет перезапущен, то этот тоже будет перезапущен.
При использовании before, данный скрипт запускается до некоторого скрипта, если выбранный скрипт это часть того же уровня. Так, инициализационный скрипт xdm, который определен до alsasound будет запущен до скрипта alsasound, но только если alsasound запланирован запуститься на том же уровне. Если alsasound не запланирована запуститься, то эта конкретная настройка не будет иметь эффекта, и xdm запустится в тот момент времени, который система init посчитает лучшим вариантом.
Похожим образом, after информирует систему init, что данный скрипт нужно запустить после некоторого скрипта, если выбранный скрипт является частью того же уровня. Если нет, то настройка не имеет эффпекта, и скрипт будет запущен системой init в момент времени, который, как она посчитает, будет наилучшим.
Из вышенаписанного должно быть ясно, что need это единственная «действительная» настройка о зависимостях, так как она влияет на то, будет ли запущен скрипт или нет. Все остальные являются больше указателями системе init, говорящими в каком порядке скрипты могут (или должны) запускаться.
Теперь, если вы посмотрите на многие из существующих инициализационных скриптов Gentoo, вы заметите, что некоторые из них имеют зависимости от вещей, которые не являются инициализационными скриптами. Эти «вещи» мы называем виртуалами.
Виртуальная зависимость это зависимость, которую дает сервис, но она не дается только этим сервисом. Ваш инициализационный скрипт может зависеть от системного логгера, но существует много системных логгеров (metalogd, syslog-ng, sysklogd, …). Так как вы не можете хотеть какой-то один из них (ни одна система не имеет все эти логгеры установленными и запущенными), мы удостоверились, что все эти сервисы дают виртуальную зависимость.
Давайте посмотрим на информацию о зависиости для сервиса postfix:
Код 4.2: Информация о зависимостях для 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 как на пример такого инициализационного скрипта.
Код 4.3: Функция depend() в сервисе Portmap |
depend() { need net before inetd before xinetd } |
Вы также можете использовать «*». Это будет означать все сервисы на том же уровне запуска, хотя это и не рекомендуется.
Код 4.4: Запускаем инициализационный скрипт как первый скрипт на уровне запуска |
depend() { before * } |
Если ваш сервис должен писать на локальные диски, он должен потребовать localmount. Если он что-либо поместит в /var/run, например пид-файл, тогда он должен запускаться после bootmisc:
Код 4.5: Пример функции depend() |
depend() { need localmount after bootmisc } |
Стандартные функции
Кроме функции depend() вам нужно также определить функцию start(). Она будет содержать все команды, необходимые для инициализации вашего сервиса. Рекомендуется использовать функции ebegin и eend, чтобы проинформировать пользователя о том, что происходит.
Код 4.6: Пример функции start() |
start() { if [ "${RC_CMD}" = "restart" ]; then # Do something in case a restart requires more than 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. Если сервис не создает пид-файл, тогда используйте --make-pidfile, если возможно, хотя вы должны протестировать это, чтобы быть уверенным. Иначе, не используйте пид-файлы. Вы также можете добавить --quiet к опциям start-stop-daemon, но это не рекомендуется, если только сервис не очень многословный. Использование --quiet может скрыть информацию если сервис не сможет запуститься.
Другой интересной настройкой, используемой в вышеприведенном примере является проверка содержимого переменной RC_CMD. В отличие от предыдущей инициализационной системы, новая система openrc не поддерживает отдельную функциональность restart для каждого скрипта. Вместо этого, скрипт должен проверить содержимое переменной RC_CMD, чтобы проверить, вызывается ли функция (как start(), так и stop()) как часть restart, или нет.
Заметка: Удостоверьтесь, что --exec действительно вызывает сервис, а не шелл-скрипт, который запускает сервисы и выходит — это должен делать сам инициализационный скрипт. |
Если вам нужно больше примеров функции start(), пожалуйста, прочитайте исходный код существующих инициализационных скриптов в вашей директории /etc/init.d.
Другой функцией, которую вы можете определить, является stop(). Вы не обязаны определять эту функцию! Наша система инициализации достаточно умна, чтобы заполнить эту функцию сама, если вы использовали start-stop-daemon.
Вот пример функции stop():
Код 4.7: Пример функции 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:
Код 4.8: Сервис, который запускает скрипт 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-страницу, которую вы можете посмотреть, если вам нужна дополнительная информация.
Код 4.9: Получаем man-страницу для start-stop-daemon |
$ man start-stop-daemon |
Синтаксис инициализационных скриптов Gentoo основан на Bourne Again Shell (bash), так что вы вольны использовать bash-совместимые конструкции в вашем инициализационном скрипте. Однако вы можете захотеть написать ваши инициализационные скрипты, чтобы они были POSIX-совместимыми. Будущие системы инициализационных скриптов могут позволить изменить символическую ссылку /bin/sh, чтобы она указывала на другие шеллы, кроме bash. Инициализационные скрипты, которые основаны на возможностях только bash на таких конфигурациях могут отказаться работать.
Добавляем дополнительные опции
Если вы хотите, чтобы ваш инициализационный скрипт поддерживал больше опций, чем те, которые мы уже описали, вам нужно добавить опцию к переменной extra_commands, и создать функцию с тем же именем, как и опция. Например, чтобы поддерживать опцию с именем restartdelay:
Код 4.10: Поддержка опции restartdelay |
extra_commands="restartdelay"
restartdelay() { stop sleep 3 # Wait 3 seconds before starting again start } |
Важно: Функция restart() не может быть переназначена в openrc! |
Переменные конфигурирования сервиса
Вам не нужно ничего делать, чтобы появилась поддержка файла конфигурации в /etc/conf.d: если ваш инициализационный скрипт выполняется, следующие файлы автоматически подключаются (то есть, переменные становятся возможными для использования):
/etc/conf.d/<ваш_инициализационный_скрипт>
/etc/conf.d/basic
/etc/rc.conf
Кроме того, если ваш инициализационный скрипт имеет виртуальную зависимость (такую как net), то файл, ассоциированный с этой зависимостью (такой, как /etc/conf.d/net) тоже можно будет использовать.