[Comm] OpenLDAP: единое дерево для разных сервисов

[Comm] OpenLDAP: единое дерево для разных сервисов

[Eugene Prokopiev]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

Здравствуйте!

Поднят openldap. bind и dhcpd берут из него свои настройки. Дерево ldap 
выглядит примерно так (как его рисует gq, ldif в аттаче):

localhost
	dc=myserver,dc=myprovider,dc=ru
		ou=DNS
			relativeDomainName=@
			relativeDomainName=ns
			relativeDomainName=mail
			relativeDomainName=host1
			relativeDomainName=host2
		cn=DHCP Config
			cn=192.168.1.0
				cn=host1
			cn=192.168.3.0
				ch=host2

Возможно, в будущем появятся новые нестандартные сервисы, которые так 
же, как bind и dhcpd, потребуют хранить какие-либо атрибуты хостов сети.

Самое главное, что мне не нравится - у каждого сервиса фактически 
собственное изолированное от других дерево. Т.е. с заменой 
конфигурационных файлов на LDAP мы меняем шило на мыло.

Ближайший аналог того, что мне хочется - технология XSLT. Т.е. имеем 
основное дерево XML с той структурой, которая удобна мне (например, в 
список атрибутов объекта хост входят одновременно dns-имя, ip-адрес, 
mac-адрес). Только в это дерево можно вносить изменения. К этому дереву 
можно применять XSLT-преобразования (для bind свое, для dhcpd свое и 
т.д.) и получать на выходе деревья для каждого сервиса с необходимой для 
этого сервиса структурой.

Как реализовать в openldap нечто подобное?

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

[-- Attachment #2: network.ldif --]
[-- Type: text/plain, Size: 3319 bytes --]

dn: dc=myserver, dc=myprovider, dc=ru
objectClass: top
objectClass: dhcpServer
objectClass: organizationalUnit
cn: myserver.myprovider.ru
dhcpServiceDN: cn=DHCP Config, dc=myserver, dc=myprovider, dc=ru
ou: DNS

dn: ou=DNS, dc=myserver, dc=myprovider, dc=ru
objectClass: top
objectClass: dNSZone
relativeDomainName: myserver.myprovider.ru
zoneName: myserver.myprovider.ru

dn: relativeDomainName=@, ou=DNS, dc=myserver, dc=myprovider, dc=ru
objectClass: top
objectClass: dNSZone
relativeDomainName: @
zoneName: myserver.myprovider.ru
sOARecord: ns.myserver.myprovider.ru. hostmaster.myserver.myprovider.ru. 2004040401 12H 1H 1W 
 1H
nSRecord: ns.myserver.myprovider.ru.
mXRecord: 10 mail.myserver.myprovider.ru.

dn: relativeDomainName=ns, ou=DNS, dc=myserver, dc=myprovider, dc=ru
objectClass: top
objectClass: dNSZone
relativeDomainName: ns
zoneName: myserver.myprovider.ru
dNSClass: IN
aRecord: 192.168.1.1

dn: relativeDomainName=mail, ou=DNS, dc=myserver, dc=myprovider, dc=ru
objectClass: top
objectClass: dNSZone
relativeDomainName: mail
zoneName: myserver.myprovider.ru
dNSClass: IN
aRecord: 192.168.1.1

dn: relativeDomainName=host1, ou=DNS, dc=myserver, dc=myprovider, dc=ru
objectClass: top
objectClass: dNSZone
relativeDomainName: host1
zoneName: myserver.myprovider.ru
dNSClass: IN
aRecord: 192.168.1.2

dn: relativeDomainName=host2, ou=DNS, dc=myserver, dc=myprovider, dc=ru
objectClass: top
objectClass: dNSZone
relativeDomainName: host2
zoneName: myserver.myprovider.ru
dNSClass: IN
aRecord: 192.168.3.4

dn: cn=DHCP Config, dc=myserver, dc=myprovider, dc=ru
cn: DHCP Config
objectClass: top
objectClass: dhcpService
dhcpPrimaryDN: cn=myserver.myprovider.ru, dc=myserver, dc=myprovider, dc=ru
dhcpStatements: ddns-update-style none

dn: cn=192.168.1.0, cn=DHCP Config, dc=myserver, dc=myprovider, dc=ru
cn: 192.168.1.0
objectClass: top
objectClass: dhcpSubnet
objectClass: dhcpOptions
dhcpNetMask: 24
dhcpRange: dynamic-bootp 192.168.1.128 192.168.1.255
dhcpStatements: default-lease-time 21600
dhcpStatements: max-lease-time 43200
dhcpOption: routers 192.168.1.1
dhcpOption: subnet-mask 255.255.255.0
dhcpOption: domain-name "myserver.myprovider.ru"
dhcpOption: domain-name-servers 192.168.1.1
dhcpOption: time-offset -5
dhcpOption: ntp-servers 192.168.1.1
dhcpOption: netbios-name-servers 192.168.1.1

dn: cn=host1, cn=192.168.1.0, cn=DHCP Config, dc=myserver, dc=myprovider, dc=ru
cn: host1
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:0C:29:84:99:6B
dhcpStatements: fixed-address 192.168.1.2

dn: cn=192.168.3.0, cn=DHCP Config, dc=myserver, dc=myprovider, dc=ru
cn: 192.168.3.0
objectClass: top
objectClass: dhcpSubnet
objectClass: dhcpOptions
dhcpNetMask: 24
dhcpRange: dynamic-bootp 192.168.3.128 192.168.3.255
dhcpStatements: default-lease-time 21600
dhcpStatements: max-lease-time 43200
dhcpOption: routers 192.168.3.1
dhcpOption: subnet-mask 255.255.255.0
dhcpOption: domain-name "myserver.myprovider.ru"
dhcpOption: domain-name-servers 192.168.1.1
dhcpOption: time-offset -5
dhcpOption: ntp-servers 192.168.1.1
dhcpOption: netbios-name-servers 192.168.1.1

dn: cn=host2, cn=192.168.3.0, cn=DHCP Config, dc=myserver, dc=myprovider, dc=ru
cn: host2
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:0C:29:84:99:5B
dhcpStatements: fixed-address 192.168.3.4

Re: [Comm] OpenLDAP: единое дерево для разных сервисов

[Eugene Prokopiev]

> Ближайший аналог того, что мне хочется - технология XSLT. Т.е. имеем 
> основное дерево XML с той структурой, которая удобна мне (например, в 
> список атрибутов объекта хост входят одновременно dns-имя, ip-адрес, 
> mac-адрес). Только в это дерево можно вносить изменения. К этому дереву 
> можно применять XSLT-преобразования (для bind свое, для dhcpd свое и 
> т.д.) и получать на выходе деревья для каждого сервиса с необходимой для 
> этого сервиса структурой.

Ну нашел буквально то, что искал - http://www.dsmltools.org/
Коротко: есть оказывается диалект xml для описания ldap и средства 
преобразования из одного в другое.

Однако же, чем дальше в лес, тем толще партизаны ;)

Получается, что переконфигурирование системы (всего-то добавление новой 
рабочей станции в сеть) приведет к следующей последовательности действий:

1. Пишем либо меняем главный xml-конфиг (руками либо гуём)
2. Посредством xslt генерим из него dsml
3. Далее на выбор: либо удаляем все содержимое дерева ldap и воссоздаем 
его из dsml, либо извлекаем то, что есть в виде dsml, сравнивем с тем, 
что нагенерили, и применяем изменения (чую, что последнее чревато 
страшными глюками)
4. Наконец данные в ldap - теперь те, кто умеет, читает прямо из него, а 
для тех, кто не умеет или не должен (например, iptables) генерятся 
конфиги, стартовые скрипты и рестартуются соответствующие сервисы

Ну как?

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

Re: [Comm] OpenLDAP: единое дерево для разных сервисов

[Pavel S. Khmelinsky]

Eugene Prokopiev wrote:
> Здравствуйте!
> 
> Поднят openldap. bind и dhcpd берут из него свои настройки. Дерево ldap 
> выглядит примерно так (как его рисует gq, ldif в аттаче):
> 
> localhost
>     dc=myserver,dc=myprovider,dc=ru
>         ou=DNS
>             relativeDomainName=@
>             relativeDomainName=ns
>             relativeDomainName=mail
>             relativeDomainName=host1
>             relativeDomainName=host2
>         cn=DHCP Config
>             cn=192.168.1.0
>                 cn=host1
>             cn=192.168.3.0
>                 ch=host2
> 
> Возможно, в будущем появятся новые нестандартные сервисы, которые так 
> же, как bind и dhcpd, потребуют хранить какие-либо атрибуты хостов сети.
> 
> Самое главное, что мне не нравится - у каждого сервиса фактически 
> собственное изолированное от других дерево. Т.е. с заменой 
> конфигурационных файлов на LDAP мы меняем шило на мыло.
> 
> Ближайший аналог того, что мне хочется - технология XSLT. Т.е. имеем 
> основное дерево XML с той структурой, которая удобна мне (например, в 
> список атрибутов объекта хост входят одновременно dns-имя, ip-адрес, 
> mac-адрес). Только в это дерево можно вносить изменения. К этому дереву 
> можно применять XSLT-преобразования (для bind свое, для dhcpd свое и 
> т.д.) и получать на выходе деревья для каждого сервиса с необходимой для 
> этого сервиса структурой.
> 
> Как реализовать в openldap нечто подобное?

Не знаю помоему самое разумное решение это держать общее для всех 
связных сервисов дерево, их которого спец. скриптам по крону или 
по событию парсить конфиг сервиса.
Либо нужно патчить сервис на предмет чтения настроек из Вашего 
основного дерева в том виде в котором Вы его храните. Это 
актуально для таких сервисов как например Radius.

Содержания обособленных деревьев для каждого сервиса в LDAP (или 
в другой БД) это действительно шило на мыло, с одной оговоркой к 
большинству БД, в отличие от текстовых конфигов, можно легко 
получить удаленный доступ, что помогает при написание, например 
веб интерфейсов физически расположенных на другой машине.

Собсно мои соображения. ;)

-- 
Pavel S. Khmelinsky <hmepas@yauza.ru>
System Administrator,
ISP Yauza Telecom
http://www.yauza.ru