Solaris 10 Inactive Boot Environment PCA patchelés Zónákkal

Sajnos a Solaris 10 patchelése elég nehézkesnek mondható. Főleg, ha egy Linuxal akarjuk összehasonlítani. Ez persze a Solaris 10 repository alapú csomag és patchkezeléséhez vezethető vissza. Ezt pedig szinte teljesen tökéletesen megoldottak a Solaris 11-ben. Az Oracle (és régebben a SUN is) belátta, hogy ez ellen tenni kell valamit, és olyan fajta egyszerűen kezelhető, automatikus funkciókat kell kínálni a Solaris 10 adminisztrátoroknak, amivel nem lesz horror a patchelés. Ez pedig már régóta elérhető a Live Upgrade formájában. Nekem viszont úgy tűnik, hogy nem merjük arra használni a Live Upgrade-t, amire való. Talán azért mert félünk tőle, talán azért, mert nem is értjük mikre lehet jó. Én ebben a cikkben azt kívánom bemutatni, hogy szerintem mi az ideális Solaris 10 patchelési módszer.

A Tradicionális módszer

Természetesen a Tradicionális és az én általam bemutatott verziók között lehet megannyi köztes forma is. Ahhoz, hogy ki tudjam hangsúlyozni az előnyöket, és hátrányokat, ahhoz ezt az alap koncepciót fogom alapul venni. Természetesen mindenki levonhatja belőle a tanulságot, és alkalmazhatja azt a saját rendszereire.

– SVM tükör Global Zone root filesystem alatt
– Adhoc vagy legutoljára kiadott Recommended Patchset alkalmazása
– Zónák paralell patchelése (hivatalos ajánlás) vagy játék a Zónák update on patchingjével
– Nincs failback plan hiba esetén, jobb esetben a tükrök szétválasztása

Inative Boot Environment with PCA script

Az egyetlen igazán rendszerszintű elvárás ehhez a folyamathoz az az, hogy a rendszer legyen legalább Solaris 10 update 8 (10/09) és ZFS alapú filesystem-en fusson az OS. Ez szükséges ahhoz, hogy a Live Upgrade elérhető legyen, és az általam bemutatott módon tudjon működni. Külön nem kívánok a Live Upgrade előnyébe és működésébe belemenni mélyebben. Akit mégis érdekelne, annak ajánlom a Live Upgrade írást. Az ötlet a következő:

1, Készítsünk egy új Boot Environment-et.
2, Mountoljuk fel az új Boot Environment adatait.
3, Patcheljük meg az inaktív, de felmountolt-t rendszert a PCA script által felkínált patchekkel.
4, Mountoljuk le megpatchelt, inaktív Boot Environment-et.
5, Aktiváljuk az új Boot Environmentet.
6, Indítsuk újra a rendszert.

Failback Method – Visszaállási metódus

1, Aktiváljuk a régi Boot Environment-et.
2, Indítsuk újra a gépet.

Egyszerűnek tűnik? Mert az is!

Összehasonlítás

A tradicionális esetben, főleg Live Upgrade használata nélkül iszonyat mennyiségű parancsot kell kiadnunk, és sok esetben konfigurációs állományokat is kell szerkeszteni. A tradicionális esetben már az előkészítés alatt illő lekapcsolni minden futó szolgáltatást. Így az egész folyamat leállással jár. Míg az én módszeremmel csupán egy újraindulásnyi idő a leállás és szinte minden patchelési lépés elvégezhető a rendszer produktív működése mellett. A PCA script minden számunkra fontos patch-et fel fog installálni, így visszamenőleg nem kell izgulnunk, hogy valami kimaradt. Illetve fontos megemlíteni, hogy míg a Tradicionális esetben a Zónák csak plusz időt és nyűgöt jelentenek (főleg cluster-ben). Az új fajta módszer segítségével gyorsabban, és minden féle újraindítás, vagy alkalmazáskiesés mellett patchelhetjük meg a Global Zone-t, és az összes rajta futó local zone-t is.

A ronda csíkok a saját teszt rendszeremen bemutatott méréseken alapszik. Szerintem elég meggyőzők az ábrák, de nézzük magát a folyamatot.

Patch Check Advanced (PCA)

Mielőtt az egész folyamatot ismertetném, először ismerkedjünk meg a PCA-val, ami egy fontos komponense lesz az egész folyamatnak. A Patch Check Advanced (PCA) egy nyílt forráskódú, egyszerű script, amit Martin Paul tart karban. A script maga egy patchdiag.xref referencia file alapján dolgozik, amit a közösség az Oracle információi alapján ad ki rendszeresen. Ez a file tartalmazza az összes elérhető patchet, azok architektúra és azon információt, hogy melyik patch teszi melyik patch-et elavulttá. Tehát a script nem csinál mást, mint összehasonlítja a patchdiag.xref és a gépünkön elérhető patcheket, és ezáltal létre tud hozni egy konkrét listát, milyen patchek hiányoznak a rendszerünkről. Természetesen képes listázni, letölteni a patcheket és installálni is azokat.

Először is töltsük le a scriptet a hivatalos oldalról, http://www.par.univie.ac.at/solaris/pca/

A script egy normál Shell script, ami némi perl elemet is tartalmaz. Ennek ellenére, csak olyan dologokat használ a script, ami egy alap Solaris telepítés során alapból elérhető a rendszeren. Tehát amint létrehoztuk a scriptet a rendszerünkön, máris használhatjuk.

root@testsystem # ./pca -l missing

A -l kapcsolót használhatjuk a listázásra. Majd utána egy kulcsszót megadva, hogy miket is listázzon. missing, installed, all, total, unbundled, bad. Értelemszerűen én a hiányzó (missing) patcheket fogom listázni.

A -d kapcsolóval tölthetjük le a patcheket, a -i pedig letölti és installálja is a rendszerre. Természetesen a script ennél sokkal többet is tud. A teljes helpje elérhető a -h kapcsolóval.

Usage: /usr/sbin/pca [OPTION] .. [OPERAND] ..

Operands:
  patch group:    missing, installed, all, total, unbundled, bad
                  Add r, s or rs at the end to list Recommended,
                  Security or Recommended/Security patches only.
  patch ID:       123456, 123456-78
  patch file:     123456-78.zip, 123456-78.jar, 123456-78.tar.Z
  file name:      patchlist.txt

Options:

  -l, --list           List patches
  -L, --listhtml       List patches, produce HTML output
  -d, --download       Download patches
  -i, --install        Install patches
  -I, --pretend        Pretend to install patches
  -r, --readme         Display patch READMEs
  -u, --unzip          Unzip patches
  -x, --getxref        Download patch xref file
  -X, --xrefdir=DIR    Location of patch xref file
  -y, --nocheckxref    Do not check for updated patch xref file
      --xrefown        Give write permissions on xref file to user only
      --nocache        Tell proxy to not cache xref file
  -P, --patchdir=DIR   Patch download directory
      --user=USER      My Oracle Support (MOS) user name
      --passwd=PASS    My Oracle Support (MOS) password
      --patchurl=URL   Source for patches and READMEs (URLs or "oracle")
      --xrefurl=URL    Source for patchdiag.xref (URLs or "oracle")
      --stop=ID        Stop after patch ID
      --ignore=WHAT    Ignore patches whose ID or synopsis match WHAT
      --rec=ID         Set Recommended flag on patch ID
      --sec=ID         Set Security flag on patch ID
  -p, --pattern=REGEX  List only patches whose synopsis matches REGEX
  -n, --noreboot       Install only patches which do not require a reboot
      --minage=DAYS    List only patches which are at least DAYS old
      --maxage=DAYS    List only patches which are at most DAYS old
      --nodep          Do not resolve patch dependencies
      --minimal        Use minimal revision for recommended patches
      --syslog=TYPE    Log patch installs to syslog priority TYPE
  -k, --nobackup=ID    Do not back up files to be patched for patch ID
  -B, --backdir=DIR    Saves patch backout data to DIR
  -s, --safe           Check locally modified files for safe patch installation
  -G, --currentzone    Make patchadd install patches in the current zone only
      --patchadd=FILE  Path to patchadd command
  -H, --noheader       Don't display descriptive headers
      --format=FORMAT  Set output format to FORMAT
  -f, --fromfiles=DIR  Read uname/showrev/pkginfo output from files in DIR
      --dltries=NUM    Try downloads from Oracle download server NUM times
  -F, --force          Force local caching proxy to download from Oracle server
  -R, --root=DIR       Alternative root directory
      --wget=FILE      Path to wget command
      --wgetproxy=URL  Default proxy for wget
      --wgetopt=OPT    Feed option OPT directly to wget
      --logger=FILE    Path to logger command
  -t, --threads=NUM    Use NUM download threads (DISABLED, Perl lacks ithreads)
      --update=TYPE    Update pca (TYPE is never, check, now or auto)
      --pcaurl=URL     URL for pca update
      --ohost=HOST     HOST name or IP address for Oracle patch server
      --norootchk      Skip check for root user with safe/install options
      --cffile=FILE    Read FILE as additional configuration file
  -V, --debug          Print debug information
  -h, --help           Display this help
  -m, --man            Display manual page
  -v, --version        Display version information

PCA proxy

A PCA script alap esetben képes használni az Oracle felhasználó nevünket és annak jelszavát (–user and –passwd), hogy a szükséges patch-eket direktbe az Oracle oldaláról letöltse. Amennyiben viszont nem néhány gépet használunk, úgy érdemes lehet helyi hálózatban egy Patch Server-t beállítanunk, ami letölti a patch-eket és azt már csak helyi hálózaton belül szolgálja ki a többi kliensnek.

Ilyen PCA proxy server-t egyszerűen összeüthetünk, ugyanis a PCA bináris tartalmazza alapból a proxy funkciót. Nincs más dolgunk, mint egy webszerver cgi-bin könyvtárába tesszük, majd beállítjuk a proxy konfigurációs állományát.

Én egy Solaris 10 rendszert fogok használni a Patch Server elkészítéséhez. Először is készítsük el azt a könyvtárat, ahol a patch-eket tárolni fogjuk.

root@patchserver # mkdir /patch
root@patchserver # chown webservd:webservd /patch

Másoljuk a PCA scriptet pca-proxy.cgi néven a megfelelő helyre. Majd hozzuk létre a konfigurációs állományt az /etc alá. Ebben meg kell adnunk a patch-ek helyét, a patchdiag.xref helyét, plusz hogy a proxy milyen ORACLE felhasználóval próbálja meg letölteni a patch-eket.

root@patchserver # cd /var/apache2/cgi-bin
root@patchserver # cp /usr/sbin/pca pca-proxy.cgi
root@patchserver # chmod 555 pca-proxy.cgi
root@patchserver # vi /etc/pca-proxy.conf
     xrefdir=/patch
     patchdir=/patch
     user=oracle_user@akarmi.hu
     passwd=nagyontitkosjelszo

root@patchserver  # chown webservd:webservd /etc/pca-proxy.conf
root@patchserver  # chmod 600 /etc/pca-proxy.conf

Ezek után bizonyosodjunk meg, hogy az apache-hoz megfelelően be van állítva a cgi-bin és kapcsoljuk be a webservice-t.

root@patchserver # vi /etc/apache2/httpd.conf
root@patchserver # svcadm enable svc:/network/http:apache2

Amennyiben a gépünk direktbe nem lát ki az internetre, abban az esetben a rendszerünkön konfigurálni kell a WEB PROXY szervert is. A PCA-PROXY a wget-et használja a csomagok letöltéséhez. Tehát az /etc/wgetrc file-t érdemes a következő módon beállítani.

root@patchserver # vi /etc/wgetrc
https_proxy = http://proxy.host.name:8080/
http_proxy = http://proxy.host.name:8080/
ftp_proxy = http://proxy.host.name:8080/

proxy_user=proxyuser
proxy_password=proxypassword

use_proxy = on

Amennyiben a /etc/pca-proxy.conf file-ba beletesszük a következő bejegyzést is:

debug=1

Akkor automatikusan létrehozza a /var/tmp/pca-proxy-debug.txt file-t, és minden részletes információt bele fog vezetni ebbe a log file-ba.

root@patchserver # less /var/tmp/pca-proxy-debug.txt 

A PCA klienseken érdemes létrehozni egy konfigurációs állományt, amiben eltároljuk a patch szerverünk elérhetőségét. Így azt nem kell mindig paraméterként beírnunk.

root@testsystem # vi /etc/pca.conf
          xrefurl=http://patchserver.hostname.hu:8080/cgi-bin/pca-proxy.cgi
          patchurl=http://patchserver.hostname.hu:8080/cgi-bin/pca-proxy.cgi

Ezek után a patchelendő szervereken ha a PCA-t használjuk, akkor automatikusan, a /etc/pca.conf-ból vett információk alapján a saját patch szerverünkhöz fog fordulni a gép. Ha a Patch Server saját /patch könyvtárában megtalálható a patch, akkor onnan fogja kiszolgálni a kéréseket. Ha nem található a kért patch, akkor a beállított WEB PROXY-n keresztül a patch server letölti az Oracle-től, eltárolja lokálisan majd kiszolgálja a kérést. Ezek után már az eltárolt file-t, lokálisan fogja mindig kiszolgálni, és természetesen ebből a kliensek semmit nem vesznek észre.

Most már megvan az infrastruktúra is a patcheléshez, nézzük akkor a folyamatot.

Inactive Boot Environment patch with Zones by PCA script

Egy Solaris 10-es rendszeren fogom bemutatni a folyamatot, amin három zóna is fut.

Lefuttattam a Global Zone-n és a local zone-kon is a PCA scriptet, és ugyan azok a patchek hiányoztak értelemszerűen mindenhonnan.

Készítsünk egy új Boot Environment-et a futó rendszerről. Az én esetemben patch-nek fogják hívni az új Boot Environmentet, de bármit megadhatunk.

root@testsystem # lucreate -n patch

Nézzük meg, mi is jött ezáltal létre:

root@testsystem #  lustatus
root@testsystem #  zfs list
root@testsystem #  lumount

Ahogy a fenti képen is látszik, egy új Boot Environment jött létre, de továbbra is az eredeti, még továbbra is produktívan működő az aktuális. Most csatoljuk fel az inaktív Boot Environment-et.

root@testsystem # lumount patch

Ahogy látszik az inaktív Boot Environment adatai, zónákkal együtt elérhetőek lettek egy alternatív mountpoint-on. Most hívjuk meg a PCA scriptet, de adjuk meg, hogy ne az aktív rendszert, hanem ezt az alternatív, felmountolt Boot Environmentet patchelje meg.

root@testsystem # pca -i -R /.alt.patch

Ahogy látszik a patchelés szépen egyesével fog haladni. Pirossal jeleztem, hogy az aktuális patch installálása mikor ért véget. Zöldel, hogy az a patch mennyi ideig tartott, és kékkel, hogy az egész patchelés odáig meddig tartott. Természetesen mivel az inaktív Boot Environmentet patcheljük, ezért a rendszerünk továbbra is működik, és nincs semmilyen szolgáltatás kiesésünk. A művelet befejeztével le kell csatolnunk a felmountolt Boot Environmentet.

root@testsystem # luumount patch

Majd aktiváljuk az új Boot Environmentet. Ezzel csak annyit teszünk, hogy újraindítást követően ez az új Boot Environment fog elindulni és nem az amiben most vagyunk.

root@testsystem #  luactivate patch

A végén pedig indítsuk újra a rendszert. Ekkor lesz az első igazi szolgáltatás kiesésünk, ez viszont csupán a normál újraindulásig fog fennállni.

Ellenőrzés Patch után

Miután a rendszerünk újra elindult, természetesen illő ellenőrizni, hogy mit is kaptunk vissza.

root@testsystem # lustatus
root@testsystem # lumount

Ahogy látszik a fenti képen, most már a patch nevű Boot Environment az aktív. A zónák újra futnak:

Végül nézzük a PCA script segítségével a hiányzó patcheket.

root@testsystem # pca -l missing
root@testsystem # zlogin test1 pca -l missing
root@testsystem # zlogin test2 pca -l missing
root@testsystem # zlogin test3 pca -l missing

Ahogy látszik, az új Boot Environmentből nem hiányzik egyetlen patch sem. Tehát egyetlen újraindulásnyi szolgáltatás kieséssel megpatcheltük a Global Zone-t és a három Local Zone-t az adott rendszeren.

Failback – visszaállás

Minden adminisztrátor rémálma, de sajnos előfordulhat, ha egy patchelés után mégis vissza kell állni az eredeti állapotra. A fenti folyamat esetében ez pofon egyszerű. Elengedő ugyanis aktiválni az erdeti Boot Environment-et, és újraindítani a gépet.

root@testsystem #  luactivate 10u11_X86

root@testsystem # init 6

Ezt követően megint az eredeti állapotot fogjuk látni:

root@testsystem # lustatus
root@testsystem # lumoun

Természetesen a hiányzó patchek itt nem lesznek telepítve.

root@testsystem # pca -l missing

Összegzés

Az új módszer hihetetlen egyszerűen kezelhető. Szimpla parancsokkal kell operálni, a többit pedig a Solaris automatizációjára kell bízni. A PCA script által hihetetlen rugalmasságot érhetünk el. Illetve az Inaktív Boot Environment patchelésével teljesen minimalizálhatjuk a kiesésünket. Sajnos meg kell említenem az árny oldalát is a folyamatnak. A Boot Environmentek elkészülése (vagy törlése) sokszor hibára fut. Ekkor természetesen nem történik szolgáltatás kiesés, csupán megakadunk a patcheléssel. Egyik tipikus probléma, hogy INSTALLED állapotú zónák vannak az /etc/zone/index file-ban, amit a Live Upgrade megrpbálni elindítani. Ezért illő a folyamat előtt kitakarítani az /etc/zone/index file-t. Minden zóna, amit nem akarunk futtatni az legyen lecsatolva, és configured állapotban. Erre írtam egy rövid scriptet.

root@testsystem # awk -F: '$0~/installed/ {print $1" "$3}' < /etc/zones/index | grep -v global | while read zone path; do if [ ! -d "${path}/root/etc" ]; then perl -i -pe "s|$zone:installed|$zone:configured|g" /etc/zones/index; fi; done

Sajnos ezen túl is sok hibába futok bele, ennek ellenére továbbra is ezt a folyamatot tartom a leginkább hatásosabbnak Solaris 10 rendszerek patchelésére.