Описание политики Debian (операционная система) — Глава 3

1. Иерархия файловой системы

1.1. Структура файловой системы Linux

Расположение всех установленных файлов и каталогов должно соответствовать Иерархическому Стандарту Файловой системы Linux (FHS). Последнюю версию этого документа можно найти рядом с этим руководством или в http://www.pathname.com/fhs/.

Конкретные вопросы о стандарте можно задать в debian-devel, или обратиться к Daniel Quinlan, координатору FHS quinlan@pathname.com.

1.2. Программы конкретного рабочего места

По определению FHS, ни один пакет не должен размещать любые файлы в /usr/local, или помещать их в архив файловой системы для распаковки с помощью dpkg или работать с ними из своих сопровождающих сценариев.

Однако, пакет должен создавать пустые каталоги ниже /usr/local, так чтобы администратор системы знал где размещаются файлы данного рабочего места. Эти каталоги должны стираться при удалении пакета, если они становятся пустыми.

Заметим, что это применимо только к каталогам лежащим ниже /usr/local, но не в /usr/local. Сам каталог /usr/local может содержать только подкаталоги, описанные в FHS. Однако, ты можешь создавать каталоги ниже него как захочешь. Ты не можешь удалять любые каталоги, даже если ты создавал их.

Т.к. /usr/local может монтироваться только для чтения с удалённого сервера, то эти каталоги будут создаваться и удаляться при помощи сценариев сопровождения postinst и prerm. Сценарии не должны не должны выходить из строя, даже если одна из этих операций завершится неудачно. (В будущем, станет возможно указать dpkg не распаковывать файлы соответствующие определённым шаблонам, для того чтобы каталоги можно было включать в пакеты .deb и те администраторы системы, которые не хотят иметь эти каталоги в /usr/local не будут их иметь.)

Например, пакет emacs будет содержать

mkdir -p /usr/local/lib/emacs/site-lisp || true

в сценарии postinst, и

rmdir /usr/local/lib/emacs/site-lisp && \

rmdir /usr/local/lib/emacs || \

true

в сценарии prerm.

Если ты создаёшь каталог в /usr/local для дополнений пакета, то ты должен гарантировать, что эти настройки /usr/local имеют преимущество над эквивалентными в /usr.

Однако, т.к. ‘/usr/local’ и его содержимое предназначено для монопольного использования локальным администратором, то пакет при нормальной работе не должен полагаться на наличие или отсутствие файлов или каталогов в ‘/usr/local’.

Сам каталог /usr/local и все подкаталоги созданные пакетом, должны иметь права доступа 2775 (разрешена запись группе и set-group-id) и владельца root.staff.

2. Пользователи и группы

Система Debian может быть настроена на использование или простых или теневых паролей.

Несколько идентификаторов пользователей (UIDs) и идентификаторов групп (GIDs) зарезервированы для глобального использования в определенных пакетах. Т.к. внекоторые пакеты необходимо включать файлы, которыми владеют эти пользователи или группы, или необходимы идентификаторы для компиляции в исполняемые файлы, то такие идентификаторы должны использоваться в любой системе Debian только для тех целей для которых они предназначены. Это серьёзное ограничение, и мы должны избегать вводить их в локальные административные правила. В частности, многие сайты выделяют идентификаторы для пользователей и/или для локальных групп системы начиная с 100.

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

Ни один пакет, за исключением base-passwd, не может изменять /etc/passwd, /etc/shadow, или /etc/group.

Диапазоны UID и GID следующие:

0-99:

Глобально выделенный проектом Debian, должен быть одинаков в каждой системе Debian. Эти идентификаторы находятся в файлах passwd и group во всех системах Debian, новые идентификаторы в этом диапазоне будут добавлены автоматически при обновлении пакета base-passwd.

Пакеты, которым нужен один статически выделяемый uid или gid должны использовать один из них; их сопровождающие должны попросить у сопровождающего base-passwd идентификатор.

100-999:

Динамически выделяемые системой пользователи и группы. Пакеты, которым нужен пользователь или группа, но этот пользователь или группа может выделяться динамически и может быть различна в каждой системе, должны использовать `apuser --system‘ для создания группы и/или пользователя.

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

1000-29999:

Динамически выделяемые бюджеты пользователей. По умолчанию apuser выбирает UIDs и GIDs для бюджетов пользователей из этого диапазона, хотя можно использовать apuser.conf для изменения такого поведения.

30000-59999:

Зарезервировано.

60000-64999:

Глобально выделенный проектом Debian, но создаваемый только по требованию. Эти идентификаторы выделяются централизовано и статически, но настоящие бюджеты создаются только на пользовательских системах по требованию.

Это идентификаторы для неизвестных пакетов, или которым необходимо много статически выделенных идентификаторов. Эти пакеты, если необходимо, должны проверять и создавать бюджеты в /etc/passwd или /etc/group (используя apuser, если возможно). Пакеты, которым вероятно необходимо и дальше выделять, должны иметь `дыру’ слева от них в выделении, чтобы дать место для роста.

65000-65533:

Зарезервировано.

65534:

Пользователь `nobody.’

65535:

(uid_t)(-1) == (gid_t)(-1). НЕ ДОЛЖЕН ИСПОЛЬЗОВАТЬСЯ, потому что это охранное возвращаемое сообщение об ошибке.

3. Уровни выполнения системы

3.1. Введение

Каталог /etc/init.d содержит сценарии, запускаемые init во время загрузки и когда меняется начальное состояние (или `уровень выполнения’) (смотри init(8)).

Существует по крайней мере два различных, таких же функционально равных, путей манипулирования этими сценариями. Ради простоты, этот документ описывает только метод символических ссылок. Однако, нельзя предполагать, что был использован этот метод, и любое управление поведением различных уровней выполнения должно выполняться с использованием update-rc.d как описано ниже, а не ручной установкой символических ссылок. Подробную информацию о реализации других методов, включённых в пакет file-rc, смотри в документации к этому пакету.

На эти сценарии указывают символические ссылки из каталогов /etc/rcn.d. Когда уровень выполнения изменяется, init ищет в каталоге /etc/rcn.d сценарии для запуска, где n является уровнем выполнения, который был изменён, или `S’ для сценариев начальной загрузки.

Все имена ссылок имеют форму Smmscript или Kmmscript, где mm это двух разрядное число и script это имя сценария (оно должно совпадать с именем настоящего сценария в /etc/init.d.

Когда init изменяет уровень выполнения, то сначала он запускает ссылки, начинающиеся на K, каждую с одним аргументом stop, затем сценарии, начинающиеся на S, каждый с одним аргументом start. Ссылки K отвечают за отключение сервисов, а ссылки S за запуск сервисов, которые нужны на новом уровне.

Например, если мы изменяем уровень выполнения 2 на уровень выполнения 3, init выполнит сначала все сценарии начинающиеся на K, какие найдёт в /etc/rc3.d, и затем все сценарии начинающиеся на S. Ссылки, начинающиеся с K будут вызваны с аргументом stop, и S ссылки с аргументом start.

Двух разрядное число mm используется для определения в каком порядке запускать и останавливать сценарии, с наименьшим номером запускаются первыми. Например, сценарий K20 выполнится перед сценарием K30. Это используется когда определёный сервис должен быть запущен перед другим. Например, сервер имён bind может понадобиться запустить перед сервером новостей inn для того чтобы inn мог настроить свои списки доступа. В этом случае, сценарий, который запускает bind должен иметь меньший номер чем сценарий, запускающий inn, так это будет работать:

/etc/rc2.d/S17bind

/etc/rc2.d/S70inn

3.2. Написание сценариев

Пакеты могут и должны размещать сценарии в /etc/init.d для запуска или останова сервисов во время загрузки или при изменении уровня выполнения. Эти сценарии должны иметь названия /etc/init.d/пакет, и они должны принимать один аргумент, говорящий что делать:

• start — запустить сервис
• stop — остановить сервис
• restart — остановить и перезапустить сервис
• reload — настройка сервиса должна загружена заново без останова и перезапуска сервиса,
• force-reload — настройка сервиса должна загружена заново, если сервис поддерживает это, иначе перезапуск сервиса.

Опции start, stop, restart, и force-reload должны поддерживаться всеми сценариями в /etc/init.d, опция reload необязательна.

Сценарии init.d должны гарантировать, что они будут вести себя разумно, если вызываются с start при уже запущенном сервисе, или с stop когда нет, и что они не убьют несчастливо названные пользовательские процессы. Лучший способ достигнуть этого обычно это использовать start-stop-daemon.

Если сервис перезагружает свои настройки автоматически (как в случае с cron, например), то опция reload для сценария из init.d должна вести себя как если бы настройки перезагрузились успешно.

Эти сценарии не должны незаметно завершаться неудачно когда файлы настроек остаются, а пакет был удалён, т.к. файлы настроек остаются в системе после удаления пакета. Файлы настроек удаляются только когда dpkg выполняется с опцией --purge. В частности, сам сценарий init это обычный файл настроек, и он останется в системе, если пакет будет удалён, но не было очистки. Поэтому, ты должен включать оператор test с начало сценария, например так:

test -f программа-выполняемая-позже-в-сценарии || exit 0

3.3. Управление ссылками

Программа update-rc.d обеспечивает лёгкую работу для сопровождающих пакетов по правильному созданию и удалению символических ссылок /etc/rcn.d, или их функциональных эквивалентов, если используется другой метод. Она может использоваться сопровождающими в сценариях своих пакетов postinst и postrm.

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

По умолчанию update-rc.d запускает сервисы в каждом из многопользовательских состояний уровней выполнения (2, 3, 4, и 5) и останавливает их в уровне выполнения останова (0), однопользовательском уровне выполнения (1) и уровне выполнения перезагрузки (6). Администратор системы имеет удобную возможность переделать уровни выполнения или запустив update-rc.d, для простого добавления, перемещения, или удаления символических ссылок в /etc/rcn.d, если используются символические ссылки, или модифицировав /etc/runlevel.conf, если используется file-rc метод.

Чтобы задать поведение по умолчанию для своего пакета помести в свой postinst сценарий

update-rc.d package defaults >/dev/null

и в postrm

if [ purge = "$1" ]; then

update-rc.d package remove >/dev/null

fi

Будет задействована последовательность по умолчанию с номером 20. Если неважно когда или в каком порядке запускать сценарий, оставь так. Если важно, то ты должен поговорить с сопровождающим пакета sysvinit или через debian-devel, и они помогут тебе выбрать номер.

Подробную информацию об использовании update-rc.d смотри в man странице update-rc.d(8).

3.4. Инициализация во время запуска машины

Для этого используется другой каталог, /etc/rc.boot, который содержит сценарии, запускаемые только во время загрузки машины. Есть возражения против полезности ссылок из /etc/rcS.d на файлы в /etc/init.d как описывалось в введение. Никакой пакет не может помещать файлы в /etc/rc.boot.

3.5. Замечания

Не включай символические ссылки /etc/rcn.d/* в архив файлов системы .deb! Возникнут проблемы! Ты должен создавать их с помощью update-rc.d, как описывалось выше.

Не включай символические ссылки /etc/rcn.d/* в список conf_файлов dpkg! Возникнут проблемы! однако, относись к сценариям /etc/init.d как файламнастройки, или пометив их как conf_файлы или правильно обращайся с ними в сопровождающих сценариях. (Это важно, т.к. мы хотим дать шанс конечному системному администратору адаптировать сценарии под локальную систему—например, отключить сервис без демонтажа пакета, или задать некоторые специальные опции командной строки во время запуска сервиса—чтобы быть уверенным что её изменения не исчезнут при следующем обновлении пакета.)

3.6. Пример

Пакет bind DNS (сервер имен) хочет убедиться, что сервер имен запускается в многопользовательском уровне выполнения, и правильно прекратить работу вместе с системой. Он помещает сценарий в /etc/init.d, под соответствующим именем bind. Как ты можешь видеть, сценарий понимает аргумент reload и посылает серверу имен сигнал HUP (вызывающий перезагрузку его настроек); таким образом пользователь может сказать /etc/init.d/bind reload чтобы перезагрузить сервер имен.

#!/bin/sh

#

# Первоначальная версия Robert Leslie

# <rob@mars.org>, редактировал iwj и cs



test -x /usr/sbin/named || exit 0



case "$1" in

start)

echo -n "Запуск доменного сервиса имен: named"

start-stop-daemon --start --quiet --exec /usr/sbin/named

echo "."

;;

stop)

echo -n "Останов доменного сервиса имен: named"

start-stop-daemon --stop --quiet  \

--pidfile /var/run/named.pid --exec /usr/sbin/named

echo "."

;;

restart)

echo -n "Перезапуск доменного сервиса имен: named"

start-stop-daemon --stop --quiet  \

--pidfile /var/run/named.pid --exec /usr/sbin/named

start-stop-daemon --start --verbose --exec /usr/sbin/named

echo "."

;;

force-reload|reload)

echo -n "Перезагрузка настроек доменного сервиса имен: named"

start-stop-daemon --stop --signal 1 --quiet  \

--pidfile /var/run/named.pid --exec /usr/sbin/named

echo "."

;;

*)

echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2

exit 1

;;

esac



exit 0

Другим примером, на котором должны основываться твои сценарии /etc/init.d может служить /etc/init.d/skeleton.

Если этот пакет устраивает установка по умолчанию из update-rc.d, т.е. порядковый номер 20 и named запускается во всех уровнях выполнения, то можно написать в его postinst:

update-rc.d bind defaults >/dev/null

И в его postrm, чтобы удалить ссылки, когда пакет очищается:

if [ purge = "$1" ]; then

update-rc.d acct remove >/dev/null

fi

4. Задания cron

Пакеты не могут изменять файл настройки /etc/crontab, также как и не могут изменять файлы в /var/spool/cron/crontabs.

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

/etc/cron.daily

/etc/cron.weekly

/etc/cron.monthly

Как и означает имя каталога, файлы в них выполняются ежедневно, еженедельно, или ежемесячно соответственно. Точное время записано в /etc/crontab.

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

Если какое-то задание должно выполняться чаще чем раз в день, то пакет должен создать файл /etc/cron.d/имя-пакета. Этот файл использует похожий на /etc/crontab синтаксис и выполняется cron автоматически. Файл должен также восприниматься как файл настройки. (Заметим, что записи в каталоге /etc/cron.d не обрабатываются anacron. Поэтому, ты должен использовать только этот каталог для заданий, которые могут быть пропущены если система не запускается.)

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

5. Консольные сообщения

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

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

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

• Каждое сообщение должно занимать одну строку, начинаться с заглавной буквы и заканчиваться точкой `.’.
• Если нужно показать, что компьютер над чем-то задумался (выполняя специальную задачу, не запуская или останавливая программу), мы используем «эллипс», т.е. три точки `…’. Заметим, что мы не вставляем пробелы в начале и конце точек. Если задача завершилась, мы пишем `done.’ и переходим на другую строку.
• Составляй свои сообщения, как если компьютер говорил тебе что он делает (позволь ему быть вежливым 🙂 но не воспринимай «его» буквально. Например, если ты хочешь сказать «Я запускаю демонов сети: nfsd mountd», то просто скажи «Запуск демонов сети: nfsd mountd»

Вот какие форматы должны использоваться

1. Для запуска демонов. Используй этот формат, если твой сценарий запускает один и более демонов. Вывод должен выглядеть так (одна строка, без пробелов в начале):

Starting <описание>: <демон-1> <демон-2> <...> <демон-n>.

<Описание> должно описывать подсистему демонов или часть набора демонов, начиная с <демон-1> до <демон-n> означающие имя каждого демона (обычно имя файла программы).

Например, вывод /etc/init.d/lpd будет выглядеть так:

Starting printer spooler: lpd.

Этого можно достичь написав в сценарии:

echo -n "Starting printer spooler: lpd"

start-stop-daemon --start --quiet lpd

echo "."

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

echo -n "Starting remote file system services:"

echo -n " nfsd"; start-stop-daemon --start --quiet nfsd

echo -n " mountd"; start-stop-daemon --start --quiet mountd

echo -n " ugip"; start-stop-daemon --start --quiet ugip

echo "."

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

2. Когда что-то нужно настроить. Если ты устанавливаешь различные параметры системы во время загрузки, ты можешь использовать такой формат:

Setting <параметр> to `<значение>'.

Ты можешь использовать следующий оператор echo, чтобы получить правую кавычку:

echo "Setting DNS domainname to \`"value"'."

Заметим, что левая кавычка (`) отличается от правой (‘).

3. Когда демон останавливается. Когда ты останавливаешь демона, ты должен выдать сообщение подобное сообщению при запуске, за исключением того что `Starting’ заменяется на `Stopping’.

Так останавливается демон принтера:

Stopping printer spooler: lpd.

4. Когда что-то выполняется. Есть несколько примеров, где нужно запускать программу во время запуска системы или завершения её работы для выполнения специальной задачи. Например, установка системных часов через `netdate’ или убить все процессы при завершении работы системы. Твоё сообщение должно выглядеть так:

Делаем что-то очень полезное...done. 

Ты должен печатать `done.’ сразу после завершения выполнения работы, для того чтобы пользователь знал причину задержки. Ты можешь получить такое поведение с помощью

echo -n "Делаем что-то очень полезное..."

do_something

echo "done."

в своём сценарии.

5. Когда настройка перезагружается. Когда демон принудительно перезагружает свои файлы настроек, ты должен использовать следующий формат:

Reloading <daemon's-name> configuration...done.

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

6. Меню

Элементы меню должны соответствовать текущей политике меню как определено в файле на /debian/doc/package-developer/menu-policy.txt или на твоём локальном зеркале. Также, он включён в пакет debian-policy.

Debian пакет menu обеспечивает уникальный интерфейс между пакетами с приложения и документами и программами меню (или менеджерами X window или текстовыми программами меню типа pdmenu).

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

Пожалуйста, посмотри документ Система Меню Debian, который есть в пакете menu о том как зарегистрировать своё приложение и web документы.

7. Обработчики мультимедиа

Пакеты, которые способны отображать/показывать/играть, составлять, редактировать или печатать MIME типы должны сами зарегистрироваться также как и существующие в правилах поддержки MIME, как определено в файле, который можно найти на /debian/doc/package-developer/mime_policy.txt или на локальном зеркале. Также, он включён в пакет debian-policy.

MIME (Многоцелевые Расширения Электронной Почты, RFC 1521) это механизм для кодирования файлов и потоков данных и хранение мета информации о них, в частично своих типах (например, аудио или видео) и форматах (например, PNG, HTML, MP3).

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

8. Настройка клавиатуры

Для достижения совместимости настроек клавиатуры (т.е., все приложения интерпретируют клавиатурные события одинаково) все программы в дистрибутиве Debian настраиваются в соответствии со следующими общими принципами.

Здесь список, содержащий определённые клавиши и их интерпретации:

<--

удаляет символ слева от курсора

Delete

удаляет символ справа от курсора

Control+H

emacs: префикс помощи

Интерпретация любых клавиатурных последовательностей должна быть независимой от используемого терминала виртуальной консоли, X эмулятора терминала, сеанса rlogin/telnet, и т.д.

Следующий список объясняет как настроить различные программы чтобы достичь этого:

• `<--‘ генерирует KB_Backspace в X.
• `Delete‘ генерирует KB_Delete в X.
• X трансляция настроена так чтобы KB_Backspace генерировал ASCII DEL, и KB_Delete генерировал ESC [ 3 ~ (это управляющий код vt220 для клавиши `символ удаления’). Это должно быть выполнено загрузкой ресурсов с помощью xrdb на все локальные дисплеи X, не используя установки приложений по умолчанию, так чтобы трансляция ресурсов использовалась в соответствии с настройками xmodmap.
• Linux консоль настраивается чтобы `<--‘ генерировал DEL, и `Delete’ генерировал ESC [ 3 ~ (таково положение на данный момент).
• X приложения настраиваются так чтобы Backspace удалял символ слева, и Delete удалял символ справа. Motif приложения так уже работают.
• stty erase ^? .
• Запись `xterm’ terminfo должна иметь ESC [ 3 ~ для kdch1, как при TERM=linux и TERM=vt220.
• Emacs программируется чтобы символ KB_Backspace или `stty erase’ преобразовывался в delete-backward-char, и KB_Delete или kdch1 в delete-forward-char, и ^H всегда закрепляется для помощи.
• Другие приложения используют символ `stty erase’ и kdch1 для двух клавиш удаления, т.е. ASCII DEL будет `удалять предыдущий символ’ и kdch1 будет`удалять символ над курсором’.

Это решаемая проблема за исключением:

• Некоторые терминалы имеют клавишу <--, которую нельзя заставить выдавать другой код кроме как ^H. На этих терминалах помощь Emacs будет недоступна по ^H (предполагается, что символ `stty erase’ имеет превосходство в Emacs, и был установлен корректно). Вместо этого можно использовать M-x help или F1 (если доступно).
• Некоторые операционные системы используют ^H для stty erase. Однако, современные версии telnet и все версии rlogin передают настройки stty, и почти все версии UNIX обрабатывают stty erase. Там, где настройки stty не обрабатываются правильно, их можно сделать вручную с помощью stty.
• Некоторые системы (включая ранние версии Debian) используют xmodmap для настройки обоих <-- и Delete для генерации KB_Delete. Мы можем изменить поведение их X клиентов через те же X ресурсы, которые мы используем для в наших целях, или настроим наших клиентов через их ресурсы, когда всё не так до предела. На дисплеях, настроенных так Delete работать не будет, но <-- работает.
• Некоторые операционные системы имеют разные настройки kdch1 в своих terminfo для xterm и некоторых других. На этих системах клавиша Delete будет работать неправильно, когда ты регистрируешься в системе, соблюдающей наши правила, но <-- работает.

9. Переменные среды

Ни одна программа не может зависеть от переменных среды, для того чтобы приемлемо настроить параметры по умолчанию. (Из-за того что эти переменные среды будут устанавливаться в общесистемном файле настроек типа /etc/profile, который не поддерживается всеми shell.)

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

Вот пример сценария оболочки для этого случая:

#!/bin/sh

BAR=/var/lib/fubar

export BAR

exec /usr/lib/foo/foo "$@"

Кроме того, /etc/profile является файлом настройки пакета bash, и не один другой пакет не может помещать любые переменные среды или другие команды в этот файл.