Мигратор

«Мигратор» — это утилита, позволяющая упростить миграцию RHEL-подобных (RHEL — Red Hat Enterprise Linux) дистрибутивов на МСВСфера ОС с сохранением настроек, данных и приложений.

Сценарии миграции на более высокую верию

На текущий момент доступны следующие сценарии миграции на более высокую версию.

• Миграция с EL 7 (EL — Enterprise Linux) на МСВСфера 8 ОС;

• Миграция с EL 8 на МСВСфера 9 ОС;

• Миграция с AlmaLinux/Rocky Linux/Oracle Linux/Euro Linux 8 на МСВСфера 9 ОС.

Инструкции по миграции

Миграция с EL 7 на МСВСфера 8 ОС

1. Если вы используете CentOS, то на данный момент большинство зеркал отключены. Для успешной миграции необходимо переключить репозитории на зеркало mirror.yandex.ru:

$ sudo sed -i 's@^mirrorlist@#mirrorlist@g;s@#baseurl=http://mirror.centos.org/centos/$releasever@baseurl=https://mirror.yandex.ru/centos/7.9.2009/@g' /etc/yum.repos.d/CentOS-Base.repo

Далее обновите систему и перезагрузить компьютер:

$ sudo yum update -y

$ sudo reboot

2. Подключите репозиторий «Мигратора»:

   $ sudo yum -y install https://repo1.msvsphere-os.ru/migrator/migrator-release-latest-el$(rpm --eval %rhel).noarch.rpm
   

3. Установите «Мигратор» и пакеты с правилами для обновления:

   $ sudo yum -y install leapp-upgrade leapp-data-msvsphere
   

4. Запустите preupgrade-проверку:

   $ sudo leapp preupgrade
   

   Результатом работы утилиты будет отчёт, по которому можно определить возможность обновления системы. Подробный отчёт можно найти в файле /var/log/leapp-report.txt. Также будет сгенерирован файл /var/log/leapp/answerfile для подтверждения исправления найденных проблем, типичных для EL 7.

5. При возникновении ошибок их необходимо устранить. См. Известные проблемы при миграции с EL 7 на МСВСфера 8 ОС.

6. Снова запустите preupgrade-проверку. Если результат будет помечен жёлтым или зелёным, то можно продолжать миграцию.

7. Запустите обновление:

   $ sudo leapp upgrade
   

8. После удачного завершения обновления перезагрузите систему:

   $ reboot
   

9. После перезагрузки в загрузчике операционной системы выберите пункт Migrator-Upgrade-Initramfs.

10. Дождитесь окончания обновления системы. В конце обновления система будет перезагружена и загрузится в обычном режиме. При первом запуске будет запущена процедура повторной маркировки меток SELinux. После чего система перезагрузится ещё раз.

11. Если вы до этого обновили EL 7 до МСВСфера 8 ОС, то вам необходимо сначала удалить пакеты, оставшиеся от предыдущей версии «Мигратора». Для этого выполните следующую команду:

    $ sudo dnf remove '*leapp*'
    

    И удалите из конфигурационного файла /etc/yum.conf следующую строку:

    exclude=python2-leap...
    

Миграция с EL 8 на МСВСфера 9 ОС

1. Обновите МСВСфера 8 ОС и перезагрузите компьютер:

   $ sudo dnf update -y
   
   $ sudo reboot
   

2. Подключите репозиторий «Мигратора»:

   $ sudo dnf -y install -y https://repo1.msvsphere-os.ru/migrator/migrator-release-latest-el$(rpm --eval %rhel).noarch.rpm
   

3. Установите «Мигратор» и пакет с правилами для обновления:

   $ sudo dnf -y install leapp-upgrade leapp-data-msvsphere
   

4. Запустите preupgrade-проверку:

   $ sudo leapp preupgrade
   

   Результатом работы утилиты будет отчёт, по которому можно определить возможность обновления системы. Подробный отчёт можно найти в файле /var/log/leapp-report.txt. Также будет сгенерирован файл /var/log/leapp/answerfile для подтверждения исправления найденных проблем, типичных для МСВСфера 8 ОС.

5. При возникновении ошибок их необходимо устранить. См. Известные проблемы при миграции с EL 8 на МСВСфера 9 ОС.

6. Снова запустите preupgrade-проверку. Если результат будет помечен жёлтым или зелёным, то можно продолжать миграцию.

7. Запустите обновление:

   $ sudo leapp upgrade
   

8. После удачного завершения обновления перезагрузите систему:

   $ reboot
   

9. После перезагрузки в загрузчике операционной системы выберите пункт Migrator-Upgrade-Initramfs.

10. Дождитесь окончания обновления системы. В конце обновления система будет перезагружена и загрузится в обычном режиме. При первом запуске будет запущена процедура повторной маркировки меток SELinux. После чего система перезагрузится ещё раз.

Миграция с AlmaLinux/Rocky Linux/Oracle Linux/Euro Linux 8 на МСВСфера 9 ОС

Процесс миграции с дистрибутивов AlmaLinux, Rocky Linux, Oracle Linux, Euro Linux 8 на МСВСфера 9 ОС идентичен процессу Миграция с EL 8 на МСВСфера 9 ОС.

Известные проблемы

Известные проблемы при миграции с EL 7 на МСВСфера 8 ОС

1. Обратите внимание, что Oracle Linux должен быть загружен в ядро 3.10.

2. Скорее всего для продолжения обновления необходимо будет отключить модуль pata_acpi и PAM-модуль pkcs11:

   $ sudo rmmod pata_acpi
   

   $ sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True
   

3. Для Oracle Linux и Red Hat Linux необходимо будет удалить пакет python-hwdata:

   $ sudo yum -y remove python-hwdata
   

4. Для Oracle Linux также будет необходимо удалить пакеты uname26 и iwlax2xx-firmware:

   $ sudo yum -y remove uname26 iwlax2xx-firmware
   

Эти и другие требуемые изменения будут описаны в файле /var/log/leapp/leapp-report.txt.

Известные проблемы при миграции с EL 8 на МСВСфера 9 ОС

1. Обратите внимание, что Oracle Linux должен быть загружен в ядро 4.18.

2. Если Oracle Linux не сможет загрузить метаданные некоторых репозиториев, отключите их:

   $ sudo dnf config-manager --set-disabled <repo>
   

3. Для CentOS Stream необходимо изменить версию дистрибутива с 8 на 8.5 в файле /etc/centos-release. А также отключить репозитории, у которых невозможно загрузить метаданные:

   $ sudo dnf config-manager --set-disabled <repo>
   

4. Скорее всего для продолжения обновления будет необходимо исправить зону firewalld:

   $ sudo sed -i "s/^AllowZoneDrifting=.*/AllowZoneDrifting=no/" /etc/firewalld/firewalld.conf
   

   А также отключить проверку vdo устройств:

   $ sudo leapp answer --section check_vdo.confirm=True
   

   Запретить доступ по ssh пользователю root:

   $ echo PermitRootLogin no | sudo tee -a /etc/ssh/sshd_config
   

Эти и другие требуемые изменения будут описаны в файле /var/log/leapp/leapp-report.txt.

Диагностика

В некоторых случаях обновление системы из режима Migrator-Upgrade-Initramfs заканчивается неудачно и запускается отладочная консоль. Скорее всего ошибка происходит на этапе установки отдельных пакетов, поэтому DNF возвращает ошибку. При этом остальные пакеты устанавливаются успешно, так как все зависимости разрешаются ещё на этапе подготовки системы к обновлению.

В этом случае следует изучить системный журнал доступный через команду journalctl.

1. В Initramsfs находится обрезанная версия загрузочного образа, поэтому команды less и more там отсутствуют. Лучше всего перенаправить вывод journalctl в файл:

   $ journalctl > system.log
   

2. Подключите корневой раздел основной операционной системы:

   $ mkdir /mnt
   
   $ mount /dev/sdXX /mnt
   

3. Для LVM подключите нужный том:

   $ mount /dev/mapper/XX-root /mnt
   

4. Если вы используете отдельный раздел для каталога /usr, то его также необходимо подключить в каталог /mnt/usr.

5. Далее скопируйте system.log в /mnt/tmp и измените корневой каталог на /mnt с помощью команды:

   $ chroot /mnt
   

   Теперь вы можете просматривать файл system.log с помощью команды less.

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

7. Следует обязательно переразметить метки SELinux. Для этого необходимо создать в корневом разделе операционной системы файл .autorelabel:

   $ touch /mnt/.autorelabel
   

8. Если вы изменяли корневой каталог командой chroot, то необходимо вернуться в корневой каталог initramfs при помощи команды exit или комбинации клавиш Ctrl + d.

9. После этого отключите все разделы, которые вы подключали выше:

   $ umount /mnt/usr
   
   $ umount /mnt
   

10. Перезагрузите систему:

$ reboot

Система начнёт загрузку в обычном режиме, переразметит метки SELinux и перезагрузится ещё раз.

Поддержка сторонних поставщиков

В настоящее время «Мигратор» поддерживает следующие сторонние репозитории:

• EPEL в настоящее время поддерживается только для обновлений до МСВСфера ОС.

• Docker CE — для всех поддерживаемых операционных систем.

• MariaDB — для всех поддерживаемых операционных систем.

• Microsoft Linux Package Repositories — для всех поддерживаемых операционных систем.

• nginx — для всех поддерживаемых операционных систем.

• PostgreSQL — для всех поддерживаемых операционных систем.

Процедура интеграции пакетов сторонних репозиториев в процесс обновления «Мигратора» состоит из следующих шагов.

1. Клонируйте репозиторий leapp-data.

2. Перейдите в ветку devel.

3. Перейдите в папку vendors.d. Она содержит необходимые файлы для каждого поддерживаемого стороннего репозитория.

4. Чтобы добавить новый сторонний репозиторий необходимо создать отдельные файлы. Эти файлы должны иметь одинаковую часть <vendor_name> в своих именах:

   • <vendor_name>_map.json — см. «Файл соответствия репозиториев».

   • <vendor_name>.repo — см. «Информация о репозитории, в котором содержатся пакеты».

   • <vendor_name>.sigs — см. «Список подписей поставщика для пакетов».

   • <vendor_name>_pes.json — см. «Список событий миграции для пакета».

Предупреждение

Обратите внимание, что все сторонние пакеты должны быть подписаны.

Файл соответствия репозиториев

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

Структура файла соответствия:

• datetime — временная метка создания файла (например, 202306191741Z);

• version — версия базы данных. Актуальную версию можно посмотреть в репозитории leapp-data.

• Разделы (описаны ниже): * mapping — определяет соответствия между репозиториями. * repositories — описывает все задействованные репозитории.

Важно

Файл соответствия определяет, участвуют ли пакеты от поставщика в процессе обновления. Если найден хотя бы один из указанных исходных репозиториев, поставщик считается активным, и его репозитории и события PES будут участвовавть в процессе обновления. Если ни один репозиторий не найден — поставщик будет проигнорирован при обновлении.

Раздел mapping — соответствие репозиториев

Устанавливает соответствие между версиями системы и связанными с ними репозиториями.

Содержит следующие поля:

• source_major_version — начальная основная (мажорная) версия системы (например, 7 или 8).

• target_major_version — целевая основная (мажорная) версия (например, 8 или 9).

• entries — список правил соответствия:

• source — ID исходный репозиторий из старой системы.

• target — ID одного или нескольких репозиториев, из которых будут устанавливаться обновлённые пакеты.

• Каждый исходный репозиторий может быть сопоставлен с одним или несколькими целевыми репозиториями.

• Все репозитории, указанные в source и target, должны быть также описаны в разделе repositories и в файле .pes. Их ID должны совпадать.

В качестве примера вы можете использовать файлы для MariaDB — mariadb_map.json.

Раздел repositories — описание репозиториев

Этот раздел содержит детальную информацию о каждом исходном и целевом репозитории.

Информация о каждом репозитории должна включать следующее:

• pesid — уникальный идентификатор, используемый в .pes-файлах. Если он не совпадёт, обновление завершится с ошибкой.

• entries:

  • major_version — основная (мажорная) версия системы.

  • repoid — ID репозитория. Должен совпадать с ID из .repo-файла. (Может не совпадать с pesid.)

  • arch — архитектура системы (например, x86_64).

  • channel — канал репозитория (актуально для Red Hat):

    • ga — стабильный (основной).

    • beta — тестовый.

    • eus, e4s, aus, tus — расширенные каналы поддержки.

  • repo_type — тип репозитория:

    • rpm — бинарные пакеты.

    • srpm — исходные пакеты.

    • debuginfo — отладочная информация.

В качестве примера вы можете использовать файлы для MariaDB — mariadb_map.json.

Информация о репозитории, в котором содержатся пакеты

Файл .repo определяет, какие именно репозитории поставщика будут использоваться при обновлении.

Файл репозитория имеет формат, типичный для файлов репозитория пакетов YUM/DNF:

[repository ID]
name = repository name
baseurl = repository baseurl
gpgkey = GPG Key directory
gpgcheck = 1
enabled = 1

В качестве примера вы можете использовать файлы для MariaDB — mariadb.repo.

Совет

Репозитории, перечисленные в этом файле, используются только во время обновления. В обновлённую систему репозитории добавляются как обычно.

Список подписей поставщика для пакетов

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

Чтобы узнать подпись конкретного пакета, выполните команду:

$ rpm -qip <ИМЯ_ПАКЕТА> | grep Signature

Пример вывода:

Signature   : DSA/SHA1, Mon Aug 23 08:17:13 2021, Key ID 8c55a6628608cb71

Значение Key ID (в данном случае — 8c55a6628608cb71) и есть публичный заголовок пакета, который необходимо добавить в файл подписей. Файл должен содержать одну подпись на строку.

В качестве примера вы можете использовать файл для MariaDB — mariadb.sigs.

Список событий миграции для пакета

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

Как правило, эта информация хранится в файле:

• в GitHub: leapp-data/vendors.d/<vendor_name>_pes.json

• в обновляемой системе: /etc/leapp/files/vendors.d/<vendor_name>_pes.json

Предупреждение

Действия из PES-файлов применяются только к тем пакетам, которые подписаны и имеют подпись в файле <vendor_name>.sigs. Неподписанные пакеты будут обновлены только в том случае, если на них есть зависимость от подписанных пакетов.

Создание pes.json

Если дополнительные действия не требуются, используйте следующий базовый шаблон:

{
  "legal_notice": "",
  "packageinfo": [],
  "provided_data_streams": [
      "2.0"
  ],
  "timestamp": "202408081321Z"
}

Если требуются дополнительные действия, то добавьте информацию для обновления. Для этого создайте новую запись в массиве packageinfo. Поле action определяет одно из следующих действий:

• 0 (present) — сохранить пакеты в in_packageset, чтобы гарантировать включение репозитория, в котором они находятся в целевой системе.

• 1 (removed) — все указанные пакеты будут удалены из in_packageset.

• 2 (deprecated) — сохранить пакеты в in_packageset, чтобы гарантировать включение репозитория, в котором они находятся в целевой системе, но считать их устаревшими.

• 3 (replaced) — удалить все пакеты из in_packageset, установить отсутствующие в системе пакеты из out_packageset, а также сохранить установленные.

• 4 (split) — установить отсутствующие в системе пакеты из out_packageset, сохранить установленные из out_packageset. Удалить из in_packageset пакеты, отсутствующие в out_packageset. Если пакет X разделён на Y и Z, пакет X будет удалён. Если пакет X разделён на X и Y, пакет X не будет удалён.

  Пример:

  {
   "action": 4,
   "architectures": [
       "aarch64",
       "ppc64le",
       "s390x",
       "x86_64"
   ],
   "id": 23,
   "in_packageset": {
       "package": [
           {
               "modulestreams": [
                   null
               ],
               "name": "ntp",
               "repository": "base"
           }
       ],
       "set_id": 29
   },
   "initial_release": {
       "major_version": 7,
       "minor_version": 7,
       "os_name": "CentOS"
   },
   "modulestream_maps": [
       {
           "in_modulestream": null,
           "out_modulestream": null
       }
   ],
   "out_packageset": {
       "package": [
           {
               "modulestreams": [
                   null
               ],
               "name": "chrony",
               "repository": "msvsphere8-baseos"
           },
           {
               "modulestreams": [
                   null
               ],
               "name": "ntpstat",
               "repository": "msvsphere8-appstream"
           }
       ],
       "set_id": 30
   },
   "release": {
       "major_version": 8,
       "minor_version": 0,
       "os_name": "MSVSphere"
   }
  },
  

• 5 (merged) — установить отсутствующие в системе пакеты из out_packageset, удалить из in_packageset пакеты, которых нет в out_packageset. Если пакеты Y и Z объединены в X, пакеты Y и Z будут удалены. Если пакеты Y и Z не объединяются в X, пакеты Y и Z не будут удалены.

  Пример:

  {
   "action": 5,
   "architectures": [
       "aarch64",
       "ppc64le",
       "s390x",
       "x86_64"
   ],
   "id": 93,
   "in_packageset": {
       "package": [
           {
               "modulestreams": [
                   null
               ],
               "name": "infiniband-diags",
               "repository": "base"
           },
           {
               "modulestreams": [
                   null
               ],
               "name": "libibmad",
               "repository": "base"
           }
       ],
       "set_id": 118
   },
   "initial_release": {
       "major_version": 7,
       "minor_version": 7,
       "os_name": "CentOS"
   },
   "modulestream_maps": [
       {
           "in_modulestream": null,
           "out_modulestream": null
       }
   ],
   "out_packageset": {
       "package": [
           {
               "modulestreams": [
                   null
               ],
               "name": "infiniband-diags",
               "repository": "msvsphere8-baseos"
           }
       ],
       "set_id": 9451
   },
   "release": {
       "major_version": 8,
       "minor_version": 0,
       "os_name": "MSVSphere"
   }
  },
  

• 6 (moved to new repository) — сохранить пакет, чтобы убедиться, что репозиторий, в котором он находится в целевой системе, включён. С in_packageset ничего не происходит, поскольку он всегда содержит один пакет — такой же, как и пакет «out».

• 7 (renamed) — удалить in_packageset и установить out_packageset, если он не установлен. Если он уже установлен, оставить out_packageset как есть.

• 8 (reinstalled) — переустановить пакет in_packageset во время обновления. Полезно, если версия пакета не меняется между системами.

Действия 1, 3, 4 и 5 используются наиболее часто.

Предупреждение

Исключения и особые случаи:

• Любое действие, кроме present, игнорируется, если хотя бы один из пакетов в in_packageset помечен на удаление.

• Любое действие, кроме merged, игнорируется, если пакеты из in_packageset не установлены и не помечены на установку.

• Для merged достаточно, чтобы хотя бы один пакет из in_packageset был установлен или помечен на установку.

Дополнительные поля

• architectures — архитектуры, для которых применяются действия.

• id — уникальный идентификатор записи.

• in_packageset — список исходных пакетов, подлежащих обновлению (поле repository указвает репозиторий, из которого пакет был установлен в исходной системе).

• out_packageset — список целевых пакетов (поле repository должно совпадать с полем «Target system repo name in PES» в файле соответствия для поставщика).

• initial_release — исходная система, включая основную (мажорную) и младшую (минорную) (например, MSVSphere 8.9).

• release — целевая система, включая основную (мажорную) и младшую (минорную) (например, MSVSphere 9.3).

Совет

Leapp устанавливает пакеты строго из заданного репозитория. Он лишь включает нужный репозиторий из out_packageset, а DNF устанавливает последнюю доступную версию.

Пример структуры in_packageset и out_packageset:

"in_packageset": {
  "package": [
    {
      "module_stream": null,
      "name": "PackageKit",
      "repository": "base"
    },
    {
      "module_stream": null,
      "name": "PackageKit-yum",
      "repository": "base"
    }
  ],
  "set_id": 1592
},