Re: ng_ipacct port

From

Vadim Goncharov (2:5020/400)

To

Sergey Skvortsov

Date

2006-09-18T16:20:06Z

Area

RU.UNIX.BSD

From: Vadim Goncharov <vadimnuclight@tpu.ru>

Hi Sergey Skvortsov! 

On Mon, 18 Sep 2006 10:14:16 +0000 (UTC); Sergey Skvortsov wrote about 'Re: ng_ipacct port':

 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> всегда". И ваше "лучше", подчеркну, если таково для вас, то "не надо
 SS> говорить за всех" (с).

Хехе. Тред начался с того, что был навязываем стиль rc.conf.d, всем, ибо
предыдущий стиль типа устарел

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

У многих утилит есть режимы проверки корректности конфигов. В том числе
и тут - sh -n /etc/rc.conf.

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

Написать утилитку, которая будет редактировать rc.conf вместо
пользователя, тоже не так сложно. А когда всё равно надо что-то писать,
становится не интересно.

 SS> Вообще, текущая интеграция из TrustedBSD новых фич типа mac/audit
 SS> позволяет делать тонкую настройку прав для конкретной роли оператора.
 SS> Роли с ограниченным доступом к управлению системой очень полезны.
 SS> Опять же, в тривиальных случаях достаточно root'а. Но простота некоторых
 SS> случаев не означает их достаточности и универсальности.

...Безусловно верные абстрактные утверждения, весьма косвенно
относящиеся к конкретному случаю.

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

Я нигде не говорил _единственно_. Это во-первых. А во-вторых, где
показатели распространенности вашего подхода?

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

Органиизация конфигов в BSD всегда была тем, что выгодно отличало её от
линуксов. А именно, упорядоченность, стройность и логичность, всё лежит
на своих местах. Нет ни помойки "всё в одном месте", ни размазанности
всего и вся по всему дереву каталогов, а есть оптимальный баланс.

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

(1)

 SS>> граф скриптов в rc.d.
 >> Нифига он на данный момент не граф. Параллельного запуска независимых
 >> сервисов - нет. Всё идет в точной последовательности rcorder(8).
 SS> О боги, ну к чему эта подмена (извращение) понятий?!
 SS> Каким боком слово "граф" подразумевает "параллельный запуск"?

Тем, что вырожденные случаи обычно графами не называют. А с учетом (1),
прогрессом было бы использование возможностей графа например для
параллельного запуска и ускорения тем загрузки системы. Представьте
себе, я тоже думаю не только исключительно "практической" плоскостью,
а еще и о стратегии развития BSD.

 >>> P.S. Вот что можно было бы считать прогрессом, так это введение
 >>> различных rc.conf (в каждом из которых полные настройки), своего рода
 >>> профилей, и переключение между ними 
 SS>> Это легко делается средствами shell'а.
 >> Подержка loader'ом - тоже средствами шелла?
 SS> Опять. Каким боком "loader" смешан с "rc.conf"?
 SS> Но если вам хочется выбирать профиль загрузки из loader'а (в т.ч. их
 SS> меню), читайте man loader, loader.conf и лучше всего /boot/support.4th.
 SS> Есть несколько вариантов передачи из loader'а в rc параметров выбранного
 SS> профиля (если конечно не пугает Forth).

Знаете, реализация для себя и на своей машине одно, а когда оно
становится "политикой партии" и входит в base system - другое.

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

Ваши аргументы сводились в основном к "мне rc.conf неудобно, и вообще он
устарел, а всякие ортодоксы мешают прогрессу" плюс некоторому числу
частных случаев (которые, возможно, верны, но не были развернуты до
полной убедительности). Концептуальная же хреновость rc.conf не
была ни доказана в общем виде теоретически, ни показана на реальных
примерах.

На жизненность может претендовать лишь пример с разделением привилегий,
но он мало того что не есть обыденность для большинства, так и не
требует обязательного распиливания rc.conf на кусочки - rc.conf.d может
дополнять rc.conf для таких вот частных случаев.

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

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

 >> которой еще не кончился, а система стартовых скриптов там вообще старого
 >> стиля.
 SS> Что до rc.d скриптов в 4.x - это сплошная головная боль.
 SS> B открою по секрету, что поддержка 4.х закончится 2007/01/31, и

Я знаю и про боль, и про срок. Но если обязательства взяты - их надо
выполнять.

 SS> "портеры" уже сейчас не поддерживают массу портов. И, конечно, слово
 SS> "обязаны" требует разъяснения - приведите точную цитату, даже интересно.

А если портер не вставил в порт BROKEN= для OSVERSION ниже пятерки
- значит считается, что он этот порт поддерживает для этой версии,
потому как сама версия официально поддерживается проектом.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
--- slrn/0.9.8.1 on FreeBSD 4.11/i386
 * Origin: Nuclear Lightning @ Tomsk, TPU AVTF Hostel (2:5020/400@fidonet)
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