[Comm] LDAP-паранойя

[Comm] LDAP-паранойя

[Прокопьев Евгений]

Доброе утро!

После вчерашних обсуждений ldap для dhcp и dns задумался: по той ли 
дороге я иду?

Поэтому вернусь к постановке задачи.

Есть небольшая сеть. Есть сервер, который обеспечивает dhcp, внутренний 
и кэширующий dns, выпускание кого положено в интернет, заворачивание 
тех, кого надо на squid и т.д. Т.о. все настройки сервера, разбросанные 
по различным конфигурационным файлам, можно разделить на 2 категории:

1. редко меняющиеся: общая политика разграничения доступа, набор 
сервисов, адресация (маска, адреса шлюза, прокси, dns) и т.д
2. часто меняющиеся: имена, ip-адреса и mac-адреса рабочих станций, 
которые приходят и уходят, права доступа в интернет и т.д.

Так вот, хочется собрать то, что меняется часто, в одно место :)
Например, в виде следующей таблички:

mac-адрес рабочей станции
ip-адрес
dns-имя
доступ в интернет:
	можно или нет
	через прокси или напрямую
	когда и сколько можно
и пр.

Ну и сделать к ней GUI, чтоб тот (назовем его админ ;) ), кто будет 
менять настройки, не утруждался :)

Первой мыслью было: а может и использовать какую-нибудь примитивную СУБД 
типа MySQL? А из него по требованию генерить конфиги для dns, dhcp, 
squid, стартовый скрипт или прямо сразу дамп для iptables. И в ту же БД 
писать биллинг.

Второй мыслью было: а ведь сейчас модно хранить настройки в ldap! А 
ну-ка! Все ведь умеют, кроме iptables. Но чтоб ядро, обрабатывающее 
правила, лазило за ними в ldap - это, наверное, жестоко. Поэтому для 
iptables можно и генерить чего-нибудь по мере надобности.

Вот, а теперь вопрос: я правильно рассуждаю? О ldap имею очень смутные 
представления, но уже понимаю, что у каждого сервиса - своя схема :) . 
Т.е. как в реляционной СУБД - свой набор таблиц. Но это не очень красиво 
- мы просто меняем шило на мыло. Идеалом был бы единый набор таблиц, а 
для каждого сервиса - набор представлений (view) из этих таблиц. Прошу 
прощения за терминологию из другой области, так оно мне проще. И как это 
реализовать? Перелопачивать все необходимые мне схемы и делать свою? А 
если одно и то же в разных схемах называется по разному? Есть 
какой-нибудь механизм псевдонимов?

Вот такая у меня в голове сейчас каша. Прошу прокомментировать.

-- 
С уважением, Прокопьев Евгений

Re: [Comm] LDAP-паранойя

[Nick S. Grechukh]

В сообщении от Среда 31 Март 2004 08:44 Прокопьев Евгений написал(a):
> Доброе утро!
>
> После вчерашних обсуждений ldap для dhcp и dns задумался: по той ли
> дороге я иду?
>
> Поэтому вернусь к постановке задачи.
>
> Есть небольшая сеть. Есть сервер, который обеспечивает dhcp, внутренний
> и кэширующий dns, выпускание кого положено в интернет, заворачивание
> тех, кого надо на squid и т.д. Т.о. все настройки сервера, разбросанные
> по различным конфигурационным файлам, можно разделить на 2 категории:
>
> 1. редко меняющиеся: общая политика разграничения доступа, набор
> сервисов, адресация (маска, адреса шлюза, прокси, dns) и т.д
> 2. часто меняющиеся: имена, ip-адреса и mac-адреса рабочих станций,
> которые приходят и уходят, права доступа в интернет и т.д.
>
> Так вот, хочется собрать то, что меняется часто, в одно место :)
> Например, в виде следующей таблички:
>
> mac-адрес рабочей станции
> ip-адрес
> dns-имя
> доступ в интернет:
> 	можно или нет
> 	через прокси или напрямую
> 	когда и сколько можно
> и пр.
>
> Ну и сделать к ней GUI, чтоб тот (назовем его админ ;) ), кто будет
> менять настройки, не утруждался :)
>
> Первой мыслью было: а может и использовать какую-нибудь примитивную СУБД
> типа MySQL? А из него по требованию генерить конфиги для dns, dhcp,
> squid, стартовый скрипт или прямо сразу дамп для iptables. И в ту же БД
> писать биллинг.
>
> Второй мыслью было: а ведь сейчас модно хранить настройки в ldap! А
> ну-ка! Все ведь умеют, кроме iptables. Но чтоб ядро, обрабатывающее
> правила, лазило за ними в ldap - это, наверное, жестоко. Поэтому для
> iptables можно и генерить чего-нибудь по мере надобности.
>
> Вот, а теперь вопрос: я правильно рассуждаю? О ldap имею очень смутные
> представления, но уже понимаю, что у каждого сервиса - своя схема :) .
> Т.е. как в реляционной СУБД - свой набор таблиц. Но это не очень красиво
> - мы просто меняем шило на мыло. Идеалом был бы единый набор таблиц, а

коротко: один объект (dn) может иметь несколько (относиться к нескольким) 
классам. т.е. в ou=Users cодержатся к примеры юзеры. и у них
objectclass=posixaccount(для входа в систему)
objectclass=Shadowaccount (для настроек типа как часто менять пароль и т.п.)
objectclass=sambaSAMAccount (для самбы)
objectclass=qmail
и т.д.
и все это  у одного юзера, в одной записи ldap.

Re: [Comm] LDAP-паранойя

[Maxim]

Здравствуйте, Прокопьев.

Вы писали 31 марта 2004 г., 9:44:34:

ПЕ> Доброе утро!

ПЕ> После вчерашних обсуждений ldap для dhcp и dns задумался: по той ли 
ПЕ> дороге я иду?

ПЕ> Поэтому вернусь к постановке задачи.

ПЕ> Есть небольшая сеть. Есть сервер, который обеспечивает dhcp, внутренний 
ПЕ> и кэширующий dns, выпускание кого положено в интернет, заворачивание 
ПЕ> тех, кого надо на squid и т.д. Т.о. все настройки сервера, разбросанные 
ПЕ> по различным конфигурационным файлам, можно разделить на 2 категории:

ПЕ> 1. редко меняющиеся: общая политика разграничения доступа, набор 
ПЕ> сервисов, адресация (маска, адреса шлюза, прокси, dns) и т.д
ПЕ> 2. часто меняющиеся: имена, ip-адреса и mac-адреса рабочих станций, 
ПЕ> которые приходят и уходят, права доступа в интернет и т.д.

ПЕ> Так вот, хочется собрать то, что меняется часто, в одно место :)
ПЕ> Например, в виде следующей таблички:

ПЕ> mac-адрес рабочей станции
ПЕ> ip-адрес
ПЕ> dns-имя
ПЕ> доступ в интернет:
ПЕ> 	можно или нет
ПЕ> 	через прокси или напрямую
ПЕ> 	когда и сколько можно
ПЕ> и пр.

ПЕ> Ну и сделать к ней GUI, чтоб тот (назовем его админ ;) ), кто будет 
ПЕ> менять настройки, не утруждался :)

ПЕ> Первой мыслью было: а может и использовать какую-нибудь примитивную СУБД 
ПЕ> типа MySQL? А из него по требованию генерить конфиги для dns, dhcp, 
ПЕ> squid, стартовый скрипт или прямо сразу дамп для iptables. И в ту же БД 
ПЕ> писать биллинг.

ПЕ> Второй мыслью было: а ведь сейчас модно хранить настройки в ldap! А 
ПЕ> ну-ка! Все ведь умеют, кроме iptables. Но чтоб ядро, обрабатывающее 
ПЕ> правила, лазило за ними в ldap - это, наверное, жестоко. Поэтому для 
ПЕ> iptables можно и генерить чего-нибудь по мере надобности.

ПЕ> Вот, а теперь вопрос: я правильно рассуждаю? О ldap имею очень смутные 
ПЕ> представления, но уже понимаю, что у каждого сервиса - своя схема :) . 
ПЕ> Т.е. как в реляционной СУБД - свой набор таблиц. Но это не очень красиво 
ПЕ> - мы просто меняем шило на мыло. Идеалом был бы единый набор таблиц, а 
ПЕ> для каждого сервиса - набор представлений (view) из этих таблиц. Прошу 
ПЕ> прощения за терминологию из другой области, так оно мне проще. И как это 
ПЕ> реализовать? Перелопачивать все необходимые мне схемы и делать свою? А 
ПЕ> если одно и то же в разных схемах называется по разному? Есть 
ПЕ> какой-нибудь механизм псевдонимов?

ПЕ> Вот такая у меня в голове сейчас каша. Прошу прокомментировать.

По моему опыту, если работал с SQL то с ldap как то не очень понравилось.
Я пробовал хранить в нем что-нибудь, но уж больно заморочено с конфигурацией.
Плюс у него один, это деревообразная структура.  Чего в SQL нету, по крайней
мере встроенного. Ну и репликация там кажется работает хорошо, вернее она
изначально учитывалась при создании протокола.
Вообще дело вкуса.
Кстати Ldap может свои струтуры хранить в Sql ной базе.

-- 
С уважением,
 Maxim                          mailto:max_conf@e-foto.ru

[Comm] Re: LDAP-паранойя

[Michael Shigorin]

On Wed, Mar 31, 2004 at 01:40:59PM +0400, Maxim wrote:
> По моему опыту, если работал с SQL то с ldap как то не очень понравилось.

Здрасьте.

> Я пробовал хранить в нем что-нибудь, но уж больно заморочено с
> конфигурацией.  Плюс у него один, это деревообразная структура.

Это не "плюс", это другой подход.  Совсем другой.

> Чего в SQL нету, по крайней мере встроенного.

Скажем так... в педально-весельном режиме эмулируется, но как же
умиляют потуги на XML DB на базе SQL DB...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/