Обновление IDM 4.0.1->4.0.2: переустановите операционку :-(

[Константин Ошмян]

Три месяца назад вышла версия Novell Identity Manager 4.0.2. Несмотря на изменение лишь в третьей цифре (на данный момент у нас используется 4.0.1), гладко обновиться не удалось.

У нас IDM используется уже несколько лет, ставился ещё на платформе OES2+SLES10sp1 (сейчас - OES2SP3+SLES10SP4) и последовательно обновлялся "поверх": v3.5 -> v3.6 -> v3.6.1 -> v4.0 -> v4.0.1. Ни разу серьёзных проблем не возникало.

А тут неожиданно выяснилось, что пререквизитом для версии 4.0.2 является наличие eDirectory версии 8.8.7, без неё IDM 4.0.2 не ставится. Установить отдельно (с дистрибутива IDM 4.0.2) эту версию eDirectory не удаётся - получаем сообщение от инсталятора, что у вас, дескать, не просто платформа SLES10, а ещё и OES2, так что пользуйтесь для этого стандартными каналами обновлений. А в каналах обновлений для OES2 версия eDirectory - только 8.8.6 (+какие-то фикспаки, меняющие четвётрую цифру, но не третью). Саппорт ответил, что eDir 8.8.7 для OES2 уже и не планируется (только для OES11, либо для "отдельно стоящих" SLES10/11, не-OES). Для нас это сводится по-любому к полной переустановке операционки, поскольку OES11 существует только для 64-битной платформы, а у нас до сих пор использовалась 32-битная.

Собственно, вопрос: как лучше спланировать переустановку?
Поскольку хотелось бы сохранить как имя, так и IP-адрес сервера, то я склоняюсь к такому варианту:
1) добавить в IDM-овское дерево второй, временный, сервер (исключительно для сохранения данных в дереве). Добавить на этот сервер реплику, сделать её master-ом, с исходного сервера реплику убрать.
2) вывести из дерева исходный сервер, убить его, затем переустановить на поддерживаемой платформе (предполагаю - OES11sp1+SLES11sp2, 64-bit). Вставить его в то же дерево под прежним именем, добавить реплику, сделать эту реплику master-ом.
3) убрать реплику со второго (временного) сервера, вывести тот сервер из дерева и убить.

Неясными при этом остаются такие моменты:
1) надо ли в процессе переустановки зачищать в дереве все объекты, относящиеся к серверу (сам сервер, тома, пулы, сертификаты и т.д.)? Или, наоборот, лучше оставить, чтобы при переустановке использовались те же объекты (тут я не уверен, поскольку никогда так не делал)?
2) Поскольку исходно сервер в своём дереве один, то я смутно помню, что там были какие-то тонкости с объектами, относящимися к безопасности (CA, SDI-ключи и т.п.). К сожалению, не могу сейчас найти TID на эту тему (там расписывалось, что делать, если из дерева удаляется хронологически первый сервер). Не помнит ли кто - достаточно ли будет перед добавлением в дерево переисталированного сервера удалить соответствующие объекты (чтобы они были пересозданы), или же это делается как-то по-другому?

[Dimerson]

inplace вроде бы подерживается sles10/oes2 на sles11+/oes11+ ?
там как я понял легкие пляски с /fstab из-за lvm ... но по шагам все расписано

имхо сделать стендик с дисковой системой как можно ближе и несколько раз потестить разные варианты inplace upgrade.

главное чтоб места было на / достаточно .... ну и suseconfig соответствовал реальному /etc чтоб оно подхватило конфиги ....

[Константин Ошмян]

inplace вроде бы подерживается sles10/oes2 на sles11+/oes11+ ?

Наверное, да - но у нас sles10/oes2 - 32bit. А sles11/oes11 - только 64бит. Т.е. меняется не только версия, но и аппаратная платформа - вот это уже, как я понимаю, не поддерживается. Или ошибаюсь?

Вообще, неподдержка в OES11 32-битных платформ - это ещё та подстава. Многие не шибко нагруженные серверы (тот же IDM, например) прекрасно живут на старом "железе", под их задачи тех ресурсов вполне хватает. Так нет же - железной рукой в светлое будущее, вынь да положь 64 бита...

[Сергей Дубров]

Вообще, неподдержка в OES11 32-битных платформ - это ещё та подстава. Многие не шибко нагруженные серверы (тот же IDM, например) прекрасно живут на старом "железе", под их задачи тех ресурсов вполне хватает. Так нет же - железной рукой в светлое будущее, вынь да положь 64 бита...

У M$ - та же песня: 2008 R2 и новее - только 64 бита. Десктопы ещё будут 32-х разрядные, а сервера - 64 only.

Забавный нюанс - официально рекомендуемая версия MS Office 2010 - 32-х разрядная, у 64-х разрядной сложные, странные и так и непреодолённые проблемы. Сегодня был на презентации Lync2013, SharePoint2013, Exchange2013. Много говорили об Office365 и новом офисе2013, который вот-вот объявят. И снова в силе остаётся та же рекомендация - использовать 32-х разрядную версию нового офиса. Кстати, микрософт в своей Windows 8 теперь не называет интерфейс Metro, это запрещённое словосочетание. Правильно говорить "новый интерфейс Windows" .

[Dimerson]

Звиняйте - про 32-бит у вас был не в курсе (у меня все слес и оес только 64 битные). 32->64 только миграция .... зря они это

[Юрий Арапов]

2) Поскольку исходно сервер в своём дереве один, то я смутно помню, что там были какие-то тонкости с объектами, относящимися к безопасности (CA, SDI-ключи и т.п.). К сожалению, не могу сейчас найти TID на эту тему (там расписывалось, что делать, если из дерева удаляется хронологически первый сервер). Не помнит ли кто - достаточно ли будет перед добавлением в дерево переисталированного сервера удалить соответствующие объекты (чтобы они были пересозданы), или же это делается как-то по-другому?

How do I move the Organizational CA to another server?
This document (3618399) is provided subject to the disclaimer at the end of this document.


все что нашел в закромах родины )))

[Константин Ошмян]

How do I move the Organizational CA to another server?
This document (3618399) is provided subject to the disclaimer at the end of this document.

Видимо оно; Юрий, спасибо большое!
Мне, правда, смутно помнится, что там ещё что-то про проверку SDI чего-то говорилось... Но я могу и ошибаться, давно уже про это читал.

[Константин Ошмян]

Тестовый сервер переехал. Наступил на грабли в нескольких местах, делюсь

Сервер переустанавливал путём добавления в дерево нового временного сервера (для сохранения реплики), переноса на него CA (по ссылке Юрия), убиения исходного сервера, зачистки дерева от "остатков" первоначального сервера, потом чистой установки нового сервера под прежним именем и IP-адресом (SLES11sp2+OES11sp1: eDirectory+iManager), переноса обратно на него реплик и CA, затем выведения из дерева временного сервера и зачистки относящихся к нему объектов. Сразу скажу: это всё прошло на редкость гладко.
А вот уже после этого на свежеустановленный сервер ставился IDM 4.0.2 и RBPM той же версии. После чего через iManager добавили этот сервер к старому Driver Set-у и "попытались взлететь". Блин, не тут-то было.

1. Ни один из драйверов IDM не запустился успешно. Каждый ругался на то, что при обращении к eDirectory не может прочитать жизненно важные для старта атрибуты, и на этом останавливался.
Причина: оказывается, многие атрибуты объектов класса "IDM Driver" и "IDM Driver Set" определены в схеме как имеющие признак "Per Replica" (любопытный материал об этом можно найти на КулСолюшенсах у Джефри Кармана). В результате, они вообще не участвуют в обычной репликации eDirectory - в итоге, все они пропали. Причём так, что обновлённый iManager (который теперь 2.7.5) вообще эти атрибуты не показывал. Т.е. смотришь, например, в стандартном окне Driver Set Overview свойства драйвера (Actions -> Edit Properties), а там в разделе Autentication - всё пусто, а разделов Driver Settings, Subscriber Settings и Publisher Settings вообще нет
Решение: до всех манипуляций с переустановками - обязательно сделать бэкап! В том числе - бэкап конфигурации IDM через импорт проекта в Designer. Тогда потом потерянные атрибуты можно заново от-deploy-ить тем же Designer-ом. А вообще-то правильно всё это делается через тот же Designer, когда старый сервер ещё не удалён из дерева (но тогда на временный сервер тоже надо ставить IDM).

2. Компонент User Application, переустановленный на IBM WebSphere, ни хрена не смог запуститься. Вообще. Выдавая ошибки с жалобами на java.lang.ClassNotFoundException.
Решение: Внимательно почитав документацию, найти в ней новый том, где написано, что процедура настройки Вебсферы слегка изменилась. Это по сравнению с версией 4.0.1!

3. Ура, веб-приложение User Application на ВебСфере наконец-то запустилось. Но только для того, чтобы сообщить:

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

[11/13/12 12:41:16:664 EET] 00000025 webapp        E com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextCreated SRVE0283E: Exception caught while initializing context: {0}
                                 java.lang.RuntimeException: com.sssw.fw.exception.EboDataException: User application driver (UAD) is not compatible with User Application version 4.0.2. Please upgrade your UAD using Designer for Identity Manager.
   at com.sssw.fw.servlet.InitListener.contextInitialized(InitListener.java:111)
   at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1708)
   at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:381)
   at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:299)
   at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
   at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:166)


Притом что Metadirectory Server со всеми его драйверами (включая UA через установку RBPM) был обновлён перед этим.Решение: Ещё раз залезть в найденный том документации и найти там главу "Migrating the User Application Driver". Заодно найти в предыдущей главе, что Role and Resource Service Driver тоже должен быть обновлён, но его рекомендуется обновлять только одним-единственным способом: пересозданием.

В общем, кажись, квест пройден Но ожидалось как-то попроще.
Переходим к следующему уровню: установка патчей, уже на версию 4.0.2