* [Comm] LDAP-паранойя
@ 2004-03-31 5:44 Прокопьев Евгений
2004-03-31 8:42 ` Nick S. Grechukh
2004-03-31 9:40 ` Maxim
0 siblings, 2 replies; 4+ messages in thread
From: Прокопьев Евгений @ 2004-03-31 5:44 UTC (permalink / raw)
To: Community
Доброе утро!
После вчерашних обсуждений 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) из этих таблиц. Прошу
прощения за терминологию из другой области, так оно мне проще. И как это
реализовать? Перелопачивать все необходимые мне схемы и делать свою? А
если одно и то же в разных схемах называется по разному? Есть
какой-нибудь механизм псевдонимов?
Вот такая у меня в голове сейчас каша. Прошу прокомментировать.
--
С уважением, Прокопьев Евгений
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Comm] LDAP-паранойя
2004-03-31 5:44 [Comm] LDAP-паранойя Прокопьев Евгений
@ 2004-03-31 8:42 ` Nick S. Grechukh
2004-03-31 9:40 ` Maxim
1 sibling, 0 replies; 4+ messages in thread
From: Nick S. Grechukh @ 2004-03-31 8:42 UTC (permalink / raw)
To: community
В сообщении от Среда 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Comm] LDAP-паранойя
2004-03-31 5:44 [Comm] LDAP-паранойя Прокопьев Евгений
2004-03-31 8:42 ` Nick S. Grechukh
@ 2004-03-31 9:40 ` Maxim
2004-03-31 19:22 ` [Comm] LDAP-паранойя Michael Shigorin
1 sibling, 1 reply; 4+ messages in thread
From: Maxim @ 2004-03-31 9:40 UTC (permalink / raw)
To: Прокопьев
Евгений
Здравствуйте, Прокопьев.
Вы писали 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Comm] Re: LDAP-паранойя
2004-03-31 9:40 ` Maxim
@ 2004-03-31 19:22 ` Michael Shigorin
0 siblings, 0 replies; 4+ messages in thread
From: Michael Shigorin @ 2004-03-31 19:22 UTC (permalink / raw)
To: Прокопьев
Евгений
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-03-31 19:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-31 5:44 [Comm] LDAP-паранойя Прокопьев Евгений
2004-03-31 8:42 ` Nick S. Grechukh
2004-03-31 9:40 ` Maxim
2004-03-31 19:22 ` [Comm] LDAP-паранойя Michael Shigorin
ALT Linux Community general discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 community community/ http://lore.altlinux.org/community \
mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com
public-inbox-index community
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.community
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git