Pre Migrated сервер в боевом дереве. Проблемы.

[Dimerson]

Добрый день All !

В дервере появился PreMigrated сервер OES2015 SP1 (со всеми патчами). Данная версия выбрана для гладкого пререноса iPrint с NW65 sp8 (трудящегося в XEN).
Сервер безболезненно прижился в дереве.

Был один нюанс - у LUM не установился Common Server Certificate но после перенастройки LUM и rcnscd restart 'id admin' отрабатывает нормально.
Из продуктов выбран обычный набор: PreMigrated Server (без реплики для последующего TRANSFER ID), iManager, iPrint.

yast2 oes-ldap показывает три записи:
этот Premigrated Server по IP,
этот Premigrated Server по DNS,
и сервер содержащий r/w реплику по IP.

На самом Pre Migrated ldapsearch

/opt/novell/eDirectory/bin/ldapsearch -x -h <PreMigratedIp> -p 636 -D cn=admin,o=TPSB -w PASSWD -e /etc/opt/novell/certs/SSCert.der "cn=admin" cn

нормально отдает админа

-----------------------------------
version: 1

#
# filter: cn=admin
# requesting: cn
#

# Admin,TPSB
dn: cn=Admin,o=TPSB
cn: Admin
cn:: w4DDpMOsw6jDrcOow7HDssOww6DDssOuw7A=

# admin,Tomcat-Roles,TPSB
dn: cn=admin,ou=Tomcat-Roles,o=TPSB
cn: admin

# search result
# search: 2
# result: 0 Success

# numResponses: 3
# numEntries: 2
-----------------------------------

Проблема появляется при создании на PreMigrated сервере iPrint Driver Store (чтобы потом создать iPrint Manager, потом миграция принтеров и в конце TRANSFER ID).
При создании возникает ошибка

Ошибка: Ошибка Создание хранилища драйверов

Authorization Required
IPP Error: 0xF0191
HTTP Error: 401

Соответственно в error_log апача имеем:

[Mon Nov 21 14:49:02 2022] [error] [client 192.168.100.183] user cn=Admin,o=TPSB not found: /ipps
[Mon Nov 21 14:49:02 2022] [error] [client 192.168.100.183] no acceptable variant: /usr/share/apache2/error/HTTP_UNAUTHORIZED.html.var
[Mon Nov 21 14:49:03 2022] [error] [client 192.168.100.183] user Admin not found: /ipps
[Mon Nov 21 14:49:03 2022] [error] [client 192.168.100.183] no acceptable variant: /usr/share/apache2/error/HTTP_UNAUTHORIZED.html.var


В общем не получается логин по https Apache->LDAP в /ipps

конфиг ипринта стандартный:

# Do not modify this file! Changes to this file may
# cause iPrint to opperate improperly. Your changes to this
# file will not be preserved.

<IfModule !mod_ipp.c>
LoadModule ipp_module /opt/novell/iprint/httpd/lib64/mod_ipp.so
</IfModule>

<IfModule mod_ipp.c>
<LocationMatch ^/(ipps|idss|[Pp][Ss][Mm][Ss][Tt][Aa][Tt][Uu][Ss])($|/)>
SSLRequireSSL
Require valid-user
Order deny,allow
Allow from all
AuthType Basic
AuthBasicProvider ldapdn
AuthName "TPSB"
AuthLDAPDNURL "ldaps://<premigrate-server-fdn>:636/o=tpsb???(objectClass=user)"
AuthLDAPDNRemoteUserIsDN on
AuthzLDAPDNAuthoritative Off
AuthLDAPDNAllowDNAuth on
</LocationMatch>
</IfModule>

Подскажите что поковырять ? Пока я в непонятках.

Все время забываю что для нормального лога LDAP в dstrace надо добавить галок в трейсе LDAP сервера.
Вот что показывает DSTRACE -ALL +LDAP с включенным трейсом в LDAP:

=======================================================
15:19:08 EB6C4700 LDAP: (192.168.100.183:42228)(0x0005:0x77) DoExtended on connection 0x125bea80
15:19:08 EB6C4700 LDAP: (192.168.100.183:42228)(0x0005:0x77) DoExtended: Extension Request OID: 2.16.840.1.113719.1.27.100.101
15:19:08 EB6C4700 LDAP: (192.168.100.183:42228)(0x0005:0x77) Sending operation result 0:"":"" to connection 0x125bea80
15:19:08 E6CB0700 LDAP: (192.168.100.183:42228)(0x0006:0x63) DoSearch on connection 0x125bea80
15:19:08 E6CB0700 LDAP: (192.168.100.183:42228)(0x0006:0x63) Search request:
base: "cn=admin,o=tpsb"
scope:0 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=user)"
no attributes
15:19:08 E6CB0700 LDAP: (192.168.100.183:42228)(0x0006:0x63) Empty attribute list implies all user attributes
15:19:08 E6CB0700 LDAP: (192.168.100.183:42228)(0x0006:0x63) Sending operation result 0:"":"" to connection 0x125bea80
15:19:08 E68AC700 LDAP: (192.168.100.183:42228)(0x0007:0x63) DoSearch on connection 0x125bea80
15:19:08 E68AC700 LDAP: (192.168.100.183:42228)(0x0007:0x63) Search request:
base: "o=tpsb"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(objectClass=user)(uid=cn=admin,o=tpsb))"
no attributes
15:19:08 E68AC700 LDAP: (192.168.100.183:42228)(0x0007:0x63) Empty attribute list implies all user attributes
15:19:08 E68AC700 LDAP: (192.168.100.183:42228)(0x0007:0x63) Sending operation result 0:"":"" to connection 0x125bea80
=======================================================

Может каких аттрибутов не хватает в дереве (дерево создавалось на NW 4.02 как бы) ?
Есть в виртуалке стенд прошедший transfer id и нормально работающий. Надо глянуть там dstrace -all +ldap.


В виртуалке с рабоающим логином в /ipps :
=======================================================
15:31:19 FDEC700 LDAP: New TLS connection 0x1236d180 from 192.168.27.224:59430, monitor = 0xf88c7700, index = 8
15:31:19 F88C7700 LDAP: Monitor 0xf88c7700 initiating TLS handshake on connection 0x1236d180
15:31:19 F81C0700 LDAP: (192.168.27.224:59430)(0x0000:0x00) DoTLSHandshake on connection 0x1236d180
15:31:19 F81C0700 LDAP: BIO ctrl called with unknown cmd 7
15:31:19 F81C0700 LDAP: (192.168.27.224:59430)(0x0000:0x00) Completed TLS handshake on connection 0x1236d180
15:31:19 F83C2700 LDAP: (192.168.27.224:59430)(0x0001:0x60) DoBind on connection 0x1236d180
15:31:19 F83C2700 LDAP: (192.168.27.224:59430)(0x0001:0x60) Treating simple bind with empty DN and no password as anonymous
15:31:19 F83C2700 LDAP: (192.168.27.224:59430)(0x0001:0x60) Bind name:NULL, version:3, authentication:simple
15:31:19 F83C2700 LDAP: (192.168.27.224:59430)(0x0001:0x60) Sending operation result 0:"":"" to connection 0x1236d180
15:31:19 F6CFD700 LDAP: (192.168.27.224:59430)(0x0002:0x77) DoExtended on connection 0x1236d180
15:31:19 F6CFD700 LDAP: (192.168.27.224:59430)(0x0002:0x77) DoExtended: Extension Request OID: 2.16.840.1.113719.1.27.100.101
15:31:19 F6CFD700 LDAP: (192.168.27.224:59430)(0x0002:0x77) Sending operation result 0:"":"" to connection 0x1236d180
15:31:19 F7CBB700 LDAP: (192.168.27.224:59430)(0x0003:0x63) DoSearch on connection 0x1236d180
15:31:19 F7CBB700 LDAP: (192.168.27.224:59430)(0x0003:0x63) Search request:
base: "cn=admin,o=test"
scope:0 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectClass=user)"
no attributes
15:31:19 F7CBB700 LDAP: (192.168.27.224:59430)(0x0003:0x63) Empty attribute list implies all user attributes
15:31:19 F7CBB700 LDAP: (192.168.27.224:59430)(0x0003:0x63) Sending search result entry "cn=admin,o=TEST" to connection 0x1236d180
15:31:19 F7CBB700 LDAP: (192.168.27.224:59430)(0x0003:0x63) Sending operation result 0:"":"" to connection 0x1236d180
15:31:19 F82C1700 LDAP: (192.168.27.224:59430)(0x0004:0x60) DoBind on connection 0x1236d180
15:31:19 F82C1700 LDAP: (192.168.27.224:59430)(0x0004:0x60) Bind name:cn=admin,o=TEST, version:3, authentication:simple
15:31:19 F82C1700 LDAP: (192.168.27.224:59430)(0x0004:0x60) Sending operation result 0:"":"" to connection 0x1236d180
=======================================================

Есть у меня подозрение на дублирование cn аттрибута:

cn: Admin
cn:: w4DDpMOsw6jDrcOow7HDssOww6DDssOuw7A=

Мусорный CN это BASE64->CP866 : ├А├д├м├и├н├и├▒├▓├░├а├▓├о├░

Однако года с 1994 никому не мешало

Увы дело не в CN.

придется отладку апача в максимум и изучать логи.

[skoltogyan]

а по такой ссылки удается зайти и залогинится ?
https://вашсерверIPP/PsmStatus
может шото там увидится

[Dimerson]

Там еще ничего нет. Пока не удается создать drviver store.

[skoltogyan]

микрофокус такое древнее
https://community.microfocus.com/img/ip ... ore-errors
там рекомендуют

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

In /etc/opt/novell/iprint/httpd/conf/iprint_ssl.conf we added the following lines just below the AuthName line:
AuthName "your tree name"
AuthLDAPBindDN cn=username,o=novell
AuthLDAPBindPassword userpassword
The user used in the AuthLDAPBindDN needs to have browse privileges and read rights on the uniqueID attribute of user objects in your tree.

если не откроется ссылка, маякни и скопипастю

[Иван Левшин aka Ivan L.]

Зачем OES2015SP1, когда OES2018SP2 в описании к Migration Tool прямо указывается: Netware 6.5 является "легитимным" источником. SP3 - тоже поддерживает, вот 2023 - там уже не ниже OES2015SP1.

Лог LDAP посмотрел: различия пока вижу только в том, что на проблемном нашли админа и потом идет Search, а на "живом" - Bind (логин). Вангую, это разные фазы одного и того же процесса, сравнивать надо одно и то же. Тут и там, и там возвращается код 0 - т.е. операция завершена успешно, так что лог малоинформативен. Это просто похожие куски, сомневаюсь, что это - одно и то же место одного и того же процесса...
Ну и ТИД Сергея - немного не о том, но суть верная, добавка такая не повредит - и должна помочь.

Я к сожалению, уже не помню, как перевозил NW6.5 на OES11 - точнее, помню, что miggui перевез полторы тыщи принтеров без проблем вообще Потому все вот это помнится прям смутно...

[Dimerson]

микрофокус такое древнее
https://community.microfocus.com/img/ip ... ore-errors
там рекомендуют

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

In /etc/opt/novell/iprint/httpd/conf/iprint_ssl.conf we added the following lines just below the AuthName line:
AuthName "your tree name"
AuthLDAPBindDN cn=username,o=novell
AuthLDAPBindPassword userpassword
The user used in the AuthLDAPBindDN needs to have browse privileges and read rights on the uniqueID attribute of user objects in your tree.

если не откроется ссылка, маякни и скопипастю

Скорее всего оно. Смутно припоминаю что анонимус серч выключен. Вроде бы когдато у [public] права убирали.
Похоже common proxy сюда прикрутить сложно ибо его пароль меняется асинхронно.
И наверное не у всех юзеров есть аттрибут uniqueid. Ибо создавались еще в nwadmin. Но разбираться будем после.
Опять же всегда декларировалось что в nds можно тот же юзернейм в разных ou. Точно знаю что такие есть. Что тогда в uniqueid прописывать ?

[Dimerson]

Зачем OES2015SP1, когда OES2018SP2 в описании к Migration Tool прямо указывается: Netware 6.5 является "легитимным" источником. SP3 - тоже поддерживает, вот 2023 - там уже не ниже OES2015SP1.

Лог LDAP посмотрел: различия пока вижу только в том, что на проблемном нашли админа и потом идет Search, а на "живом" - Bind (логин). Вангую, это разные фазы одного и того же процесса, сравнивать надо одно и то же. Тут и там, и там возвращается код 0 - т.е. операция завершена успешно, так что лог малоинформативен. Это просто похожие куски, сомневаюсь, что это - одно и то же место одного и того же процесса...
Ну и ТИД Сергея - немного не о том, но суть верная, добавка такая не повредит - и должна помочь.

Я к сожалению, уже не помню, как перевозил NW6.5 на OES11 - точнее, помню, что miggui перевез полторы тыщи принтеров без проблем вообще Потому все вот это помнится прям смутно...

Разница есть - на стенде пролетает Treating simple bind with empty DN and no password as anonymous. На продакшене нет.

На стенде miggui 2018 с сп и без сп мне ругался на nw65sp8 что это неизвестный источник. А miggui 2015 sp1 делал нормально.

[Dimerson]

Вообще странно. Во многих сервисах (начиная от LUM) используется CommonProxy_server. Почему его тут не прикрутили ?

По делу:

На параметры приведенные в TID для NW5.1 ругается так:
Invalid command 'AuthLDAPBindDN', perhaps misspelled or defined by a module not included in the server configuration

При этом:

strings /usr/lib64/apache2/mod_authnz_ldap.so | grep AuthLDAP
AuthLDAPURL
AuthLDAPBindDN
AuthLDAPBindPassword
AuthLDAPBindAuthoritative
AuthLDAPRemoteUserIsDN
AuthLDAPRemoteUserAttribute
AuthLDAPCompareDNOnServer
AuthLDAPGroupAttribute
AuthLDAPGroupAttributeIsDN
AuthLDAPDereferenceAliases
AuthLDAPCharsetConfig
Unrecognized value for AuthLDAPDereferenceAliases directive
Too many AuthLDAPGroupAttribute directives
Invalid AuthLDAPBindPassword exec location:

Но:
strings /opt/novell/iprint/httpd/lib64/mod_authnz_ldapdn.so | grep AuthLDAP
AuthLDAPDNURL
AuthLDAPDNBindDN
AuthLDAPDNBindPassword
AuthLDAPDNRemoteUserIsDN
AuthLDAPDNRemoteUserAttribute
AuthLDAPDNCompareDNOnServer
AuthLDAPDNGroupAttribute
AuthLDAPDNGroupAttributeIsDN
AuthLDAPDNDereferenceAliases
AuthLDAPDNCharsetConfig
AuthLDAPDNAllowDNAuth
Unrecognized value for AuthLDAPDNAliasDereference directive
Too many AuthLDAPDNGroupAttribute directives

заработало в варианте (по крайней мере https://premigrate-fdn/ipps логин админом проходит):
AuthName "TREENAME"
AuthLDAPDNBindDN "cn=staticproxyuser,ou=context"
AuthLDAPDNBindPassword "SomeStaticProxyPassword"

Налицо небольшой недокументированный нестандарт (по крайней мере Великий Гугл не знает "AuthLDAPDNBindDN"). Тем не менее большое спасибо за подсказку какое место допиливать рашпилем.

Продолжаем измывательства над зверушкой. Надоть создавать обьекты iPrint мигрировать принтера и с ужасом думать не заглючит ли TRANSFER ID.

Ура.

DriverStore.TPSB загружен на сервере с адресом 192.168.100.zzz
PrintManager.TPSB загружен на сервере с адресом 192.168.100.zzz

Так как старый ипринт не знает новых Windows, драйверы мигрироваться не будут. В плане релакса залил в IDS драйверы для 20-ти куосер и 2-х OKI. Все пока работает (без TRANSFER ID)

По ldap аттрибуту uid , как и ожидалось у СТАРЫХ пользователей его нет. У новых он есть и == CN . Возможны дубли. Но как бы у меня принтеры: a) без SSL б) не требующие авторизации.

Возможно наличие данного аттрибута не важно в этом случае.

[Иван Левшин aka Ivan L.]

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

Treating simple bind with empty DN and no password as anonymous

- это, внезапно, анонимус и есть Вы пытаетесь подключиться анонимно в источник?
Пустой uid - почти 100% вероятность того, что пользователь заведен был в nwadmin. Правится - просто, надо пробежаться по пользунам и для тех, у кого оно пусто, вколотить значение cn. В iPrint оно будет иметь значение, если использовать защищенную печать и Walk-Up, в Вашем случае, думаю, оно и не важно.
Поздравляю с миграцией

[Dimerson]

Иван, спасибо конечно, но я пока только добился работоспособности iPrint на PrMigrated сервере (залил драйверы, создал тестовый принтер, поустанавливал его в 1 клик с http://premigrated\ipp, далее миграция нескольких принтеров в тот же контекст - старые принтеры на старом сервере продолжат работать как http://old-server/Printername, переименуются комплементарные им обьекты NDS, на новом серврер появятся http://premigrated/Printername. Если все ок - мигрирую все оставшиеся принтеры. При этом печать продолжает работать. Ну а потом Transfer ID. Если все ок удаляем все старые переименованные обьекты принтеров в NDS. Даже скрипт под это есть. Ежели трансфер ID глюканет то просто поднимаем старый сервер. )

Про uid понятно.

Про анонимуса. Я не вхожу анонимусом при миграции. Это iPrint ипользует анонимный бинд при проверке паролей (в тч и при создании ids и ipsm через iManager):

cat /etc/opt/novell/iprint/httpd/conf/iprint_ssl.conf

# Do not modify this file! Changes to this file may
# cause iPrint to opperate improperly. Your changes to this
# file will not be preserved.

<IfModule !mod_ipp.c>
LoadModule ipp_module /opt/novell/iprint/httpd/lib64/mod_ipp.so
</IfModule>

<IfModule mod_ipp.c>
<LocationMatch ^/(ipps|idss|[Pp][Ss][Mm][Ss][Tt][Aa][Tt][Uu][Ss])($|/)>
SSLRequireSSL
Require valid-user
Order deny,allow
Allow from all
AuthType Basic
AuthBasicProvider ldapdn
AuthName "TREE"
AuthLDAPDNURL "ldaps://premigrated-server:636/o=tpsb???(objectClass=user)"
AuthLDAPDNRemoteUserIsDN on
AuthzLDAPDNAuthoritative Off
AuthLDAPDNAllowDNAuth on
</LocationMatch>
</IfModule>

Так как права у [Public] отобраны много лет назад анонимный бинд тупо идет лесом.

Добавил недокоментированные параметры для бинда статическим прокси пользователем:
AuthLDAPDNBindDN "cn=static-proxy,o=context"
AuthLDAPDNBindPassword "SomePasswordHere"

Тут напрашивается CommonProxy ... но не прикрутили. Опять же .... зачем uid ? Разве нелья по dn авторизовать ? Так весь смысл NDS теряется - требуется уникальность cn по всем ou.
Помню что в 1994г в момент развертывания NW4 громко декларировалась возможность одинаковых cn= в разных ou= как преимущество перед bindery

[Иван Левшин aka Ivan L.]

Хороший, на самом деле, вопрос про dn и uid. Я, если честно, даже не задумывался раньше по этому поводу.
Аутентификация в дереве посредством LDAP всегда производилась по uid, сколько я помню. Справедливое замечание относительно dn: любой атрибут использовать же можно, на самом деле. Но всегда и везде используется uid.
Относительно "почему так все сделано" - нет у меня комментариев. Реальность, данная нам в ощущениях...

[Dimerson]

Вторым подходом (первый не удался так как у [Public] не было прав на просмотр дерева и к тому же следом прицельно были добавлены права на чтение аттрибута Version прав на который все равно не хватало и migedir -s NW_IP_ADDRESS не получал платформу соурс сервера NW или OES и рубился по этому ) таки TRansfer ID прошел без замечаний.