Общая информация

В составе Astra Linux Special Edition РУСБ.10015-01 1.7 с установленным актуальным оперативным обновлением доступен инструмент astra-full-upgrade для автоматической миграции (далее — миграция) на следующее очередное обновление — 1.8. Миграция на новую ОС позволяет сохранить стандартные домашние каталоги пользователей (каталог /home), а также установленное прикладное ПО (см. 7.2).

Условия для выполнения миграции

• миграция на очередное обновление ОС (новая ОС) возможна с очередного обновления 1.7 (старая ОС) с установленным актуальным оперативным обновлением;
• если в текущем очередном обновлении ОС для файловой системы включен режим «только чтение» (overlay), то миграция невозможна;
• миграция на новую ОС позволяет сохранить стандартные домашние каталоги пользователей (каталог /home), а также установленное прикладное ПО (см. 7.2);
• для успешного выполнения миграции требуется наличие неразмеченного свободного непрерывного дискового пространства, рекомендуемый размер которого не менее 60 ГБ:
  • при загрузке в режиме BIOS свободное пространство должно быть выделено на основном диске;
  • при загрузке в режиме EFI в случае отсутствия свободного места на основном диске может использоваться подключенный дополнительный диск.
  • рекомендуемая конфигурация диска для успешной миграции:

• таблица дисковых разделов в формате GPT;
• дисковый раздел /boot объемом не менее 1 ГБ;
• группа томов LVM с файловой системой ext4, включающая:
  • дисковый раздел объемом не менее 60 ГБ с корневой файловой системой;
  • дисковый раздел с каталогом /home (домашние каталоги пользователей);
  • прочие разделы, при необходимости, например /tmp, /var/tmp и др.

• необязательный дисковый раздел для области подкачки (swap) (если используется);

• не размеченное пространство, которое может располагаться как внутри группы томов LVM, так и за ее пределами.

Настройка инструмента осуществляется редактированием конфигурационного файла /usr/lib/python3/dist-packages/astra_upgrade/configs/upgrade.conf.yaml.

Если свободное пространство не входит в состав LVM, или LVM вообще не используется, то при миграции в свободном пространстве будет создана новая группа томов LVM. При миграции на очередное обновление все имеющиеся дисковые разделы старой ОС, кроме /home, /boot и swap, будут созданы заново в не размеченном свободном пространстве. Если до миграции использовалось защитное преобразование дисковых разделов, то новые разделы будут заменены на не преобразованные. Разделы со старой ОС после миграции останутся на диске в неизменном виде и могут быть впоследствии использованы для отката выполненной миграции или для размещения информации при миграции на следующее очередное обновление. Синтаксис вызова инструмента миграции:
astra-full-upgrade [параметр]

Описание параметров инструмента:

Параметр Описаниеs

status

Отобразить текущий статус обновления и выйти. Возможные статусы:

error — при проверке возникли ошибки

ready-for-download — проверки пройдены, система готова к загрузке пакетов;

-wait-for-download — загрузка пакетов начнется по истечении случайно выбранной задержки от 0 до указанной в поле max_delay конфигурационного файла;

-downloading — производится загрузка пакетов;

-ready — готовность к обновлению (пакеты загружены);

-activated — обновление произойдет при перезагрузке (киоск активирован);

-forced — принудительное обновление при перезагрузке (без возможности отката)

c,check Проверить систему на соответствие требованиям для выполнения обновления с формированием отчета

e,enable Проверить систему на соответствие требованиям и начать подготовку к обновлению

d,disable,full-revert Остановить процесс обновления и отменить изменения

f,forceПринудительно запустить обновление при отсутствии ошибок в отчете

edit Открыть конфигурационный файл для редактированияset

<статус> Принудительно установить один из следующих статусов:

-ready-for-download — вернуться на этап готовности к загрузке пакетов;

-activated— перейти на этап запуска обновления после перезагрузки;

-ready— вернуться с этапа activated на этап готовности к обновлению

-h,–help Вывести справку и выйти

Для дополнительного управления процессом обновления в старой ОС могут быть добавлены переменные окружения.

Выполнение действий на этапах миграции производится в следующей последовательности:

1) предопределенные в инструменте проверки и миграции;

2) действия, определяемые плагинами (см. 7.5);

3) действия, заданные в пользовательских сценариях.

Используемые сценарии должны размещаться в каталоге старой ОС /usr/share/astra-upgrade/scripts. Порядок запуска сценариев определяется алфавитным порядком имен их файлов. Каждый сценарий должен иметь возможность запуска с параметром config для вывода основной информации о сценарии.

Пример сценария:

example-verification config Результатом запуска сценария с указанным параметром должен быть вывод в стандартный вывод (stdout) следующей основной информации о сценарии:

1) уникальный строковый идентификатор сценария;

2) список уникальных идентификаторов стадий обновления, на которых должен запускаться сценарий, перечисляемых через запятую:

а) verification — стадия подготовки;

б) installation — стадия установки;

в) migration — стадия миграции;

г) finalizing — стадия финализации;

д) abort — стадия отката.

3) порядок выполнения на стадии:

а)pre— перед выполнением стадии;

б)post— после выполнения стадии.

4) краткое описание. Формат вывода информации о сценарии:
id: <уникальный_ID_сценария>
stage: <уникальный_ID_стадии_обновления>,...substage: predescription: Example verification

Если в выводе отсутствует любой из вышеперечисленных параметров или какой-то из них некорректен, сценарий не будет запущен.
При запуске без параметров сценарий должен выполнять свой основной код. В процессе выполнения сценария в stdout может выводиться следующая информация:

1) произвольное сообщение, попадающее в отчет;

2) путь к конфигурационному файлу сценария;

3) предупреждения;

4) ошибки.

Выводимая сценарием информация будет записана в отчет /var/cache/astra-upgrade/upgrade.report.yaml в файловой системе новой ОС, откуда эти данные могут быть получены другими сценариями в процессе обновления. Также сценарий может иметь код возврата. Если код возврата ненулевой, то считается, что выполнение сценария завершилось с ошибкой. Результаты выполнения сценария должны выводиться в следующем формате:
message: <произвольное сообщение> config: <путь к файлу>.yaml warning: <предупреждение> error: <ошибка>

Если вывод сценария пуст или не соответствует данному формату ни в одной выведенной строке, но код возврата при этом равен нулю, действие считается полностью успешно выполненным.

Плагины

Помимо пользовательских сценариев при миграции также могут использоваться плагины, написанные на языке Python. Плагины выполняются после заранее заданных проверок и миграции, но до выполнения пользовательских сценариев. Функциональность плагинов аналогична сценариям, но предоставляет больше возможностей для взаимодействия с инструментами обновления. Для того, чтобы плагин был загружен, файл с ним необходимо поместить в каталог /usr/share/astra-upgrade/plugins старой ОС.

Откат выполненной миграции

Для отката выполненной миграции на очередное обновление используется инструмент командной строки astra-revert-upgrade. Синтаксис команды:
astra-revert-upgrade [параметр]
Параметры инструмента:

Параметр Описание

full Полный откат к старой ОС с уничтожением созданных разделов для новой ОС

soft«Мягкий» откат к старой ОС с сохранением новой ОС, позволяющий вернуться к ней в будущем

back Возврат к новой ОС после «мягкого» отката

При запуске инструмент производит следующие действия:

1) чтение данных о дисковых разделах из отчета об обновлении /var/log/upgrade.report.yaml;

2) проверка текущей версии ОС.

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

Полный откат миграции

Полный откат миграции возможен только из новой ОС. При полном откате производится возврат к старой ОС с удалением разделов новой ОС. Для выполнения полного отката выполнить команду:
astra-revert-upgrade full
Полный откат выполняется в следующем порядке:

1) монтируется раздел со старой ОС;

2) конфигурационный файл загрузчика /etc/default/grub в новой ОС заменяется конфигурационным файлом загрузчика из старой ОС;

3) загрузочный раздел старой ОС восстанавливается из резервной копии /var/cache/bootback.tar;

4) резервная копия загрузочного раздела старой ОС удаляется;

5)в новой ОС создаются юниты systemd для уничтожения разделов новой ОС и восстановления конфигурационных файлов графического окружения при загрузке ОС;

6) выполняется перезагрузка в старую ОС.

При загрузке старой ОС запускаются созданные юниты systemd, которые после завершениясвоей работы удаляются.

«Мягкий» откат миграции

«Мягкий» откат миграции возможен только из новой ОС. При «мягком» откате производится возврат на старую ОС, разделы новой ОС при этом не удаляются, что дает возможность в дальнейшем возможно вернуться к новой ОС (см. 7.6.3). Для «мягкого» откатавыполнить команду:
astra-revert-upgrade soft
Мягкий откат выполняется в следующем порядке:

1) монтируется раздел со старой ОС;

2) создается резервная копия загрузочного раздела /boot новой ОС и сохраняется в архив /var/cache/bootback.new.tar в файловой системе старой ОС, также из новой ОС копируется в старую ОС отчет об обновлении /var/log/upgrade.report.yaml;

3)загрузочный раздел старой ОС восстанавливается из резервной копии /var/cache/bootback.tar;

4)в старой ОС создается юнит systemd для восстановления конфигурационных файлов пользовательского графического окружения при загрузке ОС;

5) выполняется перезагрузка в старую ОС.

При загрузке старой ОС запускается созданный юнит systemd, который после восстановления настроек графического окружения удаляется.

Возврат к новой ОС после «мягкого» отката

Возврат к новой ОС возможен только из старой ОС. Для возврата к новой ОС после «мягкого» отката выполнить команду:
astra-revert-upgrade back
Возврат к новой ОС выполняется в следующем порядке:

1) раздел с новой ОС монтируется в каталог/target. Если этого каталога нет, то он создается;

2) загрузочный раздел новой ОС восстанавливается из резервной копии /var/cache/bootback.new.tar;

3) создается юнит systemd для восстановления конфигурационных файлов пользовательского графического окружения при загрузке ОС;

4) выполняется перезагрузка в новую ОС.

При загрузке новой ОС запускается созданный юнит systemd, который после восстановления настроек графического окружения удаляется