OES 2015: новости, вопросы, впечатления

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

Хоть и с некоторым запозданием, но таки вышел релиз OES-2015. Кто-нибудь уже ставил? Можете поделиться впечатлениями?

Для затравки - то, на что обратил внимание я, читая анонсы и документацию; а также мои первые вопросы.

• Базируется не на уже вышедшем SLES12, а на нынешнем SLES11sp3 (даже не sp4; фокус - на стабильности, а не на новизне). Поэтому название отвязано от версии SLES-а (не OES12, как ожидалось, а OES-2015). К концу года планируется первый саппорт-пак (based on SLES11sp4), в следующем году - второй (и только в нём, скорее всего, будет поддержка SLES12).
• Реализация файловых сервисов в значительной степени переписана, упор - на надёжности (в частности, к существующим 10k test-cases добавлено ещё 8k).
• Одна из новых вещей - поддержка файловой системой NSS пользователей Active Directory; т.е. при доступе по CIFS таким пользователям необязательно будет иметь соответствующий эквивалент в eDirectory (можно назначать права напрямую объектам из "чужого" дерева).
• Другая новая вещь - новая версия NSS, в которой (наконец-то!) для адресации блоков используется 64-битная арифметика. Это снимает нынешнее ограничение на размер тома 8TB (правда, только для новых томов - старые сконвертировать нельзя). Новые тома - до 8-ми эксабайт (около 8 млн. терабайт).
• Третья новая вещь - служба CIFS научится использовать механизм аутентификации Kerberos (до сих пор используется NTLMv2) и протокол SMBv2. Повышение безопасности, надёжности и скорости, снижение "шума" в сети.

Теперь вопросы.

1. Единственный описанный в документации способ апгрейда - это загрузиться с установочного Integrated DVD (SLES11sp3 + OES 2015). А просто добавить другой Add-on Product, когда сервер уже загружен – нельзя, что ли? Или загрузиться по сети с дистрибутива SLES11sp3 (у нас настроены сетевые репозитории и можно через PXE проинсталировать то, что нужно)? Ну, или какие-то ещё варианты - что, обязательно таки качать эти несколько гигов, если у меня уже скачан Add-on DVD OES 2015 (~800 MB)?

2. Для интеграции с AD добавился новый компонент - NSS Active Directory Support (NSS AD). Именно он используется для доступа по CIFS тех пользователей AD, которых нет в eDirectory. Вещь полезная - у нас, например, часть пользователей не имеет новелловского клиента и ходит по CIFS. Несмотря на то, что в CIFS-е настроена аутентификация в домене AD (в OES11 - по NTLM), для них нужны соответствующие пользователи в eDirectory; теперь этого дублирования можно избежать. Однако пока ещё для меня неясно: можно ли перевести с NTLM на Kerberos аутентификацию службы CIFS, не прибегая к установке дополнительных компонентов?

3. В составе упомянутого NSS AD есть такой компонент как Novell Identity Translator (NIT). Используется для хранения соответствия UID-ов (которые он сам генерирует) и логинов (как AD, так и eDirectory). Написано, что для AD можно ничего не генерировать, а брать оттуда готовый атрибут uidNumber (если он каким-то образом заполняется в AD). Но для меня неясно, будет ли этот NIT при генерировании UID-ов что-то прописывать обратно в AD (перезаписывая существующий uidNumber, если он есть), или же он просто сохраняет какую-то таблицу у себя (видимо, в eDirectory, поскольку она должна быть доступна разным серверам)?

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

По поводу SLES11SP3 - да, вопрос ровно в стабильности. И переход на SP4 будет в 2015.1.

По поводу CIFS и интеграции - не совсем так, на самом деле. В OES11SP2 можно было, используя DSfW, интегрировать OES с Windows и давать доступ пользователям eDirectory к файловым ресурсам и принтерам из AD. Обратно было нельзя. Действительно существовали две сущности: учетка в eDirectory и учетка в AD, которые до OES2015 надо было синхрить с помощью IDM.

Теперь внедрили поддержку Kerberos для ресурсов OES - и можно, интегрировав OES c AD, раздавать ресурсы NSS пользюкам AD, не используя IDM. На самом деле отличная штука, позволяющая использовать OES в pure AD environment. Не буду спорить, т.к. до конца пока сам не разобрался - но, насколько я понял, никаких локальных учеток в eDirectory не создается, доступ осуществляется динамически. Права на NSS при этом остаются родными, никаких трансляций в виндовое недоразумение не производится.

По поводу апгрейда - в документации апгрейд с оверлейного диска описан как рекомендованный. При этом доступен апгрейд по сети, в частности - и не только. В доке вроде все написано. Единственное, на что я пока напоролся и что точно не работает - если в OES прописаны каналы обновления (у меня - в локальный SMT), они автоматом удаляются. Если оставить SLES11SP3 канал, как рекомендует документация, вылезают грабли: по неизвестной мне пока причине визард игнорирует все настройки сети, которые уже прописаны, и требует настроить сетевую карту. Я, если честно, при обновлении просто соглашаюсь с полным удалением каналов, потом, уже после обновления, делаю suse_register и провожу обновление с подключенных каналов. Сервер в SMT при этом нормально регистрируется и опознается с этого момента как OES 2015.

В части же новых и вкусных плюшек - ты забыл отметить поддержку SMB v.2. Обещают прирост скорости на файловых операциях до 40% Просто за счет перехода от v.1 к v.2. В 2016 обещают уже v.3

Вопрос по поводу CIFS и установки дополнительных компонентов - не понял. NSS AD Integration устанавливается по умолчанию, о каких еще дополнительных компонентах идет речь?

NIT - не отвечу. Насколько я понял идею NIT (с которой, каюсь, пока до конца так и не знаком), доступ в AD у него RO и менять он там ничего не должен.

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

Иван, спасибо за ответ!

По поводу инсталяции. Добрался до Readme (с которого, видимо, надо было начинать чтение - я начал с Installation Guide-а), там явно написано:

3.1.1 Limited Upgrade Paths to OES 2015
The following methods are supported for an upgrade to OES 2015:

• Using the integrated physical OES 2015 media for an upgrade. For more information, see “Using Physical Media to Upgrade” in the OES 2015: Installation Guide.
• Using AutoYaST for an OES 2015 Upgrade. For more information, see “Using AutoYaST for an OES 2015 Upgrade” in the OES 2015: Installation Guide.

Novell plans to support other upgrade methods in a future OES release.

Второй вариант (с AutoYaST-ом) тоже начинается с того, что нужно загрузиться с того же носителя.
Как-то явно неудобно, ну да ладно.
Хорошо, конечно, что "Novell plans to support...", но плохо, что только "in a future OES release"

Про каналы обновления там в документации упомянуто, что нужно оставить канал SLES11-SP3-Updates (ты про него ведь?), но для меня неясно, зачем удалять и SLES11-SP3-Pool (тем более, что он в конце, после регистрации в NCC или SMT, всё равно добавится заново). А про сетевые настройки - так там тоже упомянуто (ссылка), что при загрузке с этого оверлейного диска нужно сразу, ещё до загрузки инсталятора, прямо в GRUB-овском меню ручками добавить параметры:

netsetup=hostip hostip=<specify the static IP of the OSEServer> netmask=<specify the Subnet Mask IP> gateway=<specify gateway IP> nameserver=<specify the IP of the name server>

Совершенно неочевидная вещь, поэтому даже картинка есть, где это место стрелочкой обозначено. Ты так и делал или пропустил? Если пропустил - то необходимость заново отконфигурировать сетевой интерфейс - это единственная проблема, которая вылезла? А если у меня используется бондинг, то как мне тогда быть?

Про SMB v2 я упомянул (в последнем пункте, вместе с Kerberos-ом).

NSS AD Integration устанавливается по умолчанию

При чтении Installation Guide-а так не выглядит. Действительно ставится по умолчанию при апгрейде?
К тому же, в слюбом случае, это доп. компонент, который должен быть настроен, запущен и т.п.
В Readme (п.1.3) упомянуто:

Increased security: Achieved through using Kerberos for Active Directory

как одна из "фич" SMBv2 и особенность именно службы CIFS. Нужен ли ему для этого NSS AD Integration - пока так и не ясно. Но даже если и нужен, то радует упоминание именно в этом контексте (т.е. должно работать, по-видимому, не только для "pure AD"-пользователей).

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

1. Совершенно не за что
2. Инсталляция - я сам, если честно, не понял, зачем и почему именно так. Но - что имеем. Согласен категорически, что in-plcae update через тот же SMT намного интереснее. Касаемо Add-On CD - полагаю, все дело "в волшебных пузырьках" (с), сиречь в особенностях работы скриптов настройки. Вероятно, они как-то где-то с чем-то несовместны - и ребята решили не заморачиваться. Сроки релиза и так затянули (изначально обещали к июню, потом в конце июля, по факту так вообще получился сентябрь), потому, видимо, решили именно так.
3. По поводу GRUB - каюсь, это я просто не видел. Ну знаешь же, как бывает? "Чего это читать, это и так известно". В результате - вот такой косяк вылез. При этом я не понимаю, почему эта проблема возникает уже после того, как установленный OES уже найден, когда, в общем, вообще не сложно взять и почитать настройки сети-то. Я, к слову сказать, свое "фи" в комментариях к доке написал.
4. Про improved security - тут все, в общем, просто: сам по себе SMB v.2 секурнее v.1, так что оно и для "простых смертных" работает. SMB v.2 там появился не из-за NSS AD Integration. Его изначально планировали к реализации, независимо от NSS AD.
5. NSS AD Integration действительно добавляется автоматом - по крайней мере на моих серверах, где визард нашел NSS, так и произошло (их два). То, что его надо донастраивать - тоже факт, это один из post-task

Больше тебе скажу - при обновлении DSfW-серверов (у меня их тут тоже два) по окончании обязательно надо запустить гуй, там после авторизации запустится post DSfW upgrade (ну или руками пнуть скрипт dsfw_upgrade.pl, о чем, вообще говоря, надо знать - этого, опять же, я в доке не видел. У меня просто колом встал один из серверов из-за кривой настройки и процесс вклинило. Инженер глаза потом мне открыл )

Вообще могу сказать, что если следовать доке - процесс проходит без шуму и пыли. Подчиненный мой, который больше занимается "глубинным бурением" после апдейта сообщил, что как минимум eDirectory или DSfW стали "отзывчивее", по файловым операциям пока ничего не скажу. У меня тут старые NSS тома, новых пока не делали. Что могу сказать точно - помимо описанного никаких особенных граблей не обнаружено, все произошло совершенно буднично. Хотя я и ожидал всяких гнустостей при апдейте файлового сервера

У нас 4 сервера: 2 инфраструктурных (DNS, DHCP, SLP, DSfW - понятно, что eDirectory), 1 -GroupWise (ему, кстати, для NSS рекомендуется NameSpace выставлять UNIX, остальные отключать), 1 - файловый, к которому прицеплено хранилище по iCSCI. Все обновлено за неделю - по одному в день и потом полдня-день под наблюдением. Замечание вылезло только одно - то самое, с каналами обновлений. Но это ерунда, на мой взгляд.

NSS AD Integration не пробовал - доменов AD тут нет, потому и проверять не на чем Городить отдельную городушку для проверки - не вижу смысла. Если я интегрирую вендосервер в DSfW - сам понимаешь, пользюки в любом случае будут браться из eDirectory.

А так - все давно на DSfW+Novell CIFS. Отлично работает уже лет 7, наверное. "У меня" - это я про вуз говорю

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

Добавка

Есть отличное видео, в котором содержится ответ на твой вопрос по поводу CIFS - из него следует, что теперь весь поток управления обрабатывается Novell CIFS. Т.е. и eDirectory, и AD-пользователи обращаются к Novell CIFS (а не как раньше - NCP и CIFS управлялись отдельно и была нужда в CROSS_PROTOCOL_LOCKS - те, кто админил GW под линухом, прекрасно должны помнить матюки в К1 при старте). Другими словами: Novell CIFS дописали, включили туда поддержку Kerberos (полагаю, с помощью как раз SMB v.2) и теперь оно работает вот так. Таким образом, ответ на твой вопрос: для не-AD-пользователей ничего (с их стороны) не поменялось, со стороны сервера поменялось все и появилась, в т.ч., Improved Security.

Ссылка на видео

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

О, ещё раз спасибо.

Ссылка на видео

:-D Забавно, я первые впечатления по материалам именно этого вебинара и писал (в том числе ожидаемые сроки выхода саппорт-паков). Там и вопросов докладчику штук пять - мои

Комментариев к документации не вижу. Возможно, добавят, когда будет что сказать.

По поводу конфигурации с бондингом, видимо, надо будет обращаться в саппорт.

Ладно, читаем доки дальше...

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

NSS AD Integration действительно добавляется автоматом - по крайней мере на моих серверах, где визард нашел NSS, так и произошло (их два). То, что его надо донастраивать - тоже факт, это один из post-task

Странно, нашёл в документации (ссылка) пункт о том, что при апгрейде ставить и конфигурировать NSS AD Support не надо; а оба эти шага следует делать уже потом.

Кстати, на одной из предыдущих страниц этой же доки (ссылка) утверждается, что

Salvage doesn’t currently support the NSS AD integration in OES 2015.

Непонятно, как так, если Salvage - это часть функционала файловой системы NSS, а она, как утверждается, включает "Native CIFS access by Active Directory users". Тоже оставил им свой комментарий (да, он таки пока не отображается).

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

Нда, в NSS AD Deployment and Administration Guide ещё несколько раз повторяется мысль о том, что при апгрейде не надо сразу же устанавливать компонент NSS AD Support, а добавлять его надо уже только после успешного апгрейда отдельным шагом. Например, тут:

Using the instructions in the installation guide, upgrade only one server in your tree at a time.
IMPORTANT:Do not install NSS AD Support as part of the upgrade process.

Ну это ладно, интереснее разобраться с тем, что же такое NIT. Вот тут, например, написано:

NOTE:The UIDs distributed by NIT are server-specific. They are not stored in eDirectory or Active Directory, and they are not visible to Linux services.

Но если они server-specific, да ещё и невидимы линуксовым службам, то я тогда вообще не понимаю, зачем нужны эти UID-ы.
Даже прилагаемая картинка мне как-то не очень помогает:
К тому же говорится, что этот компонент может работать в одном из двух режимов: "Support only eDirectory" либо "Support eDirectory and Active Directory". Однако, ставится он вместе с NSS AD Support; т.е. получается, что для "eDirectory only" он и необязателен. Но тогда вообще неясно, зачем этот NIT нужен.

И ещё: говорится, что для LUM-enabled пользователей eDirectory этот NIT использует LUM-овский UID, иначе - динамически генерирует свой (из сконфигурированного диапазона). А что будет происходить в ситуации, когда какой-либо пользователь, для которого NIT-ом сгенерирован динамический UID, делается после этого LUM-enabled?

В общем, читаю дальше; может, станет понятнее...

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

Костя, для меня этот NIT, равно как NSS AD Integration - звери пока неведомые. Прочесть я это тоже прочел - понимания не особо добавило. Для себя пока понял NIT именно как транслятор (эдакий "недо-IDM"): он генерит свои собственные UID, с помощью которых связывает пару "eDirectory-AD". Как-то так.

В условиях реальной эксплуатации пока ни того, ни другого нет, потому вряд ли чем помогу.

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

Несмотря на то, что в CIFS-е настроена аутентификация в домене AD (в OES11 - по NTLM), для них нужны соответствующие пользователи в eDirectory; теперь этого дублирования можно избежать. Однако пока ещё для меня неясно: можно ли перевести с NTLM на Kerberos аутентификацию службы CIFS, не прибегая к установке дополнительных компонентов?

Похоже, дочитал до ответа на свой вопрос:

IMPORTANT: Domain pass-through authentication is supported for backward compatibility only.
When authentication mode is changed/set to Third party authentication, Clients can connect only with NT LM 0.12 (CIFS/SMB v1) protocol version/dialect. The default "dialect" option configured will automatically change to NT LM 0.12 (SMB v1), and will be updated in the /etc/opt/novell/cifs/cifs.conf file.

Т.е. при использовании "Third-party domain pass-through authentication" (наши текущие настройки) - никаких Kerberos-ов. Видимо, либо через назначенные пользователям eDirectory универсальные пароли, либо через тот самый NSS AD Support. Даже и не знаю, что для нас проще и быстрее сделать (видимо, второе).

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

По твоему замечанию - полагаю, что вряд ли тут будет Kerberos. Я так понял, что NSS AD Support включается при использовании SMB v.2 - хотя это только догадки. Мое мнение - ничего поменяться не должно для тебя в данном случае.

Я вот тут перечитал доку по CIFS и нашел, что у novellcifs теперь есть возможность мониторить как соединения, так и файлы - это может быть решением старой головной боли "ааа, они убрали из NRM возможность отслеживания соединений". Думаю к своей Icinga прикрутить скрипт, который будет мониторить соединения и файлы - вроде бы это можно сделать, но надо будет посмотреть, какова будет нагрузка и на OES, и на Icinga