Как там с подводными камнями обновления OES11SP1->OES11SP2

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

О, ещё один баг нашёлся - к счастью, некритичный; но настолько очевидный, что странно, как его проморгали тестеры.

При открытии инцидента в саппорте первое, что просят прислать, - это результат работы утилиты supportconfig (собирает по системе её конфигурацию и логи). Так вот, после последних обновлений эта утилита "сломалась": в какой-то момент начинает заполнять экран мильоном сообщений вида

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

find: Symbolic link `/sys/class/drm/controlD64/subsystem' is part of a loop in the directory hierarchy; we have already visited the directory to which it points.
find: Symbolic link `/sys/class/drm/controlD64/device/subsystem/devices/0000:00:00.0/subsystem' is part of a loop in the directory hierarchy; we have already visited the directory to which it points.
find: Symbolic link `/sys/class/drm/controlD64/device/subsystem/devices/0000:00:02.0/firmware_node/subsystem/devices/LNXSYSTM:00/subsystem' is part of a loop in the directory hierarchy; we have already visited the directory to which it points.
find: Symbolic link `/sys/class/drm/controlD64/device/subsystem/devices/0000:00:02.0/firmware_node/subsystem/devices/LNXSYSTM:00/LNXCPU:00/subsystem' is part of a loop in the directory hierarchy; we have already visited the directory to which it points.


Ну ладно, немного преувеличил - не мильон, а только 318 тысяч. Но проблема не в этом, а в том, что в конце концов она так и не дорабатывает до конца: папка вида /var/log/nts_хост_дата_время так и остаётся, во-первых, недозаполненной, во-вторых - нескомпрессированной. Как заметил инженер из техсаппорта,

looks like running "find -L" in /sysfs is not a good idea

К счастью, обходится легко: с помощью опции -x можно исключить отдельные шаги; в данном случае помогает запуск

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

supportconfig -x X

Открыт bug#882047.

[$erg]

Operating Mode(s): MCAST,STATIC-DA сменил на STATIC-DA, NO-ACTIVE-DISCOVERY - результата нет.
Странно что клиенты Windows 7 - без проблем заходят в сеть. А у Windows XP - проблемы.

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

slpinfo /a
SLPSnoop видит по 3 сервера в каждой из веток ndap.novell и bindery.novell

Обновил сервера после апгрейда по самое немогу, т.е. все патчи установлены.

А можно про глупость поподробнее? Ведь в OES2SP3 именно так и было настроено как isDA=true - что изменилось с того времени?
Ну и соответственно в /etc/sysconfig/novell/edir_oes11_sp2 CONFIG_EDIR_SLP_MODE="da" и далее CONFIG_EDIR_SLP_DA="СПИСОК_АДРЕСОВ_СЕРВЕРОВ"
Тогда еще возникает вопрос по настройке клиентов, может тоже что то изменилось?

Одновременно isDA=true и DAAddress=<IP этого же сервера> использовать нельзя. Опция DAAddress может быть использована в случае, если в сети несколько DA, такая конфигурация создается в целях отказоустойчивости. Для сети до 10000 узлов достаточно 1 DA, в отказоустойчивой конфигурации достаточно двух.

Если так уж нужна отказоустойчивость, настраивается система так (предположим, что Сервер1=192.168.0.1, Сервер2=192.168.0.2):

Сервер1:

isDA=True
DAAddress=192.168.0.2

Сервер2:
isDA=True
DAAddress=192.168.0.1

Ну т.е. DA ссылаются друг на друга перекрестно, если на Сервер1 в DAAddress указать его же адрес - начнутся сильно трудно отлавливаемые глюки. Которые, к тому же, еще и нерегулярны.

Для начала рекомендую привести конфиг в соответствии с документацией и рекомендациями

[$erg]

Иван, спасибо за разъяснения.
Вчера плотно поработали с поддержкой и после ночного рестарта ndsd все стало работать как нужно.
Дело было в одном "лишнем" интерфейсе, который пытался обслуживать клиентов, но vlan, на котором он висел был очень сильно "зарезан". В результате клиенты обращались на этот интерфейс но ответ не получали и долго ждали.
А раньше это работало нормально потому, что этот интерфейс был добавлен после инсталяции и настройки сервера и следовательно никто сервисы edir на него не цеплял. А в процессе обновления я на это не обратил внимания(было не до этого).
Иван спасибо за помощь.

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

По предварительным данным, окончательный фикс войдёт в следующий OES Scheduled Maintenance Update (видимо, июльский). Номер бага - 869184.

Вышел August 2014 OES 11 SP2 Scheduled Maintenance Update 9413. В списке исправленных багов - и "мой" 869184 (правда, с каким-то странным описанием: "Filenames that are long and contain Cyrillic characters cannot be deleted from the volume"). По ссылке на багзиллу меня, к сожалению, не пускают. А было бы любопытно глянуть, что же там написано Может, у Иван Левшин aka Ivan L. доступ есть?

Проверил на тестовом кластере - полёт нормальный, все файлы видны, доступны и открываются. Похоже, что, наконец, исправили.

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

Привет, Костя

Что именно интересно? В двух словах - у NSS есть ограничение на длину имени файла (255 символов), удалить файлы ты не мог по причине того, что при декодировании имени файла система натыкалась на сообщение о превышении данного лимита. Собственно, это и пофиксили. Это не проблема NSS Core - скорее "неувязочка" с декодированием символов в имени файлов.

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

Привет, Иван!

Понятно, что проблема при обработке имени файла. Любопытно, как она вообще могла возникнуть - поскольку появилась при переходе на OES11sp2 (на OES11sp1 её не было). Вроде как схема именования файлов при этом не менялась: ограничение про 255 двухбайтовых (!) символов в документации сидит ещё со времён NetWare.

И непонятно, почему так странно описан баг: вроде бы, он не специфичен именно для "Cyrillic characters"; да и конкретно у меня, как я писал, это никак не было связано с удалением файлов. Просто пропадал к ним доступ и всё: по сети не видно вообще, с консоли сервера от root-а видны только имена и не более (примеры я приводил), с файлом вообще ничего сделать нельзя (не только удалить).

Вот и стало интересно, кто же и при каких обстоятельствах ещё на это нарывался, и в чём именно заключалось исправление (которое вышло только теперь).

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

Ну, учитывая, что там доступ тебе закрыт - "всю правду" я рассказать не имею права, прости. Впрочем, криминала там нет - очередной дефект ПО, который поправили. В какой части - ты, думаю, догадываешься Дефект, в любом случае, не оказывающий влияния на хранение собственно данных - проблема с их представлением и обработкой. Там в багрепорте примеры имен файлов от тебя - горазды у вас там, батенька, файлы обзывать

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

К счастью, обходится легко: с помощью опции -x можно исключить отдельные шаги; в данном случае помогает запуск

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

supportconfig -x X

Открыт bug#882047.

Этот баг до сих пор не исправлен (хотя уже три месяца прошло). А, кроме того, неожиданно обнаружил, что предлагаемый workaround не совсем корректен: при включении опции -x заодно включаются несколько дополнительных модулей, которые по умолчанию выключены. Один из них, например, приводит к тому, что в отчёт добавляется полный список вообще всех файлов в системе. В моём случае это привело к незапланированному сканированию всех смонтированных на сервере томов (которых несколько терабайт) и чуть было не отправке конфиденциальной информации (поскольку в имена файлов и директорий пользователи запихивают всё, что угодно).

В общем, правильный workaround - вот такой (отключить только модуль X и то, что итак по умолчанию отключено):

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

supportconfig -x X,SMART,aEDIR,aFSLIST,aLOGS,aMINDISK,aMAXYAST,aRPMV,aSLP

[URRY]

Обнаружился еще один косяк. Само обновление прошло без шума и пыли.В процессе выполнения команды yast2 channel-upgrade-oes
также автоматически устанавливаются новые версии плагинов для iManagera и в частности плагин iPrint Linux Management Plug-in ver . 2.7.6.20150520
Вот с ним как раз проблема и возникла. В управлении менеджера печати выскакивает сообщение Имя хоста сервера iPrint не соответствует сертификату. ( а это действительно так так как iprint у нас кластеризован)
Переходишь к менеджеру сертификатов iPrint, ставишь галочку Разрешить использование имени хоста , жмакаешь ОК. После чего снова заходишь В управлении менеджера печати и получаешь ту же самую ошибку ,и так по кругу до бесконечности.
Лечится установкой плагина версии 2.7.6.20131217.

[URRY]

собственно вот и почти решение.
https://www.novell.com/support/kb/doc.php?id=7016649