Re: ng_ipacct port

From

Sergey Skvortsov (2:5020/400)

To

Vadim Goncharov

Date

2006-09-18T14:14:16Z

Area

RU.UNIX.BSD

From: Sergey Skvortsov <skv@protey.ru>

On 17.09.2006 22:56, Vadim Goncharov wrote:
> 
>  SS>> * унифицированные конфиги для нескольких машин - в этом случае в
>  SS>> /etc/rc.conf лежат host-specific data, а в rc.conf.d - общие для всех
>  >> /etc/rc.conf.local уже отменили?
>  SS> Вот лично у вас, будьте честны, строки с hostname, ifconfig* - лежат в
>  SS> rc.conf.local?
> 
> Нет. Ибо у меня нет кластеров, где была бы значительная часть
> конфигурации общей, и небольшая часть - специфичной для машины. У меня
> типичный rc.conf имеет размер порядка ~60 строк (включая небольшое
> колличество комментированных) - это всего два экрана в vim. И 10-20
> строчек *_enable в этом rc.conf. Я могу его здесь привести, дабы вы могли
> на примере показать, чем двадцать файликовв, в каждом из которых только
> одна строка enable (и лишь ВОЗМОЖНЫ еще какие flags и т.п.), лучше, чем
> один экран редактора с этой же конфигурацией.

Да к чему приводить, тривиальные примеры не интересны.
Просто не надо простые ситуации экстраполировать в "так надо делать
всегда". И ваше "лучше", подчеркну, если таково для вас, то "не надо
говорить за всех" (с).

>  SS>> и т.д.
>  SS> Вот кстати ещё свежие пункты:
>  SS> * robustness - синтаксическая ошибка в одном конфиге не приведёт к краху
>  SS> всей системы (такие коварные ловушки не столь уж редки после reboot'а).
> 
> :) Синтаксис rc.conf настолько прост, что я ни разу за несколько лет
> с таким не сталкивался.

Ну я знаю пару случаев, когда забытая кавычка в rc.conf приводила к
остановке загрузки (т.е. ssh конечно обломался запуститься). Типичная
болезнь, когда есть несколько админов у одной машинки. Как этого
избегать, можно не рассказывать, это лишь пример.

>  SS> * security - можно давать sudo неким операторам на управление
>  SS> подмножеством сервисов.
> 
> ...с правом на ребут машины? Пример не жизненный.

Почему так опрометчиво судите? Написать оболочку типа "vimrc", которая
позволяет делать taint режим для sh не так уж сложно. На perl'е это
делается за 5 минут. И если у вас лично такого случая не было - не стоит
заявлять "пример не жизненный". Например, роль "mail services
administrator" не обязательно предполагает рутовые привилегии.

Вообще, текущая интеграция из TrustedBSD новых фич типа mac/audit
позволяет делать тонкую настройку прав для конкретной роли оператора.

Роли с ограниченным доступом к управлению системой очень полезны.

Опять же, в тривиальных случаях достаточно root'а. Но простота некоторых
случаев не означает их достаточности и универсальности.

>  SS> Думаю, нет смысла особо подчёркивать, что ваш modus operandi не столь уж
>  SS> распространён нынче и, конечно, вовсе не канонический?
> 
> Канонический - так во фре всегда было. Это, скорее, ваш не распространен
> практически.

Ну вот, пример тупика, когда вы свой ортодоксальный подход считаете
единственно верным.

А "всегда было" - это наивно, в BSD всё меняется и развивается.

>  SS> rc.subr - это вовсе не "концентрация используемых процедур".
>  SS> И не просто API для скриптов. Это фундамент для разделения монолитных
>  SS> rc-скриптов на логически изолированное 
>  
> По факту - это всего лишь библиотека процедур. Остальное - философские
> измышления.

Увы, мне сложно себя ограничить исключительно "практической" плоскостью,
мне, так уж сложилось, стратегия развития BSD более чем интересна и важна.

>  SS> граф скриптов в rc.d.
> 
> Нифига он на данный момент не граф. Параллельного запуска независимых
> сервисов - нет. Всё идет в точной последовательности rcorder(8).

О боги, ну к чему эта подмена (извращение) понятий?!
Каким боком слово "граф" подразумевает "параллельный запуск"?

>  >> P.S. Вот что можно было бы считать прогрессом, так это введение
>  >> различных rc.conf (в каждом из которых полные настройки), своего рода
>  >> профилей, и переключение между ними 
>  SS> Это легко делается средствами shell'а.
> 
> Подержка loader'ом - тоже средствами шелла?

Опять. Каким боком "loader" смешан с "rc.conf"?
Но если вам хочется выбирать профиль загрузки из loader'а (в т.ч. их
меню), читайте man loader, loader.conf и лучше всего /boot/support.4th.

Есть несколько вариантов передачи из loader'а в rc параметров выбранного
профиля (если конечно не пугает Forth).

>  >> Но размазывание _однородной_ конфигурации
>  >> из одного файла в кучу разных - это не прогресс, и даже не регресс, это
>  >> диверсия.
>  SS> Угу, давайте усилим риторику - "всякий грех глаголит, но rc.d вопиёт".
> 
> По существу есть что возразить против однородности конфигурации?

Право же не знаю... Если вы внимательно читали весь thread и ничего "по
существу" не увидели... У меня нет ни времени, ни желания что-то
продолжать :)

>  SS> Надеюсь лишь, что подписчики этой эхи сделают полезные выводы из данной
>  SS> дискусии, по принципу "неполнота знаний о мире компенсируется его
>  SS> стереоскопичностью".
> 
> Конкретно по сабжу - портеры обязаны поддерживать не только 5-ку, на
> которой в манах ничего об rc.conf.d нет, но и 4-ку, срок поддержки

В манах много чего нет. Читайте исходники rc.subr. И, если хотите быть
конструктивнее, шлите send-pr на hier(7) и т.п.

> которой еще не кончился, а система стартовых скриптов там вообще старого
> стиля.

Что до rc.d скриптов в 4.x - это сплошная головная боль.

B открою по секрету, что поддержка 4.х закончится 2007/01/31, и
"портеры" уже сейчас не поддерживают массу портов. И, конечно, слово
"обязаны" требует разъяснения - приведите точную цитату, даже интересно.

-- 
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