[Comm] announce: Office Server 4.0 beta 5

[Денис Черносов]

>   Какая, например, информация из DHCP может использоваться, будучи
>   помещённой в LDAP?

Как недавно прозвучало, нужно наверное озвучивать проблему, писать ТЗ, а уже
потом подбирать инструментарий...

В общем, мысль какая:
В том же ActiveDirectory компьютер - это объект довольно навороченный. Можно
и расположение его указать и отдел, к которому он прикреплен и т.п. Что само
по себе удобно - конфиг и коммент в одном флаконе. Это раз.

Два состоит в том, чтобы минимизировать и автоматизировать настройки
клиентов, без потери гибкости управления. Для того, чтобы опознавать машины,
нужна привязка к железу. Сетевые карточки меняются редко. И, как правило,
админ в курсе (или имеет полное право быть в курсе) каких-то изменений
[sample message: "в сети появился объект с неопознанным mac-адресом.
Тревога/Игнор/Заполнить_информацию_о_компьютере"]. Так что естественным
идентификатором системного блока, который необходимо хранить в центральной
базе будет mac. Там же должны быть статические или динамические ip+hostname.
Если всё это известно и информация всегда актуальна, то можно и в
мониторинге использовать человеческие адреса, а-ля "третий слева на втором
этаже в бухгалтерии" и те же настройки firewall привязывать к mac-адресам и
мало ли чего еще напридумывать можно по этому поводу (например, агрегировать
статистику по трафику по отделам, фильтруя учетные записи по комментам к
учеткам компов или веткам, в которых эти учетки лежат).

Три состоит в том, что без самбы сеть малого и среднего офиса - скорее
исключение, чем правило. А в самбе есть SambaMachineAccount, который в свою
очередь требует создание PosixAccount. Это не добавляет особых удобств -
скорее создает новые ограничения. Имя машины в SambaMachineAccount не должно
отличаться от dhcp-hostname, к примеру. Так что лучше будет, если объект
"компьютер" будет иметь и objectclass=PosixAccount, и
objectclass=SambaAccount. И группу под такие объекты желательно заводить
сразу. И редактировать из одного места, чтобы накладок не было.

И, наконец, четыре: желательно фиксировать/задавать доп. параметры объекта
"пользователь". IP, mac, proxy, правила доступа в какой-то форме или ссылка
на объект с правилами. Типа того, как здесь:
http://www.samba.org.ua/articles/?section=1&articleid=71

А чтобы меньше было геморроя, нужен еще и механизм наследования разрешений
от групп, в которые входит этот пользователь и машин, с которых он выходит
(Васе Пупкину, как члену группы админов домена, дозволено всё, но только не
с компа главного бухгалтера). Хочу акцентировать внимание читающих, что
сложность с точки зрения внутренней кухни, компенсируется дальнейшей
интуитивностью в обслуживании (по мотивам etcnet).

Опять же, по мотивам, etcnet, почему бы не расписать рекомендации, по
организации хранилища этих записей.
Например, есть ветка cn=AdminsGroup,dc=domain,dc=loc. Почему бы не
договориться, что все соотв. учетные записи юзеров-админов, должны храниться
в этой ветке, а если учетная запись нужна еще в какой-то ветке
(cn=Users,ou=Samara,o=CompanyLtd,c=ru), то там нужно ставить ссылку на этот
"лист". "Примат соглашений над конфигурациями" сделает внедрение,
сопровождение и поддержку этого хозяйства более унифицированным.

Ввиду идеологии использования LDAP, первоначальное проектирование имеет
решающее значение, ибо обновление схемы - процедура нежелательная. Поэтому
закладывание в проект не самых востребованных атрибутов "на вырост" и "про
запас", мне кажется оправданным.

А зоны ДИНАМИЧЕСКОГО DNS в LDAP помещать удобнее, потому что потом удобнее
залезть и поправить что-то ручками, а не применять nsupdate, который для
эпизодического встревания в процесс подходит... неидеально. Абсолютно все
статические записи резервировать и помещать в dns через dhcp мне кажется
спорным, хотя... Если будет так, то зоны dns в ldap действительно не нужны.
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/community/attachments/20080331/d039877a/attachment.html>