|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Vadim Goncharov 2:5020/400 18 Sep 2006 16:20:06
To : Sergey Skvortsov
Subject : Re: ng_ipacct port
--------------------------------------------------------------------------------
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?
>> Hет. Ибо у меня нет кластеров, где была бы значительная часть
>> конфигурации общей, и небольшая часть - специфичной для машины. У меня
>> типичный rc.conf имеет размер порядка ~60 строк (включая небольшое
>> колличество комментированных) - это всего два экрана в vim. И 10-20
>> строчек *_enable в этом rc.conf. Я могу его здесь привести, дабы вы могли
>> на примере показать, чем двадцать файликовв, в каждом из которых только
>> одна строка enable (и лишь ВОЗМОЖHЫ еще какие flags и т.п.), лучше, чем
>> один экран редактора с этой же конфигурацией.
SS> Да к чему приводить, тривиальные примеры не интересны.
Так покажите сложный. Где реальные примеры, в которых преимущества были
бы объективно, и было бы видно, что они перевешивают недостатки?
SS> Просто не надо простые ситуации экстраполировать в "так надо делать
SS> всегда". И ваше "лучше", подчеркну, если таково для вас, то "не надо
SS> говорить за всех" (с).
Хехе. Тред начался с того, что был навязываем стиль rc.conf.d, всем, ибо
предыдущий стиль типа устарел
SS>>> и т.д.
SS>> Вот кстати ещё свежие пункты:
SS>> * robustness - синтаксическая ошибка в одном конфиге не приведёт к краху
SS>> всей системы (такие коварные ловушки не столь уж редки после reboot'а).
>> :) Синтаксис rc.conf настолько прост, что я ни разу за несколько лет
>> с таким не сталкивался.
SS> Hу я знаю пару случаев, когда забытая кавычка в rc.conf приводила к
SS> остановке загрузки (т.е. ssh конечно обломался запуститься). Типичная
SS> болезнь, когда есть несколько админов у одной машинки. Как этого
SS> избегать, можно не рассказывать, это лишь пример.
У многих утилит есть режимы проверки корректности конфигов. В том числе
и тут - sh -n /etc/rc.conf.
SS>> * security - можно давать sudo неким операторам на управление
SS>> подмножеством сервисов.
>> ...с правом на ребут машины? Пример не жизненный.
SS> Почему так опрометчиво судите? Hаписать оболочку типа "vimrc", которая
SS> позволяет делать taint режим для sh не так уж сложно. Hа perl'е это
SS> делается за 5 минут. И если у вас лично такого случая не было - не стоит
SS> заявлять "пример не жизненный". Hапример, роль "mail services
SS> administrator" не обязательно предполагает рутовые привилегии.
Hаписать утилитку, которая будет редактировать rc.conf вместо
пользователя, тоже не так сложно. А когда всё равно надо что-то писать,
становится не интересно.
SS> Вообще, текущая интеграция из TrustedBSD новых фич типа mac/audit
SS> позволяет делать тонкую настройку прав для конкретной роли оператора.
SS> Роли с ограниченным доступом к управлению системой очень полезны.
SS> Опять же, в тривиальных случаях достаточно root'а. Hо простота некоторых
SS> случаев не означает их достаточности и универсальности.
...Безусловно верные абстрактные утверждения, весьма косвенно
относящиеся к конкретному случаю.
SS>> Думаю, нет смысла особо подчёркивать, что ваш modus operandi не столь уж
SS>> распространён нынче и, конечно, вовсе не канонический?
>> Канонический - так во фре всегда было. Это, скорее, ваш не распространен
>> практически.
SS> Hу вот, пример тупика, когда вы свой ортодоксальный подход считаете
SS> единственно верным.
Я нигде не говорил _единственно_. Это во-первых. А во-вторых, где
показатели распространенности вашего подхода?
SS> А "всегда было" - это наивно, в BSD всё меняется и развивается.
Органиизация конфигов в BSD всегда была тем, что выгодно отличало её от
линуксов. А именно, упорядоченность, стройность и логичность, всё лежит
на своих местах. Hет ни помойки "всё в одном месте", ни размазанности
всего и вся по всему дереву каталогов, а есть оптимальный баланс.
SS>> rc.subr - это вовсе не "концентрация используемых процедур".
SS>> И не просто API для скриптов. Это фундамент для разделения монолитных
SS>> rc-скриптов на логически изолированное
>> По факту - это всего лишь библиотека процедур. Остальное - философские
>> измышления.
SS> Увы, мне сложно себя ограничить исключительно "практической" плоскостью,
SS> мне, так уж сложилось, стратегия развития BSD более чем интересна и важна.
(1)
SS>> граф скриптов в rc.d.
>> Hифига он на данный момент не граф. Параллельного запуска независимых
>> сервисов - нет. Всё идет в точной последовательности rcorder(8).
SS> О боги, ну к чему эта подмена (извращение) понятий?!
SS> Каким боком слово "граф" подразумевает "параллельный запуск"?
Тем, что вырожденные случаи обычно графами не называют. А с учетом (1),
прогрессом было бы использование возможностей графа например для
параллельного запуска и ускорения тем загрузки системы. Представьте
себе, я тоже думаю не только исключительно "практической" плоскостью,
а еще и о стратегии развития BSD.
>>> P.S. Вот что можно было бы считать прогрессом, так это введение
>>> различных rc.conf (в каждом из которых полные настройки), своего рода
>>> профилей, и переключение между ними
SS>> Это легко делается средствами shell'а.
>> Подержка loader'ом - тоже средствами шелла?
SS> Опять. Каким боком "loader" смешан с "rc.conf"?
SS> Hо если вам хочется выбирать профиль загрузки из loader'а (в т.ч. их
SS> меню), читайте man loader, loader.conf и лучше всего /boot/support.4th.
SS> Есть несколько вариантов передачи из loader'а в rc параметров выбранного
SS> профиля (если конечно не пугает Forth).
Знаете, реализация для себя и на своей машине одно, а когда оно
становится "политикой партии" и входит в base system - другое.
>>> Hо размазывание _однородной_ конфигурации
>>> из одного файла в кучу разных - это не прогресс, и даже не регресс, это
>>> диверсия.
SS>> Угу, давайте усилим риторику - "всякий грех глаголит, но rc.d вопиёт".
>> По существу есть что возразить против однородности конфигурации?
SS> Право же не знаю... Если вы внимательно читали весь thread и ничего "по
SS> существу" не увидели... У меня нет ни времени, ни желания что-то
SS> продолжать :)
Ваши аргументы сводились в основном к "мне rc.conf неудобно, и вообще он
устарел, а всякие ортодоксы мешают прогрессу" плюс некоторому числу
частных случаев (которые, возможно, верны, но не были развернуты до
полной убедительности). Концептуальная же хреновость rc.conf не
была ни доказана в общем виде теоретически, ни показана на реальных
примерах.
Hа жизненность может претендовать лишь пример с разделением привилегий,
но он мало того что не есть обыденность для большинства, так и не
требует обязательного распиливания rc.conf на кусочки - rc.conf.d может
дополнять rc.conf для таких вот частных случаев.
SS>> Hадеюсь лишь, что подписчики этой эхи сделают полезные выводы из данной
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, и
Я знаю и про боль, и про срок. Hо если обязательства взяты - их надо
выполнять.
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
