|
Навигация
|
Главная » IBM Работа с данными Active Directory c помощью сценариев: Часть 3. Проблемы, связанные с обработкой данных, загруженных из LDAP-сервераИсточник: ibm Рашид Ачилов ВведениеПосле изучения основного алгоритма обращения к LDAP-серверу через сценарии оболочки с помощью утилиты ldapsearch осталось рассмотреть две процедуры ldap_data_deconvert() и write_when_not_dn() .Проблемы возникающие при обработке данных Утилита ldapsearch в обязательном порядке выводит строку dn для объекта, поля которого будут распечатаны. В сценарии эту строку необходимо пропустить, но при этом возникает еще одна проблема: если в значении dn есть символы национальных алфавитов, то оно будет представлено base64 кодом. Поскольку значение dn может быть очень длинным, то длина закодированного значения зачастую превышает 80 символов, а у ldapsearch есть еще одна особенность - после 80 символов обязательно ставится символ перевода строки. Это мешает выполнить простой построчный анализ, но и отбрасывать символы перевода строки нельзя, так как тогда исчезнет разделение между атрибутами. Поэтому придется сделать несколько нетривиальных ходов. Для описания ldap_data_deconvert() достаточно сказать, что процедура write_when_not_dn() выводит данные, требующие преобразования в один файл, а не требующие - в другой и пропускает поле dn при чтении. У ldapsearch есть и еще одна особенность - если атрибут содержит данные в base64, то его значение отделяется от имени двумя символами двоеточия вместо одного. Таким образом, если есть второе поле - это данные, которые не требуют перекодировки, а если его нет, но есть третье - это данные, которые необходимо перекодировать.Листинг 1. Процедура ldap_data_deconvert()
Первые три строки после объявления переменных - пример того, как можно отбросить путь к файлу (еще для этого используется $(basename $1)) и его расширение, оставив только имя. Затем из файла удаляются все комментарии и пустые строки, и начинается его построчная разборка. Поскольку в выводе ldapsearch имя поля отделяется от данных двоеточием, каждая строка разбивается по этому символу.Если после разбора есть второе поле, то данные не нужно преобразовывать, достаточно проверить, не dn ли это (вызов процедуры write_when_not_dn() ). Если же после разбора остается третье поле (второе при этом не проверяется), то значит, это данные в кодировке base64, и они должны быть преобразованы, опять же, если это не dn . Если же нет ни второго, ни третьего полей - это промежуточная строка закодированных данных, и она должна быть присоединена к буферу, в который помещается недописанная строка. Данные действия выполняются до тех пор, пока не закончится входной файл.Если были обнаружены закодированные данные, то следует сбросить последнюю строку данных в файл с данными, подлежащими кодировке, в противном случае в файл, который не требует раскодирования. Дело в том, что утилитаmmencode не проверяет переданный ей текст, а пытается перекодировать его, независимо от содержимого. После этого остается отсортировать файлы, отобрать уникальные записи и декодировать файл с кодированным текстом. Декодирование идет по одной строке с последующим преобразованием в KOI8 и выводом символа перевода строки после каждой строки. Последней процедурой является write_when_not_dn() . Она не очень большая, но весьма запутанная, так как в ней используются внешние переменные.Листинг 2. Процедура write_when_not_dn()
Если первый параметр не задан (это часто случается при разборе закодированных данных), то следует сразу выйти из программы. Если во временном буфере существуют данные, сброшенные туда при предыдущем вызове, то их нужно записать в соответствующий файл. Если обнаруженный атрибут - dn , то можно пропустить данные, переданные при вызове и все следующие строки, пока снова не будет обнаружено два поля в строке. Иначе поместить данные во временный буфер и, если они не требуют преобразования, отметить это.Заключение Язык Bourne Shell не очень подходит для обработки данных, полученных из AD. Как видно, при этом постоянно приходится выполнять различные нестандартные действия и все равно работа получается с ограничениями, так, мне не удалось сделать одновременный запрос нескольких полей. Но его можно использовать для решения несложных задач, как было показано в данных статьях. Загрузка
Видео демонстрации по решению IBM Rational для совместного управления жизненным циклом. Семинар "Управление жизненным циклом приложений с помощью решения IBM Rational". Аутсорсинг проектов гибкой разработки: Часть 2. Пять самых полезных советов. Исследование современного состояния гибкой разработки. IBM Operational Decision Manager. Главная » IBM |
© 2024 Team.Furia.Ru.
Частичное копирование материалов разрешено. |