центральне сховище конфігів

[pvl]

з'явилась така ідея: створити в linux центральне сховище конфігів. щось схоже на реєстр windows але тільки схоже.
потім пошукав і знайшов http://www.libelektra.org/Main_Page
в кого які думки про цю ідею?

[raven]

Ага, і встроїти вайн в ядро.

Навіщо це? etc не вистачає?

[pvl]

вайн в ядрі - це чудово, можна ще додати лдап сервер в ядро і зберігати там настройки ядра

чим мене не влаштовує стандартний etc:
різні формати конфігів
інтеграція linux в великих маштабах - тобто для прикладу у вас є 20 компів і 40. вам треба на одних одні налаштування - на інших - трошки інші. а потім вам треба щось змінити. притому у кожного демона свій конфіг. які засоби ви порекомендуєте?

я використовую rsync для розповсюдження конфігів - але це рішення мені здається програє Windows Domain + Active Directory.

[Praporshic]

Щось мені кортить у якості превентивної міри зачинити гілку, доки не почався холлівар, у якому pvl буде жорстоко та безжально знищений.... :-/

[pvl]

спокойно
може хтось щось конструктивне скаже

[Praporshic]

Не вірите - розповідаю:
0. Порушуємо принцип KISS - це вже дуже недобре.
1. Щоб тримати усі налаштування у сховищі штибу LDAP треба десь вказати демону де його брати. Гадаю, Ви не будете проти того, що кожен демон матиме власний погляд на те, як це слід робити?
2. Центральне сховище конфігураційних файлів - центральна точка відмови. Особливо у мережі.
3. Як не крути, а все одно доведеться робити для кожного демона свої налаштування.
4. Для кожного хоста доведеться робити окремі налаштування.

Взагалі, якщо вже на те пішло, простіше та надійніше зробити комплект сценаріїв, що будуть автоматично оновлювати відповідні файли та доповідатимуть про це демонам.

[pvl]

от вже і перша конструктивна думка

1. а парсер конфігів в кожній програмі - це теж порушення KISS
2. демон не повинен знати де його настройки - цим займається бібліотека відповідно налаштована адміністратором.
приклад - користувач коли вводить пароль також може (і не повинен - нащо воно йому) знати які модулі в ПАМ перевіряють його пароль.
2. 3. 4.- зрозуміло але переваги більші за недоліки (IMHO)

[Praporshic]

0. Якщо я не помиляюсь, то є кілька стандартних алгоритмів, що розбирають конфігураційний файл. Яким скористатись - залежить від складності майбутнього продукту.
1. Тобто Ви пропонуєте стукатись у якусь бібліотеку за налаштуваннями? А чим це краще за відкриття файлу?
2-4 НМД навпаки. Пояснюю: коли щось піде не так (а воно не так піде) злетить усе одразу. На усіх серверах. Стикався з таким на все тому ж Active Directory. Через глюк на PDC лягла уся мережа, яка взагалі-то не використовувала можливості AD по централізованому зберіганню налаштувань.

[pvl]

я жодним чином не хоче в чомусь переконувати - я сам просто думаю чи треба воно мені
ось аргументація авторів
http://www.libelektra.org/Why_Linux_Needs_to_be_Elektrified
http://www.libelektra.org/Gnome_and_KDE_Integration

тепер до обговорення
0. то де більше порушення KISS i unix way - стандартний парсер конфігів чи окремий в кожній програмі?
1. знов же це може бути і файл а може бути і лдап і мускул і чорт зна шо
2. Централізація - це і основна перевага і основний недолік. Приклад - у мене лдап в якому зберігається інформація про користувачів. користувачів > 100, груп > 20. Цю інформацію використовує самба хеімдал цирус постфікс. Це зручніше чим заводити в кожному користувачів незалежно. Зрозуміло що як падає лдап то падає і вся ця конструкція.

[raven]

Щось мені кортить у якості превентивної міри зачинити гілку

Хтось тут зморозив дурницю і зараз буде покараний.

По-перше, як ви собі уявляєте імплементацію такого чуда? Варіанти є два.
Або змусити всіх розробників під загрозою ректального приниження використовувати єдиний стандарт конфігів. Можна, наприклад, зробити для цієї цілі чергову лібу і нею користуватись. Але, очевидно, так всіх не переконаєш, а Мігель взагалі почне спеціально свій config storage писати. Врешті, той же etc, вигляд збоку.
Або - клієнт-серверна архітектура. Про це вже prapor трохи висловився. Завалимо загальносистемний сервер конфігів - завалимо систему. Круто. Можу додати, що впровадження нового рівня абстракції ніяк не може додати швидкості. Що знов виникає проблема єдиного формату - правда вже не конфігураційних файлів, а способу запису в базу того нашого "центрального сховища". Що існування стандарту, можна сказати, спонукає до його порушення - якщо зараз є одне звалище з конфігами, в якому досить просто знайти потрібне, то буде їх багато, для кожної програми свій персональний хак - стандарти тому й називаються стандартами, що вводять певні обмеження, які інколи хочеться обійти.

По-друге. Доцільність. Подібний підхід має якийсь сенс тільки при великій кількості і складності конфігів. Ніщо не нове під місяцем, і ми можемо з насолодою споглядати gconf - чудо, створене виключно з метою уніфікувати конфігурацію монструозного DE. Конфігів там багато, але вони достатньо однотипні і за дизайном, і за задачею - хоча існування інструментів для "очистки реєстру gconf" навіює невеселі думи. Але прирівнювати задачі - і, відповідно, конфіги - десктопу до задач дуже різних системних сервісів було б, скажімо так, некоректно. Їх менше, і вони складніші.

По-третє. Дистрибутиви. Пакетних менеджерів, до вашого відома, є більше ніж один. Заставити пакетний менеджер зливати конфігурацію встановленого пакета, замість просто класти кофіг куди треба, злегка складніше. А якщо просто оновлювати пакет, то як перевірити, чи не перепишемо ми щось не те в тому реєстрі? А може, навпаки - недопишемо? Натурально, простіше руками змержити...

По-четверте. Локальна конфігурація. Якщо бути послідовним, то тому центральному відстійнику конфігів треба віддати й цю задачу. Зараз вони собі тихо-мирно лежать в ~, а так доведеться їх віддавати злому демону, щоб він ховав їх у свому лігві. І якщо знайдеться богатир, що того демона приб'є, своїх конфігів ми назад не отримаємо.


Резюме: трудозатрати на створення таких інструментів аж ніяк не виправдовують отриману вигоду.
Вердикт: в біореактор.

[raven]

ось аргументація авторів

Автори - придурошні студенти зі спермотоксикозом. До того ж думають, що розумніші за авторів гному/кед. Вони б почали писати Єдиний Тулкіт Для Написання Графічних Інтерфейсів Під Юнікс.

[Praporshic]

Подивився на аргументацію авторів. Діагноз встановлено (С). Якщо вони порівнюють системну базу користувачів з конфігураційним файлом, то це вже багато про що каже. Ці люди ніколи не займались справжнім адмініструванням. "High-level system administration GUIs are just a dream today" - хай мене вдарить якщо це не так. А налаштовувати систему, зазвичай, треба на низькому рівні. Тут ніщо не може замінити shell + favorite_text_editor.

Коротше кажучи: хлопці вирішили позбавити *nix головних переваг перед кватирками. Якби те, що використовується зараз було б таким поганим, то за 38 років вже знайшли б заміну.

[pvl]

чудово - ще одна конструктивна думка
1. стосовно примусу - нате він і впз що кожен може внести зміни. ніхто не завадить зробити патчі для відповідних програм. до того ж як висловився prapor алгоритми парсингу стандартні тож змінювати доведеться не дуже часто. Далі - ніхто не завадить додати відповідну опцію при компіляції - хочеш звичайний конфіг - хочеш ЦСК .

стандарти тому й називаються стандартами, що вводять певні обмеження, які інколи хочеться обійти

- це ви про майкрософт? бо саме вони люблять використовувати стандарти з кучею власних "хаків"
імплементація (хоч нових слів навчусь) - я схиляюсь до бібліотеки.
2. Доцільність - централізоване управління
3. Утиліти запису в ЦСК. (а нащо вам менеджер пакунків - а як він не туди запише - ні краще ручками ).
4. то я і кажу що схиляюсь до бібліотеки

[Володимир Лісівка]

0. то де більше порушення KISS i unix way - стандартний парсер конфігів чи окремий в кожній програмі?

Ша. Конфігураційний файл - це DSL (Domain Specific Language). Якщо ви напишете парсер будь-яких DSL-ів, то світова спільнота відлиє вам пам'ятник ще за життя. :-) Поки що набільший прогрес (з доступних реалізацій) є в perl6 - там є спеціальний синтаксис для опису DSL-ів. Хоча, звичайно, *Lex+*cc ніхто не відміняв - але це не пасер, це так як воно працює зараз.

Але давайте подумаємо над проблемою в загальному. Якщо є якийсь універсальний парсер конфігів, то йому, для того щоб він парсав конкретні типи конфігів, потрібна конфігурація, для якої потрібен парсер конфігів. :-) Для прикладу, в XML-і це вирішується з допомогою DTD.

А якщо серйозно, то стандартизація конфігів проводиться, просто вона проводиться трохи в іншому напрямку. Наприклад багато конфігів зараз підтримує .d каталоги, тобто каталог, в якому валяється купа файлів, які всі є фактично шматками великого конфігураційного файлу. Це потрібно для роботи пакетних систем.

Все інше нікого не обходить. Кому не підходять Flex+yacc, ті можуть використовувати доссть стандартні properties, ini-files, чи XML - для них є біліотеки.

[Володимир Лісівка]

2. Централізація - це і основна перевага і основний недолік. Приклад - у мене лдап в якому зберігається інформація про користувачів. користувачів > 100, груп > 20. Цю інформацію використовує самба хеімдал цирус постфікс. Це зручніше чим заводити в кожному користувачів незалежно. Зрозуміло що як падає лдап то падає і вся ця конструкція.

А в Гугла 150 тисяч машин. Якого розміру LDAP потрібен щоб витримати таке навантаження? :-)

До речі, є система конфігурації на основі DNS, яка вже вбудована в glibc/, hesiod називається. Тільки майже ніхто не користується - ніхто не хоче довіряти свої паролі та іншу чутливу інформацію DNS-у.