Re: ng_ipacct port

From

Sergey Skvortsov (2:5020/400)

To

Vadim Goncharov

Date

2006-09-16T21:02:50Z

Area

RU.UNIX.BSD

From: Sergey Skvortsov <skv@protey.ru>

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).
Только вот таких диких сервисов что-то нет.

> Но размазывание _однородной_ конфигурации
> из одного файла в кучу разных - это не прогресс, и даже не регресс, это
> диверсия.

Угу, давайте усилим риторику - "всякий грех глаголит, но rc.d вопиёт".

Резюмируя.

1. Для меня использование rc.conf.d есть безусловно логичный и удобный
способ управления сервисом. Использовать для настроек сервисов только
rc.conf - устарелый и неудобный способ.

2. Для вас - rc.conf единственно приемлемый и безальтернативный.

Дальнейшее же обсуждение сведётся к повтору одних и тех же агрументов,
что есть бессмысленная трата времени.
Надеюсь лишь, что подписчики этой эхи сделают полезные выводы из данной
дискусии, по принципу "неполнота знаний о мире компенсируется его
стереоскопичностью".

История нас рассудит (скорее всего, как обычно, придумав некий третий
вариант).

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)
SEEN-BY: 50/12 203 400/814 450/159 186 1024 451/30 461/43 132 640 469/999
SEEN-BY: 550/196 4616/3 4625/8 4635/4 4641/444 5000/76 5000 5006/1 5007/1
SEEN-BY: 5010/70 352 5011/13 5012/46 5015/28 5019/31 5020/18 154 175 194 400
SEEN-BY: 5020/545 549 715 758 982 1057 1523 1604 1630 1909 1922 2142 2238 2395
SEEN-BY: 5020/2450 2590 2871 4441 5021/3 29 5022/128 5025/3 750 5026/45
SEEN-BY: 5027/12 5029/32 5030/49 500 556 966 1063 1080 1900 1957 2828 5031/47
SEEN-BY: 5031/70 5034/10 13 5035/3 38 5036/1 5040/47 5042/13 5045/7 5049/1 50
SEEN-BY: 5049/97 5051/15 5054/1 4 8 9 11 28 35 36 37 45 63 66 67 70 75 84 85
SEEN-BY: 5055/95 5057/1 5059/9 5060/88 5061/15 5062/1 10 5063/3 5064/7 5066/18
SEEN-BY: 5074/9 5075/5 5077/70 5080/80 1003 5082/6 5083/21 5085/13 5090/108
SEEN-BY: 5094/4 5095/20 5096/18 5099/11 6001/3 10

PATH: 5020/400 4441 545 5054/1 37