|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Sergey Skvortsov 2:5020/400 16 Sep 2006 21:02:51
To : Vadim Goncharov
Subject : Re: ng_ipacct port
--------------------------------------------------------------------------------
Vadim Goncharov wrote:
> SS> * унифицированные конфиги для нескольких машин - в этом случае в
> SS> /etc/rc.conf лежат host-specific data, а в rc.conf.d - общие для всех
>
> /etc/rc.conf.local уже отменили?
Вот лично у вас, будьте честны, строки с hostname, ifconfig* - лежат в
rc.conf.local?
> SS> * version control - управлять/отследить изменения в конфигурации сервиса
> SS> проще (удобнее) если конфигурация сия лежит в отдельном файле, а не в
> SS> монолитном-общем rc.conf
>
> Опять же путаем startup-конфигурацию и общую конфигурацию.
С чего бы это столь странный вывод?! Вполне чётко отделяю.
Оба вида конфигураций надо хранить в VCS.
> SS> и т.д.
Вот кстати ещё свежие пункты:
* robustness - синтаксическая ошибка в одном конфиге не приведёт к краху
всей системы (такие коварные ловушки не столь уж редки после reboot'а).
* security - можно давать sudo неким операторам на управление
подмножеством сервисов.
И ещё раз - "и т.п."
> SS> Если лично для вас это не актуально, это не означает, что для остальных
> SS> является приемлемым вариант "все пихаем в rc.conf". Когда на машине
> SS> стоит 20-30 сервисов/портов, для которых кужны startup настройки,
> SS> "управлять" ими через rc.conf жутко утомительно (это, конечно, моё imho
> SS> на основе личной практики).
>
> Это сугубо ваше личное ho. Когда я все свои сервисы вижу на одном экране
> в vim и могу их тут же поменять, это куда удобнее, чем лазить в пачку
> мелких файликов.
Думаю, нет смысла особо подчёркивать, что ваш modus operandi не столь уж
распространён нынче и, конечно, вовсе не канонический?
> SS>>> Точно так же как для xinetd удобнее настройки сервисов кидать в
> SS>>> /etc/xinetd.d (man xinetd.conf /includedir)
> >>> Ой, какой SysV-style ужас.
> SS>> Ах оставьте, тогда и rc.subr - тоже SysV?
> >> :) rc.subr как раз есть концентрация используемых процедур в одном
> >> месте, а не размазывание по куче файлов.
> SS> И rc.conf.d - продолжение этой идеи.
>
> Размазывание по куче файлов не может быть продолжением идеи концентрации
> в одном файле.
rc.subr - это вовсе не "концентрация используемых процедур".
И не просто API для скриптов. Это фундамент для разделения монолитных
rc-скриптов на логически изолированное граф скриптов в rc.d.
> P.S. Вот что можно было бы считать прогрессом, так это введение
> различных rc.conf (в каждом из которых полные настройки), своего рода
> профилей, и переключение между ними
Это легко делается средствами shell'а.
> А также развитие механизма зависимостей (когда рестарт одного
> сервиса требует рестарта другого).
Вы таки не поверите, но данная возможность уже есть в rc.subr (forced
dependencies).
Только вот таких диких сервисов что-то нет.
> Hо размазывание _однородной_ конфигурации
> из одного файла в кучу разных - это не прогресс, и даже не регресс, это
> диверсия.
Угу, давайте усилим риторику - "всякий грех глаголит, но rc.d вопиёт".
Резюмируя.
1. Для меня использование rc.conf.d есть безусловно логичный и удобный
способ управления сервисом. Использовать для настроек сервисов только
rc.conf - устарелый и неудобный способ.
2. Для вас - rc.conf единственно приемлемый и безальтернативный.
Дальнейшее же обсуждение сведётся к повтору одних и тех же агрументов,
что есть бессмысленная трата времени.
Hадеюсь лишь, что подписчики этой эхи сделают полезные выводы из данной
дискусии, по принципу "неполнота знаний о мире компенсируется его
стереоскопичностью".
История нас рассудит (скорее всего, как обычно, придумав некий третий
вариант).
p.s. Мне, кстати, давно хочется где-нибудь сделать тематические опросы
участников эхи на de-facto применяемых (mainstream) технологий и
подходов в работе. И кроме классических "vim или exim", "sendmail vs.
exim vs. postfix", можно добавить топик "как вы управляете конфигами".
Равно как и детальное описание альтернатив, эдаких "паттернов unix
администрирования" - imho было бы весьма поучительным.
--
Sergey Skvortsov
mailto: skv@protey.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
