proNovell

Коллеги, извините, если просмотрел существующую тему... тогда буду благодарен за ссылку на нее.

Вопрос 1: есть ли у кого реально работающая промышленная база данных чисто на NDS/eDIR ?

Предполлагается, что схему существующих объектов расширили ( в идеале - создали свои объекты) , на основе низкоуровневых API/SDK создали программные инструменты, ну и далее - построение базы...
И хранят данные, как значений соответствующих атрибутов.

Интересует не теоритические возможности (каковые, без сомнения, имеются), а реально работающая база, достаточно большая, ответственная.
Похвалитесь, у кого есть чем...

Вопрос задан в рамках исследования возможность построения базы "Кадры" на основе свойств Дерева.

Вопрос 2: В дебрях Сети встречалось упоминание о возможности хранить EXE-модули (которые используют в логин-скриптах) внутри Дерева. В целях отвязки от файловой системы и от конкретного сервера, дабы т.о. повысить отказоустойчивость логин-скрипта.
Кто либо из коллег реально применяет (может, просто прорбовал?) этот механизм?

А как вы боретесь с перспективой остановки ключевого логин-сервера?

Спасибо.

Музалёв Николай писал(а):Вопрос задан в рамках исследования возможность построения базы "Кадры" на основе свойств Дерева.

А как насчет eGuide?

Может, я не то читал, но из

Код: Выделить всё

eGuide is a web application that lets you easily and quickly search for directory based information. Novell eGuide provides you a single location to search for the people, place, and things you need to know.

следует, что это инструмент поиска в Дереве, но это же не всё.
А занесение информации, а сортировка?...

Немного не по теме, но мы похожую ( до некоторой степени ) задачу хотим попробовать решить с помощь Identity Manager. Т.е. есть некие готовые продукты, на основе SQL ( MS SQL, MySQL - не суть ), со своим фронт ендом, через который бюрократы заносят инфу по персоналу. Далее предполагается, что IDM мог бы синхронизировать атрибуты пользователей в еДире с нужными полями в базе, после чего просматривать эти атрибуты можно было бы широкому кругу лиц ( в том же еГаде хотя бы, или через веб - РНР и т.п. ).

Кроме этого еще хочется настроить синхронизацию полей одной такой базы с другой, через IDM - через еДир. Вот не знаю, что из всего этого выйдет ..

А занесение информации, а сортировка?...

Возможны.
Почитать на русском можно например здесь.

но не потому, что мы этого не хотим, а потому что мы пишем для широкого круга пользователей, в том числе и на слабеньких одиночных машинах и в частности именно задача Кадры сделана с применением идей, заложенных в Edir. Правда для этого пришлось сделать набор объектов, которые бы имитировали нужные функции на первазиве (без SQL).
Объектная база как нельзя лучше подходит для решения этой задачи.
А проблема в кадровой задаче не в выборе базы, хотя SQL базы для этой цели IMHO слабо годятся. А персонально Николаю - можешь придти к нам в гости и посмотреть на это все, мы очень успешно эту задачу тиражируем.

...в гости...

Спасибо, с удовольствием. Разгребу текучку и напомню о себе.

с одним из заказчиков. Будем делать доработку, чтобы кадры брали информацию из edir о доступных разделах личной информации, поскольку на самом деле этой задачей пользуются и кадры и бухгалтерия и начальство и профком и медики .... А понятно, что далеко не всем надо все видеть. И самое удобное средство для этого - RBS.
Тем более, что они этим уже хорошо владеют, поскольку в одной из подсистем оно уже вовсю используется.

средство... - RBS ...хорошо владеют

Увы, пропустил эту аббрев., можно подробнее? об RBS и, если возможно, о задаче в целом?

Это та штука, которой мы назначаем роли в iManager.
Вещь на самом изумительная по простоте понимания и пользования в своих разработках. Совершенно становятся ненужными всякие локальные базки юзеров в каждой задаче, которые по вполне очевидным причинам не обладают ни достаточной защищенностью и требуют усилий на их создание. А реально мы RBS используем в задаче, которая обслуживает СТО (станцию технического обслуживания автомобилей) и аналогичное подразделение нормального автопарка.
Там защита должна быть на должном уровне, потому как если неавторизованный работник закроет работу по ремонту и выпустит автомобиль, а она выполнена некачественно и потом автобус с пассажирами в результате попадет в аварию, то понятно, что придут разные органы и начнут разбираться что и как. Понятно, что делать такую самописную базку как-то не хочется. А народные умельцы там имеются и кадры еще те.

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

А так один раз сбацали дельфийский объект и теперь прикладные программисты одной строчкой кода в нужных местах управляют тем, чем им надо.

Boris Morozov писал(а):А так один раз сбацали дельфийский объект и теперь прикладные программисты одной строчкой кода в нужных местах управляют тем, чем им надо.

Еще поподробнее можно ? Где именно объект - в еДире ( если так, то почему он дельфийский ) ? Т.е. у вас в еДире созданы свои классы объектов под задачу, или расширения стандартных ( типа пользователь, но с доп. атрибутами ) ? и каким образом конечный пользователь ( типа механик ) вносит изменения в базу - через веб-интерфейс, где роли и задачи описаны в RBS, или же через самописную прогу ( на дельфи, как я понял ) ? Тогда RBS используется просто для раздачи прав на нужные объекты / атрибуты ?

нас полностью устраивают стандартные объекты RBS даже с избытком.
Корректировка базы идет с помощью C1 или iManager. На объектах народ работает с С1. Причем занимается этим ИВЦ. Начальник ремзоны пишет заяву.

Дельфийский объект только читает информацию. Он написан на основе стандартного API с developer.novell.com. Это DCU и DLL. DLL нужна для того, чтобы можно было работать на локальных машинах иначе из-за каличности механизма линковки у микрософта программа не грузится без NW клиента. Пришлось заниматься гемором и делать промежуточную DLL. Зато теперь работает в любом варианте. Понятно, что на локальной машине ни о каком распределении прав речь не идет. Но там это и не надо(пока), надо будет, сочиним что-нибудь.

Николай, возвращаясь к Вашему вопросу, хочу поделиться своим скромным опытом в деле иллюстрации возможностей eDirectory. Некоторое время тому назад мне понадобилось продемонстрировать одному заказчику возможность eDirectory управляться с достаточно серьезными объемами данных, речь шла о миллионах или даже десятках миллионов объектов в одном дереве. Реальными данными заказчик не располагал, поэтому мне пришлось в качестве наполнителя придумать нечто свое. Один из коллег поделился устаревшим CD с данными ГИБДД по городу Москве за Июнь 2000г. На этом CD была обнаружен MDB файл в формате MS Access, который был экспортирован в обычный текстовый, который в свою очередь я сконвертировал в LDIF файл. Его-то я и залил в eDirectory при помощи утилиты ICE. В итоге получилось без малого 3,5 миллиона объектов, которые можно было просматривать через eGuide. Со стороны Internet этот самый eGuide был прикрыт SSLizer'ом Novell iChain v2.3. Дерево располагалось на двух серверах: Master replica NW6.5 на сервере HP LH6000, R/W replica Win2000 Adv.Server на HP ML350. iChain располагался на HP LP1000r. Если есть интерес, то на следующей неделе я оживлю эту тестовую систему, снабжу Вас User/Passowrd. Ну а Вы броузером все посмотрите сами.

К слову, про ICE - тут для себя недавно открыл одну из ее возможностей, импорта из обычного CSV, не LDIF. Чем-то напомнило UIMPORT - имеем два файла, один с описанием последовательности полей ввода ( в данном случае - атрибутов LDAP ), второй - с набором этих последовательностей - атрибутов, идущих через запятую. Наверно, это знают все, кто пользуется ICE, но я как-то больше привык в визарду в С1, так что вот не знал ..

Andrey Karyagin

Интересно, а сколько времени ушло на импорт в еДир такой базы ?

Вариант 1: импорт в Master реплику (HP LH6000) из LDIF файла, располагающегося на томе SYS: занял примерно 53 часа.
Вариант 2: импорт в R/W реплику (HP ML 350) из того же LDIF файла, располагающегося на диске C: занял примерно 48 часов.

Что касается ICE и CSV, то будьте осторожны - ICE не всегда должным образом импортирует атрибуты, содержащие русскоязычные символы!