- Не работает замечательная, призванная уменьшить нагрузку на сеть штука под названием nscd. Это лечится прописью в файлик /etc/nscd.conf слов no напротив каждой записи enable-cache. (Нерабочесть заключается в сообщениях nscd: nds_nss_GetPwdbyName: init sock returned -1. Буду потом разбираться что за сокет такой, и чего это он не работает. Может нужно из под другог юзера запускать ее, а не из-под nobody.)
- Мешает отладке наличие директивы enable-persistent-cache=no в конфиге /etc/nam.conf
- К глубочайшему сожалению, NAM почему то не вытаскивает из директории юзеров с именами по 4 и менее буков. Учитывая, что SUSE вполне нормально с такими юзерами работает... Непонятно, в общем.
20080730
PAM, LUM и прочие NAMы
20080722
Архивирование trustee
20080718
Горелые яблоки
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) и деревом.
Задача: подружить второй с первым.
По этой теме по нитям Повсеместрно Протянутой Паутины можно многое прочитать, но у меня получилось не с первого раза (если честно, до конца пока вообще не получилось, но свет виден). Хотелось бы заострить внимание на нескольких неочевидных вещах:
- Если мы используем SSL, имеет смысл показать OpenLDAP на маке сертификат дерева (SYS:Public/RootCert.der, подробности тут)
- Опять же, если мы используем SSL, в настройках в DirectoryUtility на маке нужно в качестве hostname/ip писать то что писалось при установки OES как основной hostname. Мне для того чтобы это работало пришлось прописывать hostname и ip сервера в /etc/hosts.
- Мак это 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, я намерен записать свои скромные потуги в этом направлении - в помощь и назедание.