Подводные камни при обновлении на R80.20

[Andrey_Chernyak]

Коллеги, поделитесь опытом по обновлению на R80.20. Планирую начать обновление с SmartManagement(R80.10) и SmartEvent(R80.10), используя Clean Install и migration tools. Конечная цель - перевести всю инфраструктуру CheckPoint на R80.20(сейчас ещё есть два кластера и песочница на R77.30), ибо очень нужен функционал клиента ICAP на шлюзах, который появился без дополнительных хотфиксов в R80.20.

Есть пара моментов, которые хотелось бы уточнить здесь после тестов по обновлению на тестовой виртуальной среде. 

1. В случае upgrade  через Clean Install и migrate import пропадают пользователи clish, приходится переносить строчки из конфига ручками, касающиеся юзеров Clish. Есть ли еще какие-то куски конфигурации, которые приодеться переносить руками при сценарии обновления через Clean Install?

2. Какой правильный порядок действий по переносу логов? Логи в моем инсталле поступают со шлюзов на SmartManagement, а SmartEvent используется как SmartEvent Server и SmartEvent Correlation Unit. Как перенести базу для SmartEvent более менее понятно, есть sk110173. А вот как не потерять логи на SmartManagement?

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

Напрмер, одним из них при обновлении шлюзов будет необходимость переконфигурации Identity Collector(у кого они есть), там нужно будет снять галочку "Pre R80.10 gateway" после upgrade шлюзов с R77.30 на R80.20.

[Valeriy_Denisov]

Ответы из чата:

Леонид Орлов:

Приходилось апгрейдить MDS, не менеджмент-сервер. Если не ошибаюсь, Migration tools собирает полностью только базу данных объектов и правил (то, что вы видите в SmartConsole). Но не собирает установленные хотфиксы и конфиг CLISH. Это можно вытащить с помощью команды clish "save configuration [filename]", и потом загрузить на новой машине командой "load configuration [filename]"

Леонид Орлов

Хотфиксы то и не нужны, ибо они разные под R80.10 и R80.20(и нет хотфиксов отличных от Jumbo). А за идею с "load configuration [filename]" - отличная идея, спасибо, проверю насколько корректно работает.

Леонид Орлов:

могут быть слегка косяки с загрузкой конфига. Например, недавно у меня было. Когда делаешь save configuration, он же как в циске - просто выгружает команды конфига списком. И эти команды при load configuration - то же самое, что руками будешь вбивать. Вот только проблема может быть, если у тебя RADIUS настроен, и если там в команде был использован пароль. Потому что выгружается тогда команда со звездочками, и потом эту же команду load configuration ввести не может, потому что это уже звездочки, а не пароль 🙂

но load configuration покажет, на какой команде зафэйлился

Илья

> логи со смартменеджемента можно выгрузить флагом -l при выполнении migrate export

[AlekseiShelepov]

Тут вышло видео с рассказом о новом ядре и утилитах ОС: Introduction to GAiA 3.10 - YouTube 

И в конце него есть интересный момент. Если просто обновиться с R80.10 на R80.20, то не будет новой файловой системы и таблицы разделов, это было и так понятно. Но далее говорится, что можно снять "бэкап" и сделать clean install. Не уверен, говорили ли они про именно backup или всё-таки про migrate_export. Но ведь действительно, должно получиться, если сначала просто обновить с R80.10 на R80.20, сделать backup, затем clean install и восстановить из бэкапа. Из плюсов будет то, что настройки интерфейсов, маршрутизации и прочее должны остаться, как и политики с сервера управления. Сам я этого не пробовал, но, возможно, в некоторых случаях пригодится.

Ну и ещё, кроме логов, могут пригодиться Hit Count - How can I export policy including hit count? 

Также стоит проверять есть ли файл fwkern.conf и что в нём.

Если у вас есть VSX, то по умолчанию в R80.10 они были 32-битными. В R80.20 по умолчанию уже должны идти 64-битные. Можно это заранее проверить или вручную поменять.

[Andrey_Chernyak]

Сделал Clean Install через CPUSE на сервере управления, ядро естественно обновилось до 3.10, а вот partition table по прежнему msdos и файловая систему у / и /var/log осталась ext3.

Работы, кстати, прошли не успешно, не прошел migrate import на R80.20. Со слов поддержки, так вышло из-за того, что часть правил были в статусе locked(пользователи меняли правила, но при этом не выполнили ни Discard ни Publish), дали скрипт который чистит блокировки по этим правилам. С моей точки зрения, это немножко странно, ошибка по хорошему в таком случае должна была вылезти во время migrate export ещё. И ещё я теперь раздумываю над тем, чтобы с флешкой дойти до appliance с менеджментом, чтобы сделать самый честный clean install.

[Fedor_Agafonov1]

В последней версии migration tool, при экспорте проводит проверку на Discard и Publish.  У меня одна сессия подвисла и через SmartConsol не удавалось опубликовать или изменить. Помогли вот эти команды:

Просмотр сэссий:

#psql_client cpm postgres -c "select applicationname,objid,creator,state,numberoflocks,numberofoperations,creationtime,lastmodifytime from worksession where state = 'OPEN' and (numberoflocks != '0' or numberofoperations != '0');"

отмена изменений:

# mgmt_cli discard --port 443 uid 4b2ac7a8-9b0b-4e39-a3f0-4c065d631cdf
Username: admin
Password:
number-of-discarded-changes: 2
message: "OK"

clear disconnected sessions?