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

В составе Astra Linux Special Edition РУСБ.10015-01 1.7 с установленным актуальным оперативным обновлением (далее - старая ОС) доступны инструменты astra-full-upgrade и astra-console-upgrade для автоматического обновления (далее — миграция) на следующее очередное обновление — 1.8 (далее — новая ОС).

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

• Миграция предназначена для обновления клиентских компьютеров и не должна применяться для серверов, то есть для компьютеров, предоставляющих разделяемые ресурсы и сервисы для других компьютеров.
• Миграция возможна только с очередного обновления Astra Linux Special Edition 1.7 с установленным актуальным оперативным обновлением и поддерживается только для аппаратной платформы x86-64.
• Миграция невозможна если в старой ОС:
  • включен режим файловой системы «только чтение» (overlay);
  • включен режим ЗПС;
• Миграция поддерживается как на компьютерах с загрузкой BIOS, так и на компьютерах с загрузкой EFI.
• Рекомендации по конфигурации дисковых разделов для подготовки к миграции описаны в статье Рекомендации по установке Astra Linux Special Edition x.7 на клиентские компьютеры.
  Для успешного выполнения миграции требуется наличие свободного непрерывного дискового пространства размером не менее 60 ГБ:
  • данное пространство не должно быть отформатировано с созданием какой-либо файловой системы;
  • при загрузке в режиме BIOS свободное пространство должно быть выделено на основном диске;
  • при загрузке в режиме BIOS в сочетании с таблицей дисковых разделов в формате GPT дополнительно на основном диске должен быть создан дисковый раздел без файловой системы с флагом bios_grub размером 1МБ;
  • при загрузке в режиме EFI в случае отсутствия свободного места на основном диске может использоваться подключенный дополнительный диск;
  • по умолчанию свободное дисковое пространство не должно входить в состав логического тома LVM (см. далее описание настройки параметров миграции);
  Рекомендуемые параметры дисковых разделов для успешной миграции:
  • таблица дисковых разделов в формате GPT (поддерживается также формат MBR);
  • дисковый раздел /boot объемом не менее 1 ГБ (рекомендуется 2GB);
  • при использовании загрузки BIOS в сочетании с таблицей дисковых разделов GPT — дисковый раздел объемом 1МБ с флагом bios_grub;
  • группа томов LVM с файловой системой ext4, включающая:
    • дисковый раздел объемом не менее 60 ГБ с корневой файловой системой;
    • дисковый раздел с каталогом /home (домашние каталоги пользователей);
    • прочие разделы, при необходимости, например /tmp, /var/tmp и др.

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

  • неразмеченное пространство, которое может располагаться как внутри группы томов LVM, так и за ее пределами.
• При выполнении миграции стандартными точками монтирования дисковых ресурсов считаются каталоги стандартной файловой системы Linux (/, /var, /boot, /boot/efi, /home, /cache, /tmp, /var/tmp и т.д.).
  Каталоги /boot, /boot/efi и /home при миграции не дублируются, то есть в новой ОС они будут примонтированы в неизменном виде.
  При использовании монтируемых ресурсов для других стандартных каталогов эти ресурсы в процессе миграции будут продублированы, и дубли будут монтироваться в новую ОС.
  Если используются иные точки монтирования (нестандартные дисковые или сетевые ресурсы), то перед выполнением миграции:
  • остановить приложения, использующие нестандартные дисковые ресурсы;
  • отмонтировать нестандартные дисковые ресурсы;
  • удалить (закомментировать) записи в /etc/fstab, задающие монтирование этих ресурсов.

Особенности выполнения миграции

При выполнении миграции с использованием неразмеченного пространства:

• Миграция позволяет сохранить:
  • стандартные домашние каталоги пользователей старой ОС (каталог /home );
  • установленное прикладное ПО.
• Миграция должна выполняться от имени суперпользователя ОС (при включенном МКЦ — от имени суперпользователя с высоким уровнем целостности).
• Миграция может выполняться в графическом режиме (в режиме графической консоли) или в режиме командной строки:
  • графический режим (инструмент astra-full-upgrade) позволяет выполнить миграцию в интерактивном взаимодействии с инструментом или с поэтапным конролем;
  • режим командной строки (инструмент astra-console-upgrade) позволяет выполнять миграцию удаленно в сессии SSH идти в сценариях Puppet/Ansible/Foreman;
• Если свободное дисковое пространство, зарезервированное для выполнения миграции, не входит в состав LVM, или LVM вообще не используется, то при миграции в пространстве будет создана новая группа томов LVM.
• При миграции все имеющиеся дисковые разделы старой ОС, кроме разделов /home, /boot и swap, будут созданы заново в дисковом пространстве, выделенном для новой ОС. По умолчанию это неразмеченное дисковое пространство, однако в конфигурации может быть указан дисковый раздел для размещения новой ОС.
• Если до миграции использовалось защитное преобразование дисковых разделов, то новые разделы будут заменены на не преобразованные.
• Дисковые разделы старой ОС после миграции останутся на диске в неизменном виде и могут быть впоследствии использованы для отката выполненной миграции или для размещения информации при миграции на следующее очередное обновление.

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

  1. Предопределенные в инструменте проверки и миграции.
  2. Действия, определяемые плагинами (см. Плагины).
  3. Действия, заданные в пользовательских сценариях (см. Пользовательские сценарии).

Настройка параметров миграции

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

Параметры, значения которых которые чаще всего требуют модификации:

• Расположение репозиториев, из которых будет производиться установка пакетов новой ОС:
  

  target_repos: # Настройки источников пакетов
    sources: # Список репозиториев (как сетевых так и локальных), используемых для обновления
      - 'deb https://download.astralinux.ru/astra/stable/1.8_x86-64/main-repository/ 1.8_x86-64 main contrib non-free non-free-firmware'
      - 'deb https://download.astralinux.ru/astra/stable/1.8_x86-64/extended-repository/ 1.8_x86-64 main contrib non-free non-free-firmware'
    dirs: # Список директорий с пакетами, из которых будут созданы локальные репозитории, которые также будут использоваться для обновления.
      - '/opt/repo'
    sources_list: all # all | disable | third_party | astra

  
  
  • sources: — репозитории, из которых будет выполняться установка новой ОС. По умолчанию используется интернет-репозитории актуального оперативного обновления Astra Linux Special Edition 1.8. При работе в изолированны сетях (без доступа к Интернет) здесь могут быть указаны собственные репозитории, сетевые или локальные. При этом используется формат указания репозиториев, принятый для файлов /etc/apt/sources.list (подробнее см. Создание локальных и сетевых репозиториев
  • dirs: — дополнительно может быть указан локальный каталог с пакетами, который будет использоваться как дополнительный репозиторий.
    
    При модификации состава репозиториев и добавлении пакетов следует учитывать, что общий состав репозиториев и добавленных пакетов, должен быть замкнут по зависимостям. При отсутствии зависимостей для пакета это пакет не будет установлен в процессе ммиграции.
  • sources_list: — политика использования репозиториев, указанных в файле /etc/apt/sources.list и файлах в каталоге /etc/apt/sources.list.d Старой ОС. Возможные варианты:
    • all — использовать все указанные репозитории;
    • disable — не использовать;/.
    • third_party — использовать только сторонние репозитории;
    • astra — использовать только репозитории Astra Linux,
• Политика использования неразмеченного пространства для размещения новой ОС:
  

  #  use_existing: /dev/mapper/astra--VG-root # Использовать существующий раздел под корневую ФС целевой системы. При использовании этой опции настройки разметки игнорируются

  По умолчанию для развертывания новой ОС используется неразмеченное пространство, не входящее в состав логических томов LVM. С помощью параметра конфигурации use_existing может быть указан существующий логический том LVM.

Пример файла:

# Настройки обновления
target_repos: # Настройки источников пакетов
  sources: # Список репозиториев (как сетевых так и локальных), используемых для обновления
    - 'deb https://download.astralinux.ru/astra/stable/1.8_x86-64/main-repository/ 1.8_x86-64 main contrib non-free non-free-firmware'
    - 'deb https://download.astralinux.ru/astra/stable/1.8_x86-64/extended-repository/ 1.8_x86-64 main contrib non-free non-free-firmware'
  dirs: # Список директорий с пакетами, из которых будут созданы локальные репозитории, которые также будут использоваться для обновления.
    - '/opt/repo'
  sources_list: all # all | disable | third_party | astra
 
base_system_install: # Настройки установки базовой системы
  source: debootstrap # Тип источника установки. Возможные варианты: debootstrap | archive | images. Исходя из выбранного варианта установки, будут использоваться соответствующие настройки, при этом настройки для других типов
                      # источников будут проигнорированы.
  debootstrap: # Настройки для варианта установки с использованием debootstrap (source: debootstrap)
    repo: https://download.astralinux.ru/astra/stable/1.8_x86-64/main-repository/ # Репозиторий из которого должен быть проведен debootstrap.
    use_disk: false # Установить в true, если требуется установка с диска. При установке с диска, указывать репозиторий (параметр repo) не требуется.
    mountpoint: /run/live/medium # Точка для монтирования диска
  images: # Список образов для варианта установки с использованием заранее подготовленных образов системы (source: images).
    - <path to rootfs image>/rootfs.img
  archive: <path to rootfs archive>/rootfs.tar.gz # Путь к архиву для варианта установки путем распаковки заранее подготовленного архива (source: archive).
 
packages: # Настройки установки и верификации пакетов
#  critical: # Список пакетов, которые отсутствуют в исходной системе, но должны быть установлены в целевую систему при обновлении
#    - lvm2
#    - cryptsetup
#    - plymouth-astra-theme
 
#  whitelist: # Список сторонних пакетов, которые установлены в исходной системе и должны быть перенесены в целевую систему при обновлении (см. также allow_third_party)
#    - code
 
  target_kernel_version: 'auto' # Выбор ядра, которое должно быть установлено в целевую систему при обновлении. Используйте значение 'auto' - для автоматического выбора последней доступной версии ядра.
  allow_third_party: true # Установить в false, чтобы запретить перенос всех установленных в исходной системе сторонних пакетов (см. также whitelist)
  check_gpg: true # Установить в false, чтобы отключить проверку gpg-ключей репозиториев для пакетов из состава AstraLinux.
 
#  removed: # Список пакетов, которые установлены в исходной системе, но не должны быть перенесены в целевую систему при обновлении.
#    - name
 
#  predefined_versions: # Список пакетов, для которых в целевую систему должна быть установлена указанная версия в принудительном порядке
#     package_name: version
 
# Путь к директории - точке монтирования устройства/раздела, которое будет использовано при проведении обновления.
target_path: '/target'
 
# Путь к директории, в которой хранится отчет и прочие файлы, генерируемые в процессе обновления
report_path: '/var/cache/astra-upgrade'
 
download: # Настройки параметров загрузки пакетов
  path: '/var/cache/astra-upgrade/download' # Путь к директории, в которую будет производиться загрузка пакетов
  keep: true # Установить в false, чтобы удалять загруженные пакеты при аварийном откате и откате с использованием команды set ready-for-download.
  check_time: 60 # Временной интервал между проверками на наличие изменений в составе пакетов исходной системы. Используется только в случае, если нет возможности отслеживать кэш пакетов. Задается в секундах.
  max_delay: 240 # Максимальное значение отсрочки загрузки пакетов, задается в минутах.
  retry_count: 3 # Количество повторных попыток загрузки при ошибках загрузки. Установить значение равным -1 для снятия ограничения.
  retry_delay: 30 # Временной интервал между повторными попытками загрузки, задается в секундах.
 
# Срок (в днях), через который текущая система перейдет в режим принудительного обновления при перезагрузке. Отсчет начинается с момента завершения загрузки пакетов.
max_upgrade_delay: 7 # in days
 
# Установить в true, чтобы игнорировать данные предыдущего отчета (если он имеется) при проведении проверок системы
ignore_prev_report: false
 
# Настройки разметки
target_fs_size_policy: 'auto' # Политика использования свободного места на устройстве/разделе, которое будет использовано при проведении обновления.  Возможные варианты: 'auto', 'minimal', 'maximum'
target_fs_minimal_reserve: 1000 # Размер дополнительного дискового пространства, резервируемого под рост ОС. Задается в Мб
target_fs_snapshot_reserve: 5000 # Размер дополнительно дискового пространства, резервируемого под создание снепшотов
target_rootfs_size: 'auto' # Размер дискового пространства, выделяемого под корневую ФС. Может быть вычислен динамически ('auto'), также можно  указать вручную в Мб.
backup_path: '/backup_1.7' # Путь до директории, в которой будет храниться копия старой системы
dummydisk_path: '/' # Путь до фиктивного диска для loop устройств
 
# Управление шаблоном разметки
partitioning_template:
  not_rebuild: false # Выставить в true, если нужно использовать скорректированный шаблон разметки из предыдущего отчета.
#  use_existing: /dev/mapper/astra--VG-root # Использовать существующий раздел под корневую ФС целевой системы. При использовании этой опции настройки разметки игнорируются

# Управление настройками безопасности
security_settings:
  enable_overlay: false # Выставить в true, чтобы включить astra-overlay после обновления системы

Порядок выполнения миграции

Общая подготовка к миграции

1. Установить актуальное оперативное обновление старой ОС.
2. Установить последнюю доступную версию ядра ОС:
   
   sudo apt install linux-image-latest
3. Перезагрузить ОС с использованием последней версии ядра.
4. Удалить все неиспользуемые версии ядра. См. статью Astra Linux: установка и обновление ядер серии 5 и выше.
5. Установить пакеты:
   1. Для выполнения миграции в графическом режиме (в том числе в графической консоли) — пакет astra-full-upgrade:
      
      sudo apt install astra-full-upgrade
   2. Для выполнения миграции в текстовом режиме — пакет astra-console-upgrade:
      
      sudo apt install astra-console-upgrade
6. По необходимости отредактировать конфигурационный файл /usr/lib/python3/dist-packages/astra_upgrade/configs/upgrade.conf.yaml:
   • указать корректные репозитории пакетов для установки новой ОС;
   • указать дисковый раздел для выполнения миграции в политике использования дисковых , или удалить один из логических разделов, освободив неразмеченное место.

Выполнение миграции в графическом окружении

Миграция в графическом окружении может быть запущена одной командой:

Эта команда автоматически выполнит необходимые проверки, и в случае успешного завершения проверок, запустит дальнейшие действия по миграции.

Для пошагового выполнения миграции с проверкой промежуточных результатов:

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

Для выполнения миграции в текстовой консоли (текстовой командной строке) выполнить команду:

Эта команда автоматически выполнит необходимые проверки, и в случае успешного завершения проверок, запустит дальнейшие действия по миграции.

Проверка успешности миграции

Для проверки успешности миграции войти в пользовательскую сессию и убедиться, что миграция выполнена успешно и загружена новая ОС. Это можно сделать выполнив команду:

В результате выполнения команды должен быть выведен номер установленной сборки Astra Linux. Для Astra Linux Special Edition 1.8 это должен быть номер вида 1.8.X.XX. Номер, начинающийся на 1.7 указывает, что миграция завершилась с ошибкой и загружена старая ОС. Для диагностики ошибки следует использовать журнал /var/log/astra-upgrade.log.

Общий синтаксис инструментов миграции

Общий синтаксис вызова графического инструмента миграции

Общий синтаксис вызова текстового инструмента миграции

Синтаксис вызова текстового инструмента миграции:

Параметры:

• -f, --force — выполнение миграции;
• -h, --help — вывод подсказки;
• -u, --self-upgrade — автоматическое обновление утилиты, при установленном актуальном обновлении не требуется.

Пользовательские сценарии

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

Пример вызова сценария:

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

1. Уникальный строковый идентификатор сценария.
2. Список уникальных идентификаторов стадий обновления, на которых должен запускаться сценарий, перечисляемых через запятую:
   • verification — стадия подготовки;
   • installation — стадия установки;
   • migration — стадия миграции;
   • finalizing — стадия финализации;
   • abort — стадия отката.
3. Порядок выполнения на стадии:
   • pre — перед выполнением стадии;
   • post— после выполнения стадии.
4. Краткое описание.

Формат вывода информации о сценарии:

id: <уникальный_ID_сценария>
stage: <уникальный_ID_стадии_обновления>,...
substage: pre
description: Example verification

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

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

• произвольные сообщения, попадающие в отчет;
• путь к конфигурационному файлу сценария;
• предупреждения;
• сообщения об ошибках.

Выводимая сценарием информация будет записана в отчет /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. проверка текущей версии ОС.

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

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

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

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

1. Монтируется раздел со старой ОС.
2. Конфигурационный файл загрузчика /etc/default/grub в новой ОС заменяется конфигурационным файлом загрузчика из старой ОС.
3. Загрузочный раздел старой ОС восстанавливается из резервной копии /var/cache/bootback.tar.
4. Резервная копия загрузочного раздела старой ОС удаляется.
5. В новой ОС создаются юниты systemd для уничтожения разделов новой ОС и восстановления конфигурационных файлов графического окружения при загрузке ОС.
6. Выполняется перезагрузка в старую ОС.
7. При загрузке старой ОС запускаются созданные юниты systemd , которые после завершения своей работы удаляются.

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

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

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

1. Монтируется раздел со старой ОС.
2. Создается резервная копия загрузочного раздела /boot новой ОС и сохраняется в архив /var/cache/bootback.new.tar в файловой системе старой ОС, также из новой ОС копируется в старую ОС отчет об обновлении /var/log/upgrade.report.yaml.
3. Загрузочный раздел старой ОС восстанавливается из резервной копии /var/cache/bootback.tar.
4. В старой ОС создается системный юнит службы systemd для восстановления конфигурационных файлов пользовательского графического окружения при загрузке ОС.
5. Выполняется перезагрузка в старую ОС.
6. При загрузке старой ОС запускается созданный юнит systemd , который после восстановления настроек графического окружения удаляется.

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

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

Возврат к новой ОС выполняется в следующем порядке:

1. Раздел с новой ОС монтируется в каталог/target. Если этого каталога нет, то он создается.
2. Загрузочный раздел новой ОС восстанавливается из резервной копии /var/cache/bootback.new.tar
3. Создается юнит systemd для восстановления конфигурационных файлов пользовательского графического окружения при загрузке ОС
4. Выполняется перезагрузка в новую ОС.
5. При загрузке новой ОС запускается созданный юнит systemd , который после восстановления настроек графического окружения удаляется.

Выявление и устранение ошибок

Отчет о последнем выполнявшемся этапе миграции сохраняется в журнале /var/cache/astra-upgrade/upgrade.report.yaml.

Если после завершения миграции загружается старая ОС, то для диагностики следует использовать журналы в каталоге /var/log, в частности журнал /var/log/astra-upgrade.log.