abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 4
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 2
dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 1
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 9
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
16.10. 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (15%)
 (2%)
 (0%)
 (2%)
 (71%)
 (11%)
Celkem 55 hlasů
 Komentářů: 3, poslední dnes 20:46
    Rozcestník

    Solaris patchování - opravy nainstalovaných balíčků

    28. 3. 2008 | Ondřej Kubečka | Systém | 3453×

    Solaris používá balíčkovací systém Systemu V release 4 (SVR4), jehož základní principy a postupy byly popsány v článku Tvorba balíčků pro Solaris. Tentokrát vás uvedu do navazující problematiky doručování oprav do nainstalovaných balíčků, tedy patchování.

    Co je to patch

    Podívejme se, co dělá patch patchem:

    • část balíčku (balíčků) doručující opravu
    • systém identifikace patche
    • systém je možné vrátit do stavu před aplikací patche ("backout")

    Od pohledu je zřejmé, že patchování není věc u celé řady systémů běžná a že se jedná o vlastnost, kterou ocení zejména administrátoři. Zajímavá je možnost doručení nezbytného minima pro opravu konkrétní chyby. Ponechání ostatních částí netknutých snižuje rizika, která s sebou do systému přináší každá změna. Neméně důležitá je také možnost v případě selhání patch vyjmout a vrátit systém do původního stavu. SVR4 balíčkovací systém tedy zná dvě základní akce: instalaci balíčku nebo jeho upgrade formou nové verze (tato vlastnost je společná s mnoha jinými balíčkovacími systémy) a doručení opravy do stávajícího balíčku (vlastnost méně obvyklá), včetně správy takto doručených oprav a možnosti návratu zpět.

    Jak to funguje - přehled

    Jak to celé funguje? Patch pro Solaris je část balíčku (sparse package) nebo jejich sada obsahující k doručení pouze změněné objekty. Kromě doručování cílených oprav stojí za touto praxí také historický důvod - snaha ušetřit objem přenášených dat na nezbytné minimum. Balíček totiž může být kompletní a pokud by byly nezměněné objekty zcela identické (tj. nebyly ani překompilovány) s těmi, jež se v systému již nacházejí, byly by během instalace patche ignorovány. Balíčky v patchi se musejí shodovat s těmi, které jsou nainstalované na systému, v názvu, verzi a architektuře.

    Pro každý jeden je pak při běhu patchadd(1M) zavolán pkgadd(1M). Jednotlivé skripty obsažené v balíčcích v sobě nesou základní logiku pro kontrolu, zda-li je možné daný patch aplikovat, i když tento úkol dnes vykonává sám patchadd. Stále je však klíčovou funkcí těchto skriptů připravení a archivace informace potřebné pro návrat k předchozímu stavu - vytvořit tzv. "backout" balíček. Při běhu patchrm(1M) se pak provede pkgadd(1M) "backoutových" balíčků.

    Jak to funguje - podrobně

    Aby bylo zaručeno fungování patche, musejí balíčky obsažené v patchi obsahovat více metadat, než je nezbytné pro běžný SVR4 balíček. Podívejme se na základní rozdíly a rozdělení jednotlivých úkolů.

    pkginfo

    Soubor se musí shodovat s původním balíčkem v hodnotách zapsaných pro PKG, VERSION a ARCH, kterými je jednoznačně identifikována konkrétní verze balíčku. Kromě toho však musí navíc obsahovat definici SUNW_PATCHID pro identifikaci patche. A dále může definovat ještě SUNW_OBSOLETES, SUNW_REQUIRES a SUNW_INCOMPAT, kterými lze upravit vztah k patche k patchům ostatním. Předpona "SUNW_" (odpovídající původnímu symbolu akcií Sunu) je v současné implementaci povinná v této podobě. Důležité je také nezapomenout nastavit správně hodnotu CLASSES (tj. tak, aby obsahovala všechny třídy, které se nacházejí v pkgmap balíčku), aby se nám nestalo, že se instalace některých souborů vůbec nespustí.

    install/checkinstall

    Běžný checkinstall skript kontroluje, zda-li je možné balíček bezpečně nainstalovat, a jako jediný může zcela bezpečně instalaci ukončit. To platí pro patch. V tomto případě však navíc připravuje s patchem související hodnoty pro soubor pkginfo a ukládá je do souboru odpovědí ("response file"), tj. souboru, jehož jméno bylo předáno v prvním parametru a který je následně načítán před spuštěním ostatních skriptů během instalace.

    Tento skript se při instalaci patche spouští dvakrát. Nejprve proběhnou checkinstall skripty ze všech balíčků (tzv. dryrun) a potom je spouštěn jako běžná součást průběhu pkgadd(1M).

    install/preinstall

    Připraví strukturu "backout" balíčku a zaplní jej příslušnými metadaty. Obsah adresáře install/ tohoto balíčku je vytvořen ze skriptů obsažených v patchi, které mají buď předponu "patch_" nebo "u.", a to tak, že předpona "patch_" je odstraněna a metadata přenesena do "backout" balíčku. U skriptů pojmenovaných "u.*" je předpona nahrazena "i." a jsou použity jako instalační (class action) skripty.

    Kromě této základní struktury se v preinstall skriptu také ukládají informace o všech nesouborových objektech doručovaných daným patchem (jako linky, pojmenované roury, soubory zařízení), pro jejichž doručení se nespouští žádný další (class action) skript, ale jsou vytvářeny přímo programem pkgadd(1M).

    install/i.* (class action skripty)

    Stejně jako v běžném balíčku jsou právě tyto skripty zodpovědné za doručení vlastního obsahu do souborového systému. Kromě toho o každém doručovaném souboru pořizují záznam do "backout" balíčku. Tzn. pokud objekt před doručením v systému existoval, uchovají jeho kopii. Pokud je nově instalován, je označen k odstranění při případném odinstalování patche.

    install/postinstall

    postinstall skript zpracuje soubor deletes, pokud jej metadata balíčku v patchi obsahují. Tedy uchová kopii pro odinstalování patche. V databázi systému jej odstraní z vlastnictví příslušného balíčku a pokud po této akci žádnému dalšímu balíčku nepatří, smaže jej ze souborového systému.

    Druhým úkolem tohoto skriptu je vytvořit vlastní "backout" balíček na základě dosud posbíraných dat. Takto rozvržené pořadí činností je také důvodem, proč je důležité, aby skripty v patchi po proběhnutí checkinstall neukončily činnost s nenulovou návratovou hodnotou, dokud neměl postinstall šanci skončit s výrobou dat pro návrat k původnímu stavu, aby i v případě selhání byla zajištěna možnost odstranění změn.

    install/patch_checkisntall

    Jak jsme si již ukázali, metadata "backout" balíčku jsou zajištěna pomocí skriptů s předponou "patch_" a "u.". Také odstraněni patche (tedy vlastně instalace "backout" balíčku) vyžaduje provedení některých činností.

    patch_checkinstall má dle očekávání za úkol zkontrolovat, že patch lze bezpečně odstranit. Tedy zejména, že již nebyl nainstalován stejný patch vyšší revize. Kromě toho (podobně jako protějšek při instalaci patche) připravuje související pkginfo data.

    install/u.* ("class action" skripty)

    Zajišťuje doručení objektů patřících příslušné třídě uložených v "backout" balíčku.

    install/patch_postinstall

    Podobně jako při instalaci patche patch_postinstall zajišťuje zpracování souboru deletes, tj. odstraní záznam o vlastnictví objektu, případně jej smaže úplně, pokud se k němu nehlásí žádný další balíček. Kromě toho pak patch_postinstall zajišťuje smazání dat uložených pro odinstalování patche.

    Poznámka ke skriptům: Bohužel, vzhledem k tomu, že Solaris Express a OpenSolaris běžně patche nepoužívají, tak konkrétní implementace těchto skriptů, ač veřejně přístupná v každém patchi, nebyla dosud uvolněna pod žádnou ze svobodných licencí. Jejich starší verze však byla v plné podobě zveřejněna a doporučena v dokumentu "Application Packaging Developer's Guide". Tato jejich podoba je také v přiloženém archívu.

    Ostatní specifika

    Kromě odlišnosti na úrovni jednotlivých balíčku musí každý patch ve svém kořenovém adresáři obsahovat soubor .diPatch, který signalizuje, že se jedná o "direct instance" patch. Tento typ patchů, jenž spočívá v zachování verze (instance) balíčku během patchování, se v Solarisu používá od verze 2.5, kdy nahradil starší model progresivního patchování zvyšujícího při aplikaci patche verzi balíčku nainstalovaného na systému.

    Ve svém kořenovém adresáři by měl patch obsahovat také soubor README.<číslo_patche> a volitelně může obsahovat metadata patche používaná nástroji pro automatizaci v podobě souboru patchinfo.

    Nakonec může mít speciální patch skripty prepatch, postpatch, prebackout a postbackout, které se spouštějí před a po instalaci nebo odstranění patche. Jejich použití je však rozumné se vyhnout. Toto řešení totiž nedostatečně škáluje v prostředí, kde je potřeba vyrábět a spravovat velké množství patchů. A na rozdíl od skriptů v balíčcích je potřeba doplnit logiku, která zajistí provedení akce pouze ve správném kontextu při různých scénářích instalace.

    Když je patchů více

    Pro vzájemné vztahy mezi patchi existuje několik jednoduchých pravidel. Patche jsou kumulativní. Tzn. každá nová revize obsahuje nové opravy a opravy všech revizí předchozích.

    Jeden soubor typu "f" nesmí být současně doručován více než jedním patchem. Pokud má nový patch doručovat "f" objekt již obsažený v patchi jiném, musí nový patch ten původní buď nahradit (SUNW_OBSOLETES), nebo na něm záviset (SUNW_REQUIRES), aby bylo zajištěno, že nedojde k regresi daného souboru nesprávným pořadím instalace patchů. Nová revize patche je chápána jako implicitní nahrazení revize předchozí - nástroje na instalaci patchů proto neumožní nainstalovat starší revizi přes novější.

    Kruhové závislosti jsou nepřípustné. Tedy nelze nastavit závislosti dvou nebo více patchů tak, aby se pro instalaci vyžadovaly navzájem.

    Přílohy

    šablony skriptů (tar.gz)
    LAB (tar.gz)

           

    Hodnocení: 75 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    stativ avatar 28.3.2008 17:35 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Solaris patchování - opravy nainstalovaných balíčků
    Jo, patche balíčků jsou geniální věc a Solaris to má opravdu dotaženo do dokonalosti, ale také se vám zdá, že instalace patche je pomalejší než instalace balíčku?
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    1.4.2008 11:28 Jan Horak
    Rozbalit Rozbalit vše Re: Solaris patchování - opravy nainstalovaných balíčků
    Nesrovnatelne pomalejsi - instalace asi tak 25 patchu mi trve dele nez 90 minut a z toho je 99% casu vytvereni stromu patchu a kontrola zavislosti coz je dost spatny.

    A o dokonalosti bych ani nemluvil, protoze patche nelze odinstalovavat. Teda ono to jde, ale znicite si tim system, bohuzel - a navic je idinstalovani patche nepodporovana akce.
    1.4.2008 15:27 Milan Jurik | skóre: 21 | blog: Komentare | Ova
    Rozbalit Rozbalit vše Re: Solaris patchování - opravy nainstalovaných balíčků
    A o dokonalosti bych ani nemluvil, protoze patche nelze odinstalovavat. Teda ono to jde, ale znicite si tim system, bohuzel - a navic je idinstalovani patche nepodporovana akce.
    FUD? Uved cislo patche, ktery ti po backoutu znicil system. A taktez support kontakt, ktery uvedl, ze patch backout neni podporovana akce, aby byl briskne poslan na skoleni.
    1.4.2008 21:13 Tomáš Dzik
    Rozbalit Rozbalit vše Re: Solaris patchování - opravy nainstalovaných balíčků
    S tím nemůžu souhlasit. Odinstalování patche je podporovaná a testovaná operace, pokud ovšem není v README patche v sekci Special instructions uvedeno něco jiného. (Například tam mohou být uvedené zvláštní kroky, které je třeba provést po, případně před odinstalováním patche, nebo požadavek, aby byl systém při instalaci, nebo odebírání patche v single-user modu apod.) Opravdu by mě zajímalo, který patch vám zničil systém a jak, rád bych se na ten dotyčný patch podíval.
    2.4.2008 15:43 Jan Horak
    Rozbalit Rozbalit vše Re: Solaris patchování - opravy nainstalovaných balíčků
    Dobry den, zrejme jsem vas pobouril, ale to rozhodne nebylo mym umyslem pouze jsem se nechal unest moji spatnou zkusenosti s instalaci patchu (predevsim dobou instalace).

    Rad bych tedy neco dodal:

    - patche jsou potrebne - na solarisu jsou bohuzel hodne moc pomale (opravdu hodne pomale)

    Co se tyka onoho supportu, tak mi to nikdo nerekl, ale nekde jsem to cetl jenze uz je to davno, tak vam bohuzel nepovim kde a je klidne mozne, ze se jednalo pouze o jeden zminovany patch, ktery se nesmi odinstalovat, ale nanestesti jsem si to zapamatoval jako obecne pravidlo - proste opravdu nevim a takhle mi to utkvelo v pameti. Kazdopadne dekuji za opravu.

    A ktery ze patch mi znicil system? I to uz je davno, ale nasel jsem jeste zapisky, takze ani to neni jiste, ale skoncil jsem nekde u odebirani patchu 125100-05 a 125075-01.

    Pred nimi jsem ovsem odebral jeste dalsi vetsi mnozstvi patchu:

    125166-02 119130-33 120222-16 119974-07 120182-05 120346-07 120348-02

    a nasledne jeste

    124250-03 121132-02 125427-01 125424-01 125329-02 125120-01 125116-01 125100-05 125075-01 - zde me poznamky konci, takze jeden z techto poslednich dvou patchu zpusobil nefunkcnost systemu (ovsem mozna az po nalsednem rebootu)

    Ovsem jelikoz jsem to zkousel jiz hodne davno, tak opravdu nevim jestli to bylo pri tomhle pokusu, nebo pri nejakem jinem, ale bylo to nejspis pri tomhle.

    Doufam, ze se mi timto podarilo tento neumyslny flame uzavrit a uvest na pravou miru co jsem chtel a take mel puvodne rici.

    S pozdravem, Jan Horak.
    2.4.2008 23:07 Milan Jurik | skóre: 21 | blog: Komentare | Ova
    Rozbalit Rozbalit vše Re: Solaris patchování - opravy nainstalovaných balíčků
    Dobry den, zrejme jsem vas pobouril, ale to rozhodne nebylo mym umyslem pouze jsem se nechal unest moji spatnou zkusenosti s instalaci patchu (predevsim dobou instalace).

    Rad bych tedy neco dodal:

    - patche jsou potrebne - na solarisu jsou bohuzel hodne moc pomale (opravdu hodne pomale)
    Doba instalace je dana designem, na kterem by slo asi kde co zlepsit... Vzdy bude pomalejsi nez instalace balicku stejne velikosti, protoze patch musi toho vykonat prece jen o neco vice.
    Co se tyka onoho supportu, tak mi to nikdo nerekl, ale nekde jsem to cetl jenze uz je to davno, tak vam bohuzel nepovim kde a je klidne mozne, ze se jednalo pouze o jeden zminovany patch, ktery se nesmi odinstalovat, ale nanestesti jsem si to zapamatoval jako obecne pravidlo - proste opravdu nevim a takhle mi to utkvelo v pameti. Kazdopadne dekuji za opravu.
    Samozrejme si nepamatuju celou historii Solarisich patchu, takze nepochybne mohly existovat patche, ktere nelze backoutovat, ale spise to budou patche, ktere se nedoporucuje backoutovat. Obecne je kazdy patch opakovane testovan na instalaci a backout pred svym uvolnenim.
    A ktery ze patch mi znicil system? I to uz je davno, ale nasel jsem jeste zapisky, takze ani to neni jiste, ale skoncil jsem nekde u odebirani patchu 125100-05 a 125075-01.

    Pred nimi jsem ovsem odebral jeste dalsi vetsi mnozstvi patchu:

    125166-02 119130-33 120222-16 119974-07 120182-05 120346-07 120348-02

    a nasledne jeste

    124250-03 121132-02 125427-01 125424-01 125329-02 125120-01 125116-01 125100-05 125075-01 - zde me poznamky konci, takze jeden z techto poslednich dvou patchu zpusobil nefunkcnost systemu (ovsem mozna az po nalsednem rebootu)

    Koukam, ze jste tehdy pekne rezal do systemu :-)

    Kouknul jsem se na ty patche, podle toho, o ktere se jedna, tak bych si tipnul na ten predposledni.
    Ovsem jelikoz jsem to zkousel jiz hodne davno, tak opravdu nevim jestli to bylo pri tomhle pokusu, nebo pri nejakem jinem, ale bylo to nejspis pri tomhle.
    Vzpomenete si na to, v jakem stavu ten system byl? Co presne znaci "znicil system"? Pri tomhle mnozstvi backoutovanych patchu je treba postupovat hodne pomalu zpet a pokud neco takoveho potrebujete delat vicekrat, zvazil bych spise uzivani live upgrade/patching.
    Doufam, ze se mi timto podarilo tento neumyslny flame uzavrit a uvest na pravou miru co jsem chtel a take mel puvodne rici.

    S pozdravem, Jan Horak.
    Nepovazuji to za flame, ocenuji vase informace. Skoda, ze jste to tehdy neeskaloval na support, protoze backout patche, pokud postupujete podle README (u backoutu vyrazne doporucuji, je to delikatnejsi operace), je opravdu podporovanou veci a nefunguje-li, mel by jste Sun nedecentne upozornit.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.