Každý z vás jistě již někdy dělal upgrade Fedory na novější major verzi. Máme nainstalováno spoustu aplikací, na které jsme již dávno zapomněli a nebo po upgradu nemusí pracovat správně. Jak pak hledat, proč nám dotyčná aplikace nefunguje, ať již z důvodu API, či databáze, či něčeho podobného.

A to je úkol pro preupgrade-assistanta. Preupgrade-assistant sám o sobě nedělá upgrade. O to se stará nástroj s názvem fedup. Preupgrade-assistant pomáhá analyzovat systém, který má být upgradovaný, tak, aby informoval uživatele o potenciálních problémech, které mohou nastat po upgradu.

Preupgrade-assistant využívá funkce OpenSCAP. Preupgrade-assistant má dvě části:

  • engine, který vytváří hlavní XML soubor a spouští OpenSCAP,
  • moduly, které testují určitou část systému.

Jak nainstalovat a spustit preupgrade-assistant

Pro instalaci preupgrade-assistant stačí použít dnf.

dnf install preupgrade-assistant-*

Jak spustit preupgrade-assistant?

preupg

Binárka preupg dodávaná balíkem preupgrade-assistant musí být spouštěna pod uživatelem root, neboť preupgrade-assistant potřebuje mít přístup k celému systému. Výstup preupgrade-assistant po vyhodnocení systému vypadá zhruba následovně:

# preupg
        The Preupgrade Assistant is a diagnostics tool
        and does not perform the actual upgrade.
        Do you want to continue? y/n
      y
      Gathering logs used by preupgrade assistant:
      All installed packages : 01/5 ...finished (time 00:01s)
      ...snip...
      |Removed rpms                 |needs_inspection  |
      |New Features in Fedora 23    |informational     |
      |User git repositories        |needs_inspection  |
      ------------------------------------------------------------------------------
      Tarball with results is stored here /root/preupgrade-results/preupg_results-140528114006.tar.gz .
      The latest assessment is stored in directory /root/preupgrade .
      Summary information:
      We found some potential in-place upgrade risks.
      Read the file /root/preupgrade/result.html for more details.
      Read the admin report file /root/preupgrade/result-admin.html for more details.
      Read the user report file /root/preupgrade/result-user.html for more details.
  • Soubor /root/preupgrade/result.html obsahuje report pro všechny moduly v jednom souboru.
  • Soubor /root/preupgrade/result-admin.html soubor obsahuje report modulů z pohledu adminitrátora.
  • Soubor /root/preupgrade/result-user.html soubor obsahuje report modulů z hlediska uživatele. Mají vliv pouze na uživatelské chování.

Princip preupgrade-assistant

Preupgrade-assistant nejprve posbírá důležité informace o systému a následně spouští jednotlivé moduly v podobě contentů. Preupgrade-assistant nemodifikuje systém, pouze ukládá logy a vytváří report pro administrátora či uživatele.

Preupgrade-assistant poskytuje následující funkcionalitu:

  • Jednotlivé moduly pro preupgrade-assistant je nutné dodat od správců jednotlivých balíčků.
  • Vyhodnotí systém z hlediska upgradu a reportuje důležité informace, které můžou nastat po upgradu.
  • Poskytne data pro klonování systému pomocí pykickstart.
  • Poskytuje postupgrade skripty, které můžou být spuštěny po upgradu.

Data, která preupgrade-assistant posbírá, jsou uložena v adresáři /var/cache/preupgrade/common/*.log. Samotná analýza je uložena v adresáři /root/preupgrade/.

Výstupní kódy

Preupgrade-assistant ve výsledné tabulce ukazuje uživateli/administrátorovi, co má zkontrolovat a jestli je potřeba udělat nějakou akci před či po upgradu. Jednotlivé možnosti v tabulce (a jejich pouzití v Bash skriptu) znamenají:

  • pass (výstup $RESULT_PASS) - Vše je v pořádku. Upgrade by měl projít bez problémů.
  • fail (výstup $RESULT_FAIL) - Upgrade není doporučen z důvod nekompatibility. Na OS Fedora je to ale málo pravděbodobné.
  • needs_action (výstup $RESULT_FAIL) a někde zmíněná hláška log_high_risk)- Je nutné udělat kroky popsané v modulu před samotným upgradem.
  • needs_inspection (výstup $RESULT_FAIL a někde zmíněná hláška log_medium_risk) - Tento výstupní kód neznamená, že upgrade neprojde, ale některé věci by měl administrátor zkontrolovat po upgradu a na doporučeni modulu je opravit
  • information (výstup $RESULT_INFORMATIONAL) - Pouze informativní. Například nové věci/funkce ve Fedoře 23.
  • not_applicable (výstup $RESULT_NOT_APPLICABLE) - Znamená, že dotyčná funkcionalita není nainstalovaná na systému, a proto je modul přeskočen.
  • error (výstup $RESULT_ERROR) - indikuje chybu v preupgrade-assistant nebo v modulu. Hlášení v Bugzille vítáno.

Soubor /root/preupgrade/result.html vypadá zhruba následovně. Vrchní informativní část zobrazuje, kde byla analýza spuštěna, kdy byla spuštěna a jaké jsou celkové výsledky.
preupgrade-assistant-result_1Druhý obrázek naznačuje detailněji, jak skončily jednotlivé moduly. Které moduly prošly, které nahlásily, že je potřeba je ověřit, apod.

preupgrade-assistant-result_2Jak napsat modul pro preupgrade-assistant

Pokud víme o určité komponentě, že se změnilo API, knihovny či závislosti a rádi bychom informovali uživatele o důležitých změnách, pak stačí napsat modul (content) dle Preupgrade Assistant packaging guidelines.

Řekněme, že balíček mezi Fedorou 22 a 23 je změněn tak, že se změnila struktura databáze, a rádi bychom napsali modul, který toto pokryje a bude uživatele informovat, co má udělat před či po upgradu v případě, že tuto databázi používá.

Check skript pro kontrolu

Check skript by měl zkontrolovat, jestli uživatel používá databázi. Začátek check skriptu musí obsahovat následující řádky:

#!/bin/bash
      . /usr/share/preupgrade/common.sh
      #BEGIN GENERATED SECTION

Preupgrade-assistant zde vloží licenci GPLv2 se jménem autora. Dále by měl skript zkontrolovat, jestli je databáze použita. V případě, že není, tak skončit výstupním kódem $RESULT_NOT_APPLICABLE a v případě že je, tak skončit odpovídajícím návratovým kódem, které byly vysvětleny výše.

Soubor INI pro modul

Struktura souboru INI by měla být následující:

      # cat database.ini
      [preupgrade]
      content_title = "Název modulu, který kontroluje funkcionalitu"
      content_description = "Detailnější popis modulu"
      author = Foo Bar foo@bar.com
      solution = solution.txt
      check_script = check.sh
      applies_to = <RPM_balicek, ktereho se to tyka> # OPTIONAL

Význam jednotlivých položek je:

  • solution.txt - Text, který popisuje, jak se dá po upgradu databáze opravit, aby fungovala i na nové verzi.
  • check_script - skript, který kontroluje databázi
  • applies_to - Název RPM balíku, kterého se to týká. Položka není povinná. V našem případě třeba postgresql či mysql.

Upravení SPEC souboru pro náš balíček

Nyní se pojďme podívat, jak modul distribuovat v rámci balíčku a jaké kroky jsou pro to potřeba. SPEC file by měl obsahovat zdrojové soubory:

    SOURCE1: database.ini
    SOURCE2: check.sh
    SOURCE3: solution.txt

Nový balíček by měl mít jméno podle naming guidelines

    %package -n preupgrade-assistant-%{name}
    Requires: preupgrade-assistant
    BuildRequires: preupgrade-assistant-devel

V sekci prep by mělo být:

    mkdir -p %{preupgrade_name}/%{name}
    cp -a %{SOURCE1} %{SOURCE2} %{SOURCE3} %{preupgrade_name}/%{name}

V sekci build musíme vytvořit XML soubor, který je potřeba pro OpenSCAP:

      %build
      ... snip ...
      %{preupgrade_build} %{preupgrade_name}/%{name}
      ... snip ...

Nyní v sekci install zkopírujeme potřebné soubory do adresáře, ze kterého preupgrade-assistant moduly bere:

      %install
      ... snip ...
      mkdir -p -m 755 $RPM_BUILD_ROOT%{preupgrade_dir}/%{name}
      install -p -m 755 %{SOURCE2} $RPM_BUILD_ROOT%{preupgrade_dir}/%{name}/check.sh
      install -p -m 644 %{SOURCE3} $RPM_BUILD_ROOT%{preupgrade_dir}/%{name}/solution.txt
      install -p -m 644 %{preupgrade_name}-%{preupg_results}/%{name}/group.xml \
            $RPM_BUILD_ROOT%{preupgrade_dir}/%{name}/group.xml
      ... snip ...

A v sekci files přidáme soubory pro modul.

      %files -n preupgrade-assistant-%{name}
      %dir %{preupgrade_dir}/%{name}
      %{preupgrade_dir}/%{name}/*

Reference