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í
×

včera 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ářů: 0
včera 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ářů: 0
včera 22:04 | Pozvánky

Rádi bychom vás pozvali na přednášku o frameworku Avocado. Jedná se o testovací framework další generace, inspirovaný Autotestem a moderními vývojovými nástroji, jako je třeba git. Přednáška se bude konat 23. října od 17 hodin na FEL ČVUT (Karlovo náměstí, budova E, auditorium K9 – KN:E 301). Více informací na Facebooku.

… více »
mjedlick | Komentářů: 0
včera 21:44 | Bezpečnostní upozornění

Nový útok na WPA2 se nazývá KRACK a postihuje prakticky všechna Wi-Fi zařízení / operační systémy. Využívá manipulace s úvodním handshake. Chyba by měla být softwarově opravitelná, je nutné nainstalovat záplaty operačních systémů a aktualizovat firmware zařízení (až budou). Mezitím je doporučeno používat HTTPS a VPN jako další stupeň ochrany.

Václav HFechs Švirga | Komentářů: 0
15.10. 00:11 | Zajímavý projekt

Server Hackaday představuje projekt RainMan 2.0, aneb jak naučit Raspberry Pi 3 s kamerovým modulem pomocí Pythonu a knihovny pro rozpoznávání obrazu OpenCV hrát karetní hru Blackjack. Ukázka rozpoznávání karet na YouTube. Zdrojové kódy jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 0
14.10. 15:11 | IT novinky

Online obchod s počítačovými hrami a elektronickými knihami Humble Bundle byl koupen společností IGN. Dle oficiálních prohlášení by měl Humble Bundle dále fungovat stejně jako dosud.

Ladislav Hagara | Komentářů: 7
14.10. 06:00 | Zajímavý článek

Brendan Gregg již v roce 2008 upozornil (YouTube), že na pevné disky se nemá křičet, že jim to nedělá dobře. Plotny disku se mohou rozkmitat a tím se mohou prodloužit časy odezvy pevného disku. V září letošního roku proběhla v Buenos Aires konference věnovaná počítačové bezpečnosti ekoparty. Alfredo Ortega zde demonstroval (YouTube, pdf), že díky tomu lze pevný disk použít také jako nekvalitní mikrofon. Stačí přesně měřit časy odezvy

… více »
Ladislav Hagara | Komentářů: 7
13.10. 14:33 | Komunita

Společnost SUSE natočila a na YouTube zveřejnila dva nové videoklipy: 25 Years - SUSE Music Video (7 Years parody) a Linus Said - Music Parody (Momma Said).

Ladislav Hagara | Komentářů: 6
13.10. 12:55 | Zajímavý projekt

Autoři stránky Open Source Game Clones se snaží na jednom místě shromažďovat informace o open source klonech proprietárních počítačových her. Přidat další hry nebo návrhy na zlepšení lze na GitHubu. Na stránce Open Source Text Games jsou shromažďovány informace o open source textových hrách. Opět lze k vylepšení nebo doplnění stránky použít GitHub.

Ladislav Hagara | Komentářů: 1
12.10. 20:44 | Nová verze

Po 18 měsících vývoje od vydání verze 2.3 byla oficiálně vydána nová verze 2.4 firewallové distribuce pfSense, fork již nevyvíjeného m0n0wall, která je postavená na základech FreeBSD 11.1. Přehled novinek v poznámkách k vydání. Zdůraznit lze ukončení podpory dvaatřicetibitové i386 architektury.

Ladislav Hagara | Komentářů: 0
Těžíte nějakou kryptoměnu?
 (6%)
 (2%)
 (15%)
 (76%)
Celkem 717 hlasů
 Komentářů: 24, poslední 27.9. 08:30
    Rozcestník

    OBS - 3 (backportujeme kernel a další balíčky)

    2. 7. 2008 | Marek Stopka | Návody | 2243×

    Pokud chcete dostat do své verze distribuce novější jádro, které ještě není v repozitáři, bude se vám hodit umět s pomocí openSUSE Build Service backportovat. Kromě toho se naučíte obyčejné patchování balíčků.

    openSUSE (a pokud vím i všechny ostatní RPM-based distribuce) fungují na principu stabilních vydání, a ne na principu rolling-updates, jako je tomu třeba v případě Gentoo. Proto, když chcete novou verzi nějakého programu (třeba jádra), tak musíte buď přejít na aktuální vývojovou verzi (např. openSUSE Factory), nebo si patřičný balíček backportovat. (Je zde ještě možnost si program zkompilovat mimo balíčkovací systém, ale to je spíš cesta do pekel než elegantní řešení problému.)

    S buildservicem však není nic snažšího, než si takový balíček (třeba jádro jako v našem případě) backportovat. Můžete provádět rozličné backportování. Můžete si do svého openSUSE 10.3 naládovat jádro z openSUSE 11.0 nebo přímo z openSUSE Factory. Například jsem pořeboval na desktop HP dc5800 dát novější jádro, aby mi správně fungovalo ACPI. S buildservicem stačilo vytvořit nový projekt home:m4r3k:kernel-backport (je zbytečné si zaneřádit domácí projekt, když je tu ta skvělá možnost vytvářet podprojekty) pomocí příkazu:

    osc meta prj -e home:m4r3k:kernel-backport

    V nabídnutém XML souboru:

    <project name="home:m4r3k:kernel-backport">
    	 <title>Short title of NewProject</title>
      <description>This project aims at providing some foo and bar.
    It also does some weird stuff.
    </description>
      <person role="maintainer" userid="m4r3k" />
      <person role="bugowner" userid="m4r3k" />
    <!– remove this block to publish your packages on the mirrors –>
      <publish>
        <disable />
      </publish>
      <build>
        <enable />
      </build>
      <debuginfo>
        <disable />
      </debuginfo>
    <!– remove this comment to enable one or more build targets
      <repository name="openSUSE_Factory">
        <path project="openSUSE:Factory" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
     <repository name="openSUSE_10.2">
        <path project="openSUSE:10.2" repository="standard"/>
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
      <repository name="SUSE_Linux_10.1">
        <path project="SUSE:SL-10.1" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
      <repository name="SUSE_Linux_10.0">
        <path project="SUSE:SL-10.0" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
      <repository name="Fedora_7">
        <path project="Fedora:7" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
      <repository name="SLE_10">
        <path project="SUSE:SLE-10:SDK" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
    –>
    </project>

    Pak pozměníme část <publish> z <disable /> na <enable />, čímž zajistíme vytvoření veřejně přístupného repozitáře, a dále si vybereme architektury a distribuce, pro které chceme balíčky sestavovat. Pokud je naše cílová platforma v zakomentované části XML souboru, tak máme vyhráno a tu část, kterou chceme, odkomentujeme. Ke komentářům se zde používají klasické XML komentářové znaky <!– a –>. V případě, že naše cílová platforma v nabídce není, tak ji prostě přidáme (nezakomentovanou). Můžeme ji přidat jak prostřednictvím editace XML souboru, tak prostřednictvím webového rozhraní, jak jsme si to popsali v druhém dílu seriálu. Nezapomeňte také vyplnit položky <title> a <description> něčím více popisným :-).

    Nyní, když máme projekt vytvořen, je vhodné si stáhnout jeho obsah (stejně je zatím skoro prázdný) na lokální disk. To uděláme opět pomocí příkazu osc co home:m4r3k:kernel-backport. Následně pomocí příkazu osc linkpac nalinkujeme balíčky ze zdrojového projektu do projektu cílového (tím je v našem případě home:m4r3k:kernel-backport. V případě backportování kernelu stačí spustit následující bash skript.

    for i in apparmor-parser device-mapper kernel-default kernel-source kernel-xen lvm2 openais udev apparmor-profiles kernel-debug kernel-docs kernel-syms linux-kernel-headers mkinitrd sysfsutils; do
    	osc linkpac openSUSE:Factory $i home:m4r3k:kernel-backport
    done
    

    Po doběhnutí tohoto krátkého skriptíku a vybuildění balíčků bude k dispozici FTP adresář home:m4r3k:kernel-backport, v němž jsou jednotlivé repozitáře, pro které jste si nechali backportovaný balíček sestavit. Zde bych si dovolil požádat přítomné čtenáře, aby si v případě potřeby nevytvářeli vlastní backport openSUSE jádra pro distribuce openSUSE 10.2, 10.3 a 11.0 z openSUSE Factory, protože tento backport je v mém projektu home:m4r3k:kernel-backport a jednalo by se tak o zbytečné plýtvání prostředky buildservicu. Ale pokud máte zájem o backport nějakého jiného balíčku, tak neváhejte :-).

    Balíčky si do systému můžete nainstalovat například touto posloupností příkazů (otestováno na openSUSE 10.3):

    zypper ar --repo http://download.opensuse.org/repositories/home:/m4r3k:/kernel-backport/openSUSE_10.3/home:m4r3k:kernel-backport.repo
    zypper up -t package
    

    kterou si přizpůsobíte vlastním podmínkám. Například změna URL k *.repo souboru.

    Patchuji, patchuješ, patchujeme

    Pokud jste nahlásili bug a broukobijci vás zásobují patchi k otestování nebo si chcete do nějakého balíčku přidat patch, který doplňuje pro vás zajímavou funkci, a nebo si jen chcete balíček přeložit s trošku jinými volbami, buildservice má pro vás jednoduché a elegantní řešení. Opět se jedná o magii spojenou s příkazem osc linkpac jako v předchozím případě.

    Pokud chcete přidat do balíčku nějaký patch, lze to provést pomocí editace souboru _link, který je v adresáři nalinkovaného balíčku po stažení pomocí příkazu osc co. _link soubor obsahuje něco podobného tomuto:

    <link project="openSUSE:Factory" package="apparmor-parser">
    <patches>
      <!– <apply name="patch" /> –>
      <!– <topadd>%define build_with_feature_x 1</topadd> –>
    </patches>
    </link>

    Jak vidíte, soubor obsahuje zakomentované části <apply name="patch" /> a <topadd>%define build_with_feature_x 1</topadd>. Neobsahuje však jednu stejně důležitou část <add name="somepatch" after="3" popt="1" dir=""/>. Tento element add umožňuje přidat k nalinkovanému balíčku libovolný patch. Například pokud chceme vytvořit balíček opatchovaný patchem cool-feature.patch pomocí makra %patch -p2 tak upravíme _link do následující podoby:

    <link project="openSUSE:Factory" package="apparmor-parser">
    <patches>
      <add name="cool-feature.patch" popt="2"/>
    </patches>
    </link>

    Výsledek úprav musíte v případě, že jste editovali lokální soubor, poslat na server pomocí příkazu osc commit. Pomocí tohoto řešení však můžete přidat jen nějaký patch na samotný tarball se zdrojáky. Co dělat v případě, že chcete upravit daný spec soubor? K tomu zase slouží <apply name="patch" />. Jeho použití si ukážeme třeba na situaci, kdy chceme openSUSE distribuční jádro poupravit tak, aby neobsahovalo App Armor.

    Ze všeho nejdříve si stáhneme původní balíček kernel-default z patřičného projektu (záleží na verzi distribuce, pro kterou tuto změnu budeme provádět). Já použiji jádro z projektu openSUSE:Factory a zneužiji již založený projekt home:m4r3k:kernel-backport.

    osc co openSUSE:Factory kernel-default
    cd openSUSE:Factory/kernel-default
    cp kernel-default.spec kernel-default.spec.orig
    

    Nyní si najdeme v souboru kernel-default.spec řádek 174 s následujícím obsahem: Source110: patches.apparmor.tar.bz2 a pomocí znaku # provedeme zakomentování. Totéž uděláme i s řádkem číslo 192, který obsahuje NoSource: 110. Ještě musíme na řádku číslo 228 odebrat příkaz na rozbalení Source balíčku s číslem 110, což provedeme odstraněním části -a 110. Vzhledem k tomu, že k opatchování se používá soubor %_sourcedir/series.conf, který obsahuje seznam aplikovaných patchů, tak ještě musíme všechny patche týkající se app.armor odstranit, což můžeme udělat nějakým kódem v Bashi (viz můj diff). Následně soubor uložíme a pomocí příkazu diff -u kernel-default.spec.old kernel-default.spec si vytvoříme patřičný patch. Ten by měl vypadat nějak takto (samozřejmě si můžete výstup přesměrovat přímo do nějakého souboru):

    --- kernel-default.spec.old     2008-06-27 14:23:46.936011735 +0200
    +++ kernel-default.spec 2008-06-27 22:03:03.060007138 +0200
    @@ -171,7 +171,7 @@
     Source107:      patches.xen.tar.bz2
     Source108:      patches.addon.tar.bz2
     Source109:      patches.kernel.org.tar.bz2
    -Source110:      patches.apparmor.tar.bz2
    +#Source110:      patches.apparmor.tar.bz2
     Source111:      patches.rt.tar.bz2
     Source120:      kabi.tar.bz2
     %define my_builddir %_builddir/%{name}-%{version}
    @@ -189,7 +189,7 @@
     NoSource:       107
     NoSource:       108
     NoSource:       109
    -NoSource:       110
    +#NoSource:       110
     NoSource:       111
     NoSource:       120
     # The following KMPs have been integrated into the kernel package.
    @@ -225,7 +225,7 @@
     fi
     echo "Architecture symbol(s):" %symbols
     # Unpack all sources and patches
    -%setup -q -c -T -a 0 -a 100 -a 101 -a 102 -a 103 -a 104 -a 105 -a 106 -a 107 -a 108 -a 109 -a 110 -a 111 -a 120
    +%setup -q -c -T -a 0 -a 100 -a 101 -a 102 -a 103 -a 104 -a 105 -a 106 -a 107 -a 108 -a 109 -a 111 -a 120
     # Generate the list of supported modules
     (   %_sourcedir/guards %symbols < %_sourcedir/supported.conf
         for how in external; do
    @@ -253,6 +253,8 @@
     subarch=${1%/*}
     # Apply the patches needed for this architecture.
     %if ! %build_vanilla
    +grep -v "patches.apparmor" %_sourcedir/series.conf > %_sourcedir/series.conf.tmp
    +mv %_sourcedir/series.conf.tmp %_sourcedir/series.conf
     for patch in $(%_sourcedir/guards %symbols < %_sourcedir/series.conf); do
         if ! patch -s -E -p1 --no-backup-if-mismatch -i ../$patch; then
            echo "*** Patch $patch failed ***"
    

    UPOZORNĚNÍ: Správně byste měli ještě opravit část %changelog a přidat tam nějaký záznam o tom, že se jedná o opatchovaný build - ale pro naše cvičné účely to není třeba.

    Poté přejdeme do projektu (a patřičného adresáře), kde máme již nalinkovaný balíček kernel-default (v mém případě se jedná o adresář home:m4r3k:kernel-backport/kernel-default) a tento patch soubor do daného adresáře uložíme třeba pod názvem app_armor_remove.patch. Nyní editujeme soubor _link, abychom dostali podobný výsledek.

    <link project="openSUSE:Factory" package="kernel-default">
    <patches>
      <apply name="app_armor_remove.patch" />
    </patches>
    </link>
    

    Ještě je potřeba to všechno poslat na server; to můžeme udělat třeba následující sekvencí příkazů:

    osc add app_armor_remove.patch # přidá soubor app_armor_remove.patch mezi BuildServicem spravované soubory
    osc commit # odešle změny na server
    

    A k čemu mi to je?

    Pokud jste poctivě četli druhý díl seriálu, tak jistě víte, že místo tohoto řešení můžete prostě do adresáře s _link souborem přidat soubor se stejným názvem, který nahradí ten původní. Důvod pro použití patchování v rámci _link souboru je však jednoduchý (kdo na něj přijde před jeho přečtením, má u mě bonbón :-)), tohle řešení je, na rozdíl od toho prvního, vhodné i do budoucna. Musíme si uvědomit, že když přeplácneme patřičný .spec soubor, tak v případě aktualizace dojde k nepříjemné situaci, kdy se nám balíček přestane aktualizovat automaticky s upstream projektem, jež linkujeme. Toto řešení je do jisté míry (limity příkazu patch, který si s každou situací nemusí poradit) dopředné, a proto, pokud dojde k prostému navýšení verze, to naše metoda s patchováním ustojí a sestaví novější verzi balíčku s potřebnými změnami, které jsme provedli.

           

    Hodnocení: 100 %

            š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ář

    David Šmíd avatar 2.7.2008 09:43 David Šmíd | skóre: 10 | blog: dsmid
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    openSUSE (a pokud vím i všechny ostatní RPM-based distribuce) fungují na principu stabilních vydání, a ne na principu rolling-updates, jako je tomu třeba v případě Gentoo.
    Minimálně jedna RPM-based distribuce (PCLinuxOS) funguje na principu rolling-updates.
    Jediné "intuitivní" rozhraní je bradavka. Všechno ostatní se musíte naučit. -- Bruce Ediger, o uživatelském rozhraní
    Marek Stopka avatar 2.7.2008 10:39 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    Aha, díky za info.
    Ilfirin avatar 2.7.2008 20:27 Ilfirin | skóre: 32 | blog: ilfblog | Liberec
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    Ovšem ten není v BuildService podporován, pokud se dobře dívám.
    Marek Stopka avatar 2.7.2008 20:31 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    No a?
    Ilfirin avatar 2.7.2008 20:34 Ilfirin | skóre: 32 | blog: ilfblog | Liberec
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    comment, nic víc.
    Marek Stopka avatar 2.7.2008 20:41 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    Aha, já myslel, že to má nějaký smysl, který mi uniká. :-)
    2.7.2008 21:37 phero | skóre: 17 | blog: techblog
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    podporovat bleeding edge distro ani neni mozny
    Marek Stopka avatar 2.7.2008 22:00 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    Je možné ho podporovat stejně jako openSUSE:Factory... Jen je to technicky náročné... (hlavně na HW)

    Založit nové vláknoNahoru

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