При переезде на новый сервер с операционкой версии 10.7 (а была 10.5) стали переносить на него настройки входа в дерево eDirectory. К дереву он подключался, однако авторизовываться в него не давал, при том что пользователей показывал исправно.
Решение нашлось, как известно, в интернете
Нужно открыть файлик /etc/openldap/ldap.conf вашим любимым текстовым редактором (желательно это делать из консоли от root)
Найти там строчку TLS_REQCERT demand
Исправить слово demand на never
В итоге у вас получается TLS_REQCERT never
После этого можно следовать пути, аналогичному для 10.5 - но в настройках DirectoryUtility обязательно нужно указывать галку "Использовать SSL", ибо в 10.7 небезопасная проверка пароля не прокатывает, а для работы безопасной как раз нужна правка файла настроек LDAP.
Не всегда хотят дружить программки от novell для SLES и для NetWare, ой не всегда.
Например, при установке OES2 в существующее дерево где master-репликой является NetWare сервер, не захотели настраиваться AFP и CIFS. Дело в том что настроечные скрипты на Shell, которые Yast запускает при настройке этих сервисов (из /opt/novell/afptcpd/bin/*.sh) не хотят дружить с LDAP-сервером NetWare, и говорят что соединиться с ним не могут. Yast же выдает ошибку "here are no password policies currently defined in eDirectory. To associate policies to users, plase re-configure AFP later using YaST after adding password policies and users to eDirectory.
AFP configuration will continue."
Проблема решается выносом из настройки LDAP адресов NetWare сервера (чтобы скрипты соединялись на SLESовский eDirecroty), либо переписыванием скриптов так чтобы вне зависимости от парметров командной строки подставлялся нужный сервер, либо запуском скриптов руками. Я сделал первое, пока не жалею.
Авторизация маков в дерево работает. Невероятно, но факт. Уже целый месяц.
Выявлены проблемы.
Проблема за нумером 1: Firefox не желает слушать нас. Мы говорим Firefox-у: друг! Сохраняй на рабочий стол который лежит на /Network/Servers/server/share/class/user/Desktop. Firefox говорит "Да да конечно". И пытается сохранять на стол /Users/Guest/Desktop. Но увы! Прав у него нет туда сохранять. И Firefox говорит "Аххаха жалкие людишки! Я не буду сохранять."
Проблема за нумером 2: ACL странно работают через стандартную сборку netatalk на Suse. Finder их не видит, и говорит, в чем-то созвучно Firefox-у: "Аххахаха жалкие людишки! Я не буду показывать вам эту папку - у вас нету прав!!!" Что любопытно и показательно, bash на том же компьютере не умничает, и по командам ls и cat спокойно читает содержимое недоступных для умного Finder-а директорий.
Что странно и страшно, проблема повторяется для SMB, на маке (на Windows все ОК), что пугает к осознанию того что, может быть, Netatalk понимает ACL, а не понимает их Finder.
Неприятно, но директивы perm:0777 и options:upriv не делают того что кажется должны делать. Применен ли патч на perm на версию netatalk собранную для Suse - неизвестно. В списке опций в комментариях AppleVolumes.default она есть, в мане - нету.
Намереваюсь пересобрать netatalk, для этого нужно будет доставить пару библиотек на Suse.
В королевстве туманно.
Ну разьве можно не любить технологии с такими звучными аббривеатурами...
Суть содеянного здесь.
От себя добавлю что
- Не работает замечательная, призванная уменьшить нагрузку на сеть штука под названием 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 вполне нормально с такими юзерами работает... Непонятно, в общем.
TRUSTBAR.NLM - Хоть что то работает как надо, и выдает результаты в приличный формат.
У меня одного ощущение что пароли в eDirectory хранятся несколько неочевидно? Есть пароль который simple. Он хранится в атрибутах sASLogin чего то там, числом два атрибута. Если вручную копировать значения обоих этих атрибутов, пароль копируется. Но: только в пределах одного сервера. Скопировать простой пароль таким способом не удалось. Еще есть пароль который universal. Он покрыт тайной и мраком. Есть политики паролей. В них можно сказать чтобы при установке universal пароля все остальные с ним синхронизировались. Это хорошо. При импорте юзеров из LDIF файла где было прописано поле userPassword установился пароль который simple. Universal и остальные пароли не поменялись. Это плохо. При запуске перлового скрипта, который заменяет тот же параметр userPassword пароль установился, как simple, так, похоже, и universal. Это странно. Мак при коннекте по afp может поменять simple пароль, не меняя universal. Это было бы весело, если бы не было так грустно. Необходимо больше думать.
Имеем: сервер 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 атрибутов и объектов. Но об этом позже и с прикрепленным файлом.
Как показывает практика, откопировать кусок Дерева в какой-либо формат можно тьмой способов. Это и экспорт в 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 рассмотрен тут.
и имя ему было 45. Выполненное на eDirectory, две реплики, платформа NetWare 6.с хвостиком (ниже 6.5). Вообще говоря так бы ему и стоять, дереву. Но ничто не вечно: мусор накопился на ветках, всякие ненужные trustee, модификации схемы, Древние Юзеры (не к ночи будут помянуты) - и было принято Высокое Решение Миграции. Но Решение - Решением, а делать то надо. Как показала практика, Мудрые Романтики (Novell-щики) держат при себе свои сокровенные знания, и постичь тайну Миграции читая нити Повсеместно Протянутой Паутины тяжело. Поэтому здесь, под тенью дерева eDirectory, я намерен записать свои скромные потуги в этом направлении - в помощь и назедание.
|
