|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Vadim Goncharov 2:5020/400 17 Sep 2006 22:56:00
To : Sergey Skvortsov
Subject : Re: ng_ipacct port
--------------------------------------------------------------------------------
Hi Sergey Skvortsov!
On Sat, 16 Sep 2006 17:02:51 +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>> * version control - управлять/отследить изменения в конфигурации сервиса
SS>> проще (удобнее) если конфигурация сия лежит в отдельном файле, а не в
SS>> монолитном-общем rc.conf
>> Опять же путаем startup-конфигурацию и общую конфигурацию.
SS> С чего бы это столь странный вывод?! Вполне чётко отделяю.
SS> Оба вида конфигураций надо хранить в VCS.
В VCS надо хранить все конфиги. Тут особой роли играть не будет (да и,
как по мне, удобне получить сжатый diff изменения одного файла, нежели
портянку на все файлы вместе). А сами startup-скрипты портов вообще
можно под CVS не класть, они легко восстанавливаются из портов же.
SS>> и т.д.
SS> Вот кстати ещё свежие пункты:
SS> * robustness - синтаксическая ошибка в одном конфиге не приведёт к краху
SS> всей системы (такие коварные ловушки не столь уж редки после reboot'а).
:) Синтаксис rc.conf настолько прост, что я ни разу за несколько лет
с таким не сталкивался.
SS> * security - можно давать sudo неким операторам на управление
SS> подмножеством сервисов.
...с правом на ребут машины? Пример не жизненный.
SS>> Если лично для вас это не актуально, это не означает, что для остальных
SS>> является приемлемым вариант "все пихаем в rc.conf". Когда на машине
SS>> стоит 20-30 сервисов/портов, для которых кужны startup настройки,
SS>> "управлять" ими через rc.conf жутко утомительно (это, конечно, моё imho
SS>> на основе личной практики).
>> Это сугубо ваше личное ho. Когда я все свои сервисы вижу на одном экране
>> в vim и могу их тут же поменять, это куда удобнее, чем лазить в пачку
>> мелких файликов.
SS> Думаю, нет смысла особо подчёркивать, что ваш modus operandi не столь уж
SS> распространён нынче и, конечно, вовсе не канонический?
Канонический - так во фре всегда было. Это, скорее, ваш не распространен
практически.
SS>>>> Точно так же как для xinetd удобнее настройки сервисов кидать в
SS>>>> /etc/xinetd.d (man xinetd.conf /includedir)
>>>> Ой, какой SysV-style ужас.
SS>>> Ах оставьте, тогда и rc.subr - тоже SysV?
>>> :) rc.subr как раз есть концентрация используемых процедур в одном
>>> месте, а не размазывание по куче файлов.
SS>> И rc.conf.d - продолжение этой идеи.
>> Размазывание по куче файлов не может быть продолжением идеи концентрации
>> в одном файле.
SS> rc.subr - это вовсе не "концентрация используемых процедур".
SS> И не просто API для скриптов. Это фундамент для разделения монолитных
SS> rc-скриптов на логически изолированное
По факту - это всего лишь библиотека процедур. Остальное - философские
измышления.
SS> граф скриптов в rc.d.
Hифига он на данный момент не граф. Параллельного запуска независимых
сервисов - нет. Всё идет в точной последовательности rcorder(8).
>> P.S. Вот что можно было бы считать прогрессом, так это введение
>> различных rc.conf (в каждом из которых полные настройки), своего рода
>> профилей, и переключение между ними
SS> Это легко делается средствами shell'а.
Подержка loader'ом - тоже средствами шелла?
>> А также развитие механизма зависимостей (когда рестарт одного
>> сервиса требует рестарта другого).
SS> Вы таки не поверите, но данная возможность уже есть в rc.subr (forced
SS> dependencies).
SS> Только вот таких диких сервисов что-то нет.
Что, вообще говоря, странно.
>> Hо размазывание _однородной_ конфигурации
>> из одного файла в кучу разных - это не прогресс, и даже не регресс, это
>> диверсия.
SS> Угу, давайте усилим риторику - "всякий грех глаголит, но rc.d вопиёт".
По существу есть что возразить против однородности конфигурации?
SS> Резюмируя.
SS> 1. Для меня использование rc.conf.d есть безусловно логичный и удобный
SS> способ управления сервисом. Использовать для настроек сервисов только
SS> rc.conf - устарелый и неудобный способ.
Бездоказательно.
SS> 2. Для вас - rc.conf единственно приемлемый и безальтернативный.
Если из альтернатив только rc.conf.d - то да.
SS> Дальнейшее же обсуждение сведётся к повтору одних и тех же агрументов,
SS> что есть бессмысленная трата времени.
Есть еще демонстрация на примерах.
SS> Hадеюсь лишь, что подписчики этой эхи сделают полезные выводы из данной
SS> дискусии, по принципу "неполнота знаний о мире компенсируется его
SS> стереоскопичностью".
Конкретно по сабжу - портеры обязаны поддерживать не только 5-ку, на
которой в манах ничего об rc.conf.d нет, но и 4-ку, срок поддержки
которой еще не кончился, а система стартовых скриптов там вообще старого
стиля.
SS> История нас рассудит (скорее всего, как обычно, придумав некий третий
SS> вариант).
Графические конфигурялки :)
SS> p.s. Мне, кстати, давно хочется где-нибудь сделать тематические опросы
SS> участников эхи на de-facto применяемых (mainstream) технологий и
SS> подходов в работе. И кроме классических "vim или exim", "sendmail vs.
SS> exim vs. postfix", можно добавить топик "как вы управляете конфигами".
SS> Равно как и детальное описание альтернатив, эдаких "паттернов unix
SS> администрирования" - imho было бы весьма поучительным.
Сделайте. Будет интересно.
--
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
