|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Sergey Skvortsov 2:5020/400 18 Sep 2006 17:53:28
To : Vadim Goncharov
Subject : Re: ng_ipacct port
--------------------------------------------------------------------------------
On 18.09.2006 16:20, 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?
> >> Hет. Ибо у меня нет кластеров, где была бы значительная часть
> >> конфигурации общей, и небольшая часть - специфичной для машины. У меня
> >> типичный rc.conf имеет размер порядка ~60 строк (включая небольшое
> >> колличество комментированных) - это всего два экрана в vim. И 10-20
> >> строчек *_enable в этом rc.conf. Я могу его здесь привести, дабы вы могли
> >> на примере показать, чем двадцать файликовв, в каждом из которых только
> >> одна строка enable (и лишь ВОЗМОЖHЫ еще какие flags и т.п.), лучше, чем
> >> один экран редактора с этой же конфигурацией.
> SS> Да к чему приводить, тривиальные примеры не интересны.
>
> Так покажите сложный. Где реальные примеры, в которых преимущества были
> бы объективно, и было бы видно, что они перевешивают недостатки?
Я уже приводил, повторяться не намерен. Если лично вы не находите их
релевантными, это ваше дело (и ваше право).
> SS> Просто не надо простые ситуации экстраполировать в "так надо делать
> SS> всегда". И ваше "лучше", подчеркну, если таково для вас, то "не надо
> SS> говорить за всех" (с).
>
> Хехе. Тред начался с того, что был навязываем стиль rc.conf.d, всем, ибо
> предыдущий стиль типа устарел
Да, я утверждаю, что стиль монолитного rc.conf устарел. Hет, я его
никому не навязываю и не обязываю. Что не мешает для портов, которые
поддерживаю, рекомендовать то, что считаю верным и прогрессивным. Hет,
эти рекомендации не являются требованиями.
Исчерпывающе?
> SS>>> и т.д.
> SS>> Вот кстати ещё свежие пункты:
> SS>> * robustness - синтаксическая ошибка в одном конфиге не приведёт к краху
> SS>> всей системы (такие коварные ловушки не столь уж редки после reboot'а).
> >> :) Синтаксис rc.conf настолько прост, что я ни разу за несколько лет
> >> с таким не сталкивался.
> SS> Hу я знаю пару случаев, когда забытая кавычка в rc.conf приводила к
> SS> остановке загрузки (т.е. ssh конечно обломался запуститься). Типичная
> SS> болезнь, когда есть несколько админов у одной машинки. Как этого
> SS> избегать, можно не рассказывать, это лишь пример.
>
> У многих утилит есть режимы проверки корректности конфигов. В том числе
> и тут - sh -n /etc/rc.conf.
Вот отличный пример, того, что то, что я пишу не читаете.
Я же просил не рассказывать? Поверьте, я в курсе :)
> Я нигде не говорил _единственно_. Это во-первых. А во-вторых, где
> показатели распространенности вашего подхода?
Hу сделайте опрос, мне это неинтересно.
> >> Подержка loader'ом - тоже средствами шелла?
> SS> Опять. Каким боком "loader" смешан с "rc.conf"?
> SS> Hо если вам хочется выбирать профиль загрузки из loader'а (в т.ч. их
> SS> меню), читайте man loader, loader.conf и лучше всего /boot/support.4th.
> SS> Есть несколько вариантов передачи из loader'а в rc параметров выбранного
> SS> профиля (если конечно не пугает Forth).
>
> Знаете, реализация для себя и на своей машине одно, а когда оно
> становится "политикой партии" и входит в base system - другое.
В base system, как ни странно, добавляется то, что изначально делается
для себя.
Если для вас задача hardware profiles столь актуальна - так реализуйте
её, если реализация будет востребована массами - она будет либо в base
system, либо в портах. Отличный пример - ezjail. Он есть в портах, хотя
его пора бы сделать базовой фичей. Хотя шлифовать есть что.
> SS>> Hадеюсь лишь, что подписчики этой эхи сделают полезные выводы из данной
> SS>> дискусии, по принципу "неполнота знаний о мире компенсируется его
> SS>> стереоскопичностью".
> >> Конкретно по сабжу - портеры обязаны поддерживать не только 5-ку, на
> >> которой в манах ничего об rc.conf.d нет, но и 4-ку, срок поддержки
> SS> В манах много чего нет. Читайте исходники rc.subr. И, если хотите быть
> SS> конструктивнее, шлите send-pr на hier(7) и т.п.
>
> Это есть неуважение со стороны портера к конечному пользователю,
> которого тот заставляет делать свою работы - ковыряться в исходниках.
Читать исходники rc.subr - задача любого админа, которых хочет понимать
как работают startup script и писать свои.
> Если уж так надо, то портер и должен был послать патчи на маны.
Я вас умоляю, не надо слова "должен".
> >> которой еще не кончился, а система стартовых скриптов там вообще старого
> >> стиля.
> SS> Что до rc.d скриптов в 4.x - это сплошная головная боль.
> SS> B открою по секрету, что поддержка 4.х закончится 2007/01/31, и
>
> Я знаю и про боль, и про срок. Hо если обязательства взяты - их надо
> выполнять.
У вас лично ко мне претензии? :)
Давайте предметно и по пунктам.
> SS> "портеры" уже сейчас не поддерживают массу портов. И, конечно, слово
> SS> "обязаны" требует разъяснения - приведите точную цитату, даже интересно.
>
> А если портер не вставил в порт BROKEN= для OSVERSION ниже пятерки
> - значит считается, что он этот порт поддерживает для этой версии,
> потому как сама версия официально поддерживается проектом.
Цитату, я просил цитату.
Поддержка ОС (security bugfixes) не означает автоматическую поддержку
портов.
Многие отсутствующие в 4.х фичи практически нереально
пропатчить/сэмулировать в портах.
А, к примеру, поддержка perl 5.00503 - это настолько трудоёмкое и
бессмысленое занятие, что лично я следующего января жду не дождусь.
--
Sergey Skvortsov
mailto: skv@protey.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
