From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 31 Mar 2004 13:40:59 +0400 From: Maxim Organization: Home X-Priority: 3 (Normal) Message-ID: <1812000775.20040331134059@e-foto.ru> To: =?koi8-r?B?8NLPy8/Q2MXXIOXXx8XOyco=?= Subject: =?koi8-r?B?UmU6IFtDb21tXSBMREFQLdDB0sHOz8rR?= In-Reply-To: <406A5AC2.3090702@rmts.donpac.ru> References: <406A5AC2.3090702@rmts.donpac.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: community@altlinux.ru List-Id: Mailing list for ALT Linux users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 09:41:05 -0000 Archived-At: List-Archive: List-Post: Здравствуйте, Прокопьев. Вы писали 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