proNovell

Добрый день джентльмены.

Наконец-то в конторе не осталось ни одного Windows < 8.1.
Удачно переехал с SLES11SP4+SMT+SepSesam на OES2018SP2+MF-SMT+SepSesam (пришлось руками мигрировать PostgreSQL базу SepSESAM c 8.3 на 10 версию).
Слава богу GWAVA 6.5 хорошо заменилась на SMG 7.0 Appliance.

Остался у меня последний сервер oes11 sp1 + GroupWise 12.0.2 (остальные OES2015 с сервиспаками и патчами до упора). Дело несколько осложняется тем, что тут живет DDNS-DHCP с раздачей адресов на кучу VLAN'ов.
Не хотелось бы этот сервис не то что просохатить, а останавливать надолго.

Планирую переезд на OES 2018 SP2 + GW 18.0.3 (последние версии если я не ошибаюсь).

Подскажите по процедуре как это сделать поровнее и поглаже ?

если в части переноса dhcp ( что-бы те-жи остались розданными и их сроки..)
то кроме переноса на новый DHCP-server конфиг-файлов еще и базу с розданными из /var/lib/dhcpd перенсти

ну надеюсь обойдусь без переноса.

на стенде конечно отрепетирую сперва.

cперва думаю OES11 SP1->OES11 SP3 . тут не особо важно как. можно и тупо с болванок. а можно и с SMT.

пока непонятки надо ли SLES11 SP4 потом ?

ну а потом OES11SP3 -> OES2018SP2.

перед апдейтом можно залочить под замок наглухо RPM-ки от групвайза чтоб их не вынесло апдейтом.

В результате получим OES2012SP2 + GW2012 SP2. Ну а потом можно и GW на последний (процедура в принципе стандартная - я систему с 5.01 до 2012 обновлял постепенно).

P.S. Danita Zanrè не пришет новых книг по GroupWise 2014 у нее последняя.

P.P.S. в доке на GW2018 не приводится поддерживаемые версии GW в случае External System Syncronization. Их можно где-нибудь узнать ?

это вы про эти шаги ?
http://www.novell.com/documentation/ope ... _2018.html

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

Preparing the Server You Are Upgrading#

Ensure that the server meets the hardware requirements for OES 2018 SP2. See Section 2.2.2, Server Hardware.

Itanium is not a supported platform for OES 2018 SP2.

If the server is running [b]SUPPORTED SOURCE VERSION [/b]( [b]http://www.novell.com/documentation/open-enterprise-server-2018/inst_oes_lx/data/shared_sec_supported-upgrade-paths_2018.html [/b]), complete the following steps before upgrading the server:

    Run YaST > Software > Online Update to patch the OES source server to the latest patch level.

    Ensure that the server and services are still running as desired.

    Upgrade to OES 2018 SP2 using the instructions in this section, then apply all patches and verify services.

5.3.4 Checking the Server’s DNS Name#

Обновление производится стандартно, по документации. Сразу хочу предупредить относительно GW: в новом 18.3 выпилил старый-добрый WebAccess, по умолчанию поставляется GW Web (это то, что в докере). Вы его посмотрите сначала Если будете оставлять GW2012 - лучше его перенести на сторонный SLES11, уже 2014R2 WebAccess не живет принципиально на SLES12SP5 (на котором базируется OES2018SP2).
Миграцию сервисов настоятельно рекомендую производить с помощью miggui - причем лучше сначала потренироваться. Я как-то "смигрировал" DNS/DHCP так, что завод с 8К машин чуть не оставил без DHCP... Было интересно Но, признаюсь, весьма нервно
Вопрос про доку GW 18 и поддерживаемые External System Sync - имеется в виду какие наиболее старые версии GW поддерживаются или что? Давно не занимался этим, но есть ощущение, что через GWIA должно быть вообще по-всеравному...

Cпасибо джентльмены! Буду сперва на стенде обкатывать. Схожу в отпуск и займусь.

Сервисы мигрировать не планирую хочу по месту обновить OES11 SP1->OES11 SP3->OES2018SP2.

Про GW WebAccess -> GW Web читал. Хотя есть TID https://support.microfocus.com/kb/doc.php?id=7023130
И вроде как старый WebAccess можно использовать.

Похоже GW 18.3 сильно отличается от 2012 (может жить без eDir, конфигурируется через WEB морду, лицензия имеется не только бумажная, GW WEB итд итп). Проблема в том что у меня есть несколько внешних систем (там старые GW) и сперва обкатаю как оно поднимется при соединении в режиме MTA<->MTA на 18.3 может придется их ящики сюда переносить.

P.S. Не может не радовать отсутствие зависимости клиента от Windows NT Messaging. Имеется определенное количество программ собранных с GW Object API. Их тоже надо проверять как оно
заработает с клиентом 18.3.

P.P.S. За неимением Даниты читаю другого товарища. https://www.redjuju.com/groupwise-18-3- ... ice-guide/
Интересно пишет. Агитирует за XFS.

Я, конечно, тот еще линуксоед... Но, если честно, стараюсь стороной обходить все эти btrfs и прочие XFS - везде у меня ext4 (там, где я могу на это повлиять). ГВ уже в 2014 версии в едиректори не нуждался - фактически ГВ "вернули к истокам" (в WordPerfect это изначально и было решением для работы с БД, почтовым клиентов оно стало сильно позже).
Старый WebAccess использовать можно, но очень, очень настоятельно рекомендуется про него забыть..
Про лицензию: если у Вас используется тот же Messenger, необходимо иметь в виду, что он, конечно, бесплатен, но работать будет до тех пор, пока жива подписка Maintenance.

Мессенджера нет. Слава богу. В принципе у меня везде ext3/ext4. Только под кеш сквида Reiser. Но в наше время Сквид почти не кеширует если не разбирать SSL/TLS и не подсовывать сертификат свой. Но ACL слава богу работают.

А сам groupwise будет работать и давать админить при про просроченной подписке ?

Надо бы разобраться как оно синхронизирует GW <-> eDir ... раньше C1 со снапинами (а еще раньше NWadmin с плагинами) писала в оба места. Новый еще не трогал от слова совсем.

Dimerson писал(а):Мессенджера нет. Слава богу. В принципе у меня везде ext3/ext4. Только под кеш сквида Reiser. Но в наше время Сквид почти не кеширует если не разбирать SSL/TLS и не подсовывать сертификат свой. Но ACL слава богу работают.

Ну, в общем, да. Я даже представить не могу, как ноне кэширующий прокси может быть полезен...

Dimerson писал(а):А сам groupwise будет работать и давать админить при про просроченной подписке ?

Чего ему не работать, если лицензия-то куплена? Вот ежели была подписка - там да, но там и так все понятно.

Dimerson писал(а):Надо бы разобраться как оно синхронизирует GW <-> eDir ... раньше C1 со снапинами (а еще раньше NWadmin с плагинами) писала в оба места. Новый еще не трогал от слова совсем.

Вообще говоря, ГВ всегда работал именно со своей базой. Оно изначально родилось как Collaboration ("ежедневник бизнесмена") клиент БД, так и жило все время. Просто раньше оно не ставилось совсем, если на сервере eDirectory не было, начиная с 2014 версии все решили "вернуться к истокам". Синхронизируется оно очень просто: eDirectory подключается как LDAP-источник данных о пользователях и группах (это списки рассылки в ГВ), причем там есть LDAP Directory и LDAP Server. Прописывать надо оба, второе - это redundancy для LDAP Directory. Ну и не надо забывать о том, чтобы переключать авторизацию в ПО на LDAP, по умолчанию оно работает как "внутреннее". Нужна будет помощь: пишите либо заводите SR, упадет он все равно на меня

+1 к фразе Ивана про ext4.
https://qna.habr.com/q/110881

и вот интервью с разрабом(не xfs) и обсуждение ниже.
https://habr.com/ru/post/559014/

До отпуска неделя. У меня 2018 сп2 есть в виртуалке. Взгромоздил 18.3..... Какой он насквозь SSL-ный !

Я так понял что он в LDAP ничего не пишет ? При создании можно сказать импорт и выбрать пользователя (лей) и все ?
Не очень удобно что совершенно отдельная точка администрирования. Убиваем пользователя eDir и надо не забыть войти в
администратор Groupwise и убить пользователя там ?

В ldap ходить пользователем common proxy он умеет ?

Пишет в eDir аттрибут e-mail address.

Читает Firstname/Lastname (при изменении в eDir после syncronize меняет в GW).

Есть Associate/Deassociate.

В общем пока потряхивает.

Продолжаем наблюдение.

В целом все работает (на этом маленьком стенде). Даже WEB который в Докере.
Пусто только в Directory Associaton. Хотя оба тестовых юзера ассоциированы и синронизируются по кнопке на раз.

Про Association понятно - он показывает если groupwise username = edir cn. Если != то руками через user->More-Associate.

Ну, вообще говоря, Associate - суть связывание внутреннего пользователя ГВ (из БД) с учеткой в LDAP. Ходить оно умеет тем/кем, чем/кем укажете, настроите учетку CP - от нее и будет ходить, без проблем. В LDAP оно ничего не пишет, кроме поля email - и то если попросить об этом, по умолчанию оно этого не делает. Читает он -да, не все атрибуты, а только те, которые ему нужны.
Еще раз: наблюдаемое поведение не есть нечто новое, ГВ всегда работал именно так. Просто раньше снапин в К1 все делал прозрачно, теперь надо отдельно админить. Лабу с ГВ я, в очередной раз, узлом завязал, не могу посмотреть, можно ли там, как в файлере/вайбе автоматом блокировать/удалять пользователей, которые есть во внутренней базе, но которых нет в LDAP.

Полностью согласен. Ранее снапин / плагин писал в оба места. И отслеживал удаление обоих аккаунтов. Теперь бывает плагин для iManager со странным функционалом - одна кнопка по которой в выбранном ПО создается пользователь с username == cn пользователя eDir. И так как адмн eDir != админ gw он каждый раз просит пароль GW админа.

На предмет осиротевших пользователей можно написать программульку и через REST API дёргать домен GW на предмет орфанед пользователей GW. Но это развлекалово на после переезда.

Вопрос взаимодействия MTA (TCP 7100) старые GW <-> MTA (TCP7100) GW 18.3 пока открыт. Только стенд покажет.

Dimerson писал(а):Вопрос взаимодействия MTA (TCP 7100) старые GW <-> MTA (TCP7100) GW 18.3 пока открыт. Только стенд покажет.

Полагаю, ничего особенно там не поменялось, должно работать.

Dimerson писал(а):
Вопрос взаимодействия MTA (TCP 7100) старые GW <-> MTA (TCP7100) GW 18.3 пока открыт. Только стенд покажет.

В доке к GW2012 была вот такая табличка , к более новым версиям я не видел
https://www.novell.com/documentation/gr ... 12nlj.html