В чем разница между / etc и / usr / local / etc


24

Я занимаюсь разработкой демона, который должен хранить множество данных приложения, и заметил, что в моей системе (Fedora 15) есть /usr/local/etcкаталог.

Я решил установить свой демон в /usr/local/bin, и мне нужно место для моих файлов конфигурации.

Я не видел этого в Википедии . Это нестандартное или это стандартное место для программ, установленных /usr/local/binдля хранения конфигурационных файлов?

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


2
Есть ли причина не ставить это прямо под /etc/myapp? Если бы я искал изменения в конфигурации, это было бы первое место, которое я бы посмотрел.
new123456

@ new123456 - Лично мне нравится идея держать конфигурационные файлы рядом с двоичными файлами (например, /usr/local/bin-> /usr/local/etc), но соглашения выигрывают в этом случае.
beatgammit

Ответы:


24

/usr/localобычно для приложений, созданных из исходного кода. т.е. я устанавливаю большинство своих пакетов, используя что-то подобное apt, но если я загружаю более новую версию чего-либо или часть программного обеспечения, не входящую в мой дистрибутив, я собираю его из исходного кода и помещаю все в иерархию `/ usr / local '.

Это позволяет отделить от остальной части распределения.

Если вы разрабатываете какое-то программное обеспечение для других, вы должны спроектировать его так, чтобы оно могло быть установлено в любом месте, где люди хотят, но оно должно по умолчанию использовать стандартные системные директории, определенные FHS , когда они указывают префикс /usr(( /etc, /usr/binи т. Д.)).

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

Иметь хорошее чтение на FHS , и использовать стандартные инструменты Linux , чтобы ваш источник должен быть построен и установлен в любом месте , так что пакет строителей для различных дистрибутивов можно настроить их в соответствии с требованиями для их распределения, и пользователи могут поместить его в , /usr/local если они желают или обычные системные каталоги, если они хотят.


Да, я думаю, что разрешить настройку - это хорошо, но мне было интересно, /usr/local/etcявляется ли стандарт для конфигурационных файлов для такого рода программ.
beatgammit

/ usr / local / etc - это то, что я мог бы выбрать, если бы я собрал ваш демон из исходного кода, но / etc - это место, которое кто-то выберет, если он упаковывает ваш демон с помощью Debian или Ubuntu.
EightBitTony

4
На самом деле стандарты GNU требуют, чтобы пакет по умолчанию соответствовал локальному пути, поскольку люди, собирающие его из исходного кода, обычно не указывают, где. Дистрибутивы изменят его на нелокальный путь, когда они его упакуют / соберут.
psusi

@ psusi- Хороший вопрос, я обязательно сделаю это по умолчанию. Возможно, я обнаружу, когда моя make install запускается от имени пользователя root или обычного пользователя. Если пользователь root, я по умолчанию использую / usr / local, если пользователь, в домашнем каталоге пользователей. Я также добавлю настройки конфигурации.
beatgammit

@ EightBitTony - есть ли другие платформы с другими соглашениями? Я уже делаю разные сценарии запуска для разных платформ (upstart, systemd, init).
beatgammit

7

Очень короткий ответ

/ etc используется вашей ОС для файлов конфигурации

/ usr / local / etc может использоваться вами и вашими дополнительными программами для ваших файлов конфигурации


4

/usr/local/etcредко используется в мире Linux. Но решение о том, хранения конфигурационных файлов в /etc, /usr/local/etcили в другое место , как правило , производится во время компиляции (и часто могут быть переопределены с помощью опции командной строки или переменной окружения). На самом деле не имеет значения, какое значение по умолчанию используется при компиляции, просто убедитесь, что его легко установить (обычно это опция --sysconfdirпосле autoconf). Если ваш демон упакован для дистрибутива, исполняемый файл войдет в систему /usr/sbin(по умолчанию при сборке из исходного кода /usr/local/sbin), а конфигурация - в /etc.

Обратите внимание, что /etcэто не место для «большого количества данных приложения». Это входит в /var. По умолчанию при построении из источника может быть /var/local/mydaemonили /var/lib/mydaemon; опять же, нет строгого соглашения в любом случае по умолчанию при сборке из исходного кода. Должен быть способ изменить как время компиляции по умолчанию (обычно с configure --localstatedir), так и время выполнения по умолчанию (с настройкой в ​​файле конфигурации, возможно с параметром командной строки или переменной среды).


Есть ли причина, почему /usr/local/etcне используется очень часто? Мне нравится идея сохранения файлов конфигурации на том же уровне файловой системы, что и двоичный файл.
beatgammit

1
@ tjameson Я не знаю, есть ли распространенная причина. BSD делает это таким образом. Как администратор, я так все конфигурационные файлы (которые должны быть подкреплены и изменения контролируемых, в отличие от материала , в binи libи так далее , которые можно переустанавливать) живут в том же самом месте.
Жиль "ТАК - перестать быть злым"

1

Как пользователь Arch, я бы вообще избегал / usr / local и использую только / etc для конфигурации. При установке из исходного кода, я предпочел бы написать небольшой файл PKGBUILD, пока я там, и, возможно, загрузить его в репозиторий пользователей Arch (AUR), как для других, так и для себя на другом компьютере в будущем. Судя по количеству пакетов в AUR и скорости их создания, я не одинок в своих мыслях. Это увеличивает шансы для всех, что пакет будет доступен, вместо того, чтобы устанавливать его из исходных текстов, и избегать устаревших расположений, таких как / usr / local.

Похоже, что Debian также нравится идея создания пакета исходного кода вместо установки чего-либо в / usr / local, поэтому используются такие утилиты, как checkinstall .

Создание пакета с исходным кодом, который вы хотите установить, было бы хорошим способом отследить, где находятся файлы, и убедиться, что некоторые из них непостоянно не перезаписаны другим пакетом или другой «make install». Удаление с помощью «make uninstall» не является хорошим решением. Информация о том, какая версия установлена, - это еще одна вещь, которую современные менеджеры пакетов умеют отслеживать.

Я бы просто отказался от / usr / local полностью. Это не очень хорошее место для размещения чего-либо, не для установки пакетов (общесистемные каталоги более удобны) и не для пользователей.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.