By the Shade of the Tree

В тени электронного дерева

20080730

PAM, LUM и прочие NAMы

Ну разьве можно не любить технологии с такими звучными аббривеатурами... Суть содеянного здесь. От себя добавлю что
  1. Не работает замечательная, призванная уменьшить нагрузку на сеть штука под названием nscd. Это лечится прописью в файлик /etc/nscd.conf слов no напротив каждой записи enable-cache. (Нерабочесть заключается в сообщениях nscd: nds_nss_GetPwdbyName: init sock returned -1. Буду потом разбираться что за сокет такой, и чего это он не работает. Может нужно из под другог юзера запускать ее, а не из-под nobody.)
  2. Мешает отладке наличие директивы enable-persistent-cache=no в конфиге /etc/nam.conf
  3. К глубочайшему сожалению, NAM почему то не вытаскивает из директории юзеров с именами по 4 и менее буков. Учитывая, что SUSE вполне нормально с такими юзерами работает... Непонятно, в общем. Понимает он, он все понимает, он умный. Это я глупый. Дело в том что NAM выбирает юзеров не по CN а по uniqueID. Не повторяйте моих ошибок.

20080722

Архивирование trustee

TRUSTBAR.NLM - Хоть что то работает как надо, и выдает результаты в приличный формат.

20080718

Горелые яблоки

Ура! На нашем xServe сгорела PCIX сетевуха, теперь он не в локальной сети и проблема связи его с деревом временно отпадает... Попутно выясняется, что не каждая сетевуха подходит к xServe. Будем искать совместимую.

20080716

Пароли

У меня одного ощущение что пароли в eDirectory хранятся несколько неочевидно?

Есть пароль который simple. Он хранится в атрибутах sASLogin чего то там, числом два атрибута. Если вручную копировать значения обоих этих атрибутов, пароль копируется. Но: только в пределах одного сервера. Скопировать простой пароль таким способом не удалось.

Еще есть пароль который universal. Он покрыт тайной и мраком.

Есть политики паролей. В них можно сказать чтобы при установке universal пароля все остальные с ним синхронизировались. Это хорошо.

При импорте юзеров из LDIF файла где было прописано поле userPassword установился пароль который simple. Universal и остальные пароли не поменялись. Это плохо.

При запуске перлового скрипта, который заменяет тот же параметр userPassword пароль установился, как simple, так, похоже, и universal. Это странно.

Мак при коннекте по afp может поменять simple пароль, не меняя universal. Это было бы весело, если бы не было так грустно.

Необходимо больше думать.

20080709

Яблоко в Дереве

Имеем: сервер Xserve (PowerPC G4, MacOS X 10.5), и сервер NetWare (OES2) и деревом. 

Задача: подружить второй с первым.

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

  1. Если мы используем SSL, имеет смысл показать OpenLDAP на маке сертификат дерева (SYS:Public/RootCert.der, подробности тут)
  2. Опять же, если мы используем SSL, в настройках в DirectoryUtility на маке нужно в качестве hostname/ip писать то что писалось при установки OES как основной hostname. Мне для того чтобы это работало пришлось прописывать hostname и ip сервера в /etc/hosts.
  3. Мак это UNIX-подобная система, глубоко в душе. Чтобы добавить юзерам gidNumber И uidNumber (для номера юзера и группы соответственно), которые нужны маку, можно приделать к объекту пользователя расширяющий класс (например, posixAccount или специально созданный и внедренный в схему). Не реуомендую модифицировать определение класса юзер напрямую - печально получается, проверено.

Кроме всего этого, нужно еще настроить mapping атрибутов и объектов. Но об этом позже и с прикрепленным файлом.

20080707

К вопросу архивации

Как показывает практика, откопировать кусок Дерева в какой-либо формат можно тьмой способов. Это и экспорт в LDIF (напрямую с помощью утилиты ice или через iManager или еще как нибудь), и такой же экспорт в текстовый файлик, и копирование с помощью embox, и оно же с помощью dsbk (единственный удачный), и, наконец, еще один бакап с помощью nwconfig и опции "prepare for какой-то там upgrape" подменю "Directory Maintaince".

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

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

Команда dsbk действует, на мой взгляд, несколько проще, понятней и безопасней. Написав в консоли netware сервера dsbk help, вы сможете прочитать о возможных с помощью этой команды действиях. Общий принцип состоит в том что метод backup сохраняет все дерево в один файлик, а restore - считывает его из этого файлика. У каждого дейтсвия есть несколько опций: например я, как человек суеверный, при восстановлении указал что надо восстановить все что только можно (кроме юзерских файлов которые в архив не включались) и потом все что можно разблокировать. 

Формат файлов, создаваемых dsbk, весьма интересный. Сверху идет располагающий к себе xml-заголовок, который содержит имя сервера и дерева и предвещает легкий просмотр архива. За ним и до конца файла следует убийственный кусок двоичных данных. Восстановление такого архива прошло успешно, на том же сервере на котором он был выполнен. Восстановление его же на другом сервере, даже с редактированием xml-заголовка, свернуло серверу мозги и заставило его считать себя другим сервером. Не делайте так как сделал я в этом случае.

Копирование в текстовый файл мной не применялось - как то не верится что этот файлик можно потом будет обратно в Дерево запихать, а именно такая задача ставилась и ставится.

LDIF оказался форматом хорошим, до определенной степени. Он позволяет экспортировать кусок дерева в человекочитаемый, человекопонимаемый и человекоизменяемый формат (Ну хорошо, почти.. Какая-то штука для кодирования/раскодирования base64 все таки нужна, но она есть где то в комплекте поставки ConsoleOne, а я сам пользовался perl и соответствующим модулем MIME::base64).  Экспорт осуществляется с помощью яМэнеджер-а, КонсолиОдин (просто и не работает, я вам еще напишу об этих чудесных программах) и консольного средства ice (скудная документация здесь, первый способ по сути является графической оболочкой над ice). В итоге, в моих условиях полуживого дерева (после nwconfig, см. выше), наиболее эффективным оказался вариант использования ice в консоли, а iManager-а в качестве справочного руководства по подготовке командной строки. Файлы в формате LDIF относительно легко вставляются обратно в Дерево (или в другое Дерево) с помощью того же ice.

Два маленьких ньюанса: во первых, с помощью LDIF можно создать пользователю пароль (по крайней мере так пишут Мудрые, сам еще не пробовал), но вот вытащить в него пароль или хотябы его хеш (в целях миграции) нельзя. Во вторых, LDIF можно использовать для модификации схемы (экспортируйте b cn=schema и все увидите), но обойти с использованием этого метода ограничения типа "нельзя удалить объект с флагом неудаляемый" не получается.

Синтаксис LDIF рассмотрен тут.

20080703

Все началось с Дерева

и имя ему было 45.  Выполненное на eDirectory, две реплики, платформа NetWare 6.с хвостиком (ниже 6.5).

Вообще говоря так бы ему и стоять, дереву. Но ничто не вечно: мусор накопился на ветках, всякие ненужные trustee, модификации схемы, Древние Юзеры (не к ночи будут помянуты) - и было принято Высокое Решение Миграции.

Но Решение - Решением, а делать то надо. Как показала практика, Мудрые Романтики (Novell-щики) держат при себе свои сокровенные знания, и постичь тайну Миграции читая нити Повсеместно Протянутой Паутины тяжело. Поэтому здесь, под тенью дерева eDirectory, я намерен записать свои скромные потуги в этом направлении - в помощь и назедание.