Jurský park aneb jak jsem spouštěl dinosaury

21. 10. 2004
Doba čtení: 5 minut

Sdílet

V tomto článku se pokusím nastínit své osobní zkušenosti s provozem prastarých binárních programů určených pro SCO OpenServer v prostředí Linuxu. Při použití projektu Linux A.B.I. to nebyl žádný velký problém.

Ve firmě se zabývám vývojem IS, který používá jako platformu Oracle databázi a Oracle Forms + Oracle Reports pro uživatelské rozhraní. Původní verze používala pro svůj provoz Oracle databázi verze 7 a textové terminálové rozhraní Oracle Forms 3 (a samozřejmě odpovídající textovou verzi Oracle Reports). Na uživatelově stanici běžel emulátor terminálu (ArcTel) a práce probíhala vzdáleně pomocí protokolu telnet. Nyní se začala používat databáze verze 8i na Linuxu a jako klient jak starý textový terminál, tak nový grafický klient (Forms 6i nebo aplikační server 9i…). Požadavkem tedy bylo rozchodit starou znakovou verzi runtime v nově vzniklém prostředí na nových počítačích.

Jedná se samozřejmě o programy distribuované v binární podobě pro jeden operační systém, na který má uživatel zakoupenu licenci. V článku ukáži, jak lze rozběhat tyto binární aplikace určené pro SCO OpenServer v mírně upraveném prostředí Debian GNU/Linux v 3.0r2.

Příprava výběhu

Projekt, který zajistí korektní spuštění binárních souborů určených pro SCO OpenServer, se nachází na adrese linux-abi.sourcefor­ge.net. Samotný projekt linux-abi je pokračováním staršího iBCS, který se týkal jader řady 2.2, a jak bude vidět dále, lze některé části projektu iBCS využít i s linux-abi.

Linux-abi podporuje nejen SCO, ale i několik dalších platforem. Vždy se podpora týká i386 systémů, neboť jsou do jádra doplněna jen volání systému, nikoliv emulace instrukcí procesoru. Jedinou výjimkou je procesor i286 a operační systém SCO Xenix 286. I tak ale výčet považuji na solidní:

  • SCO OpenServer
  • SCO OpenDesktop
  • SCO Unix 3.x
  • SCO Xenix 386
  • SCO Xenix 286 (with userspace x286 emul)
  • SCO UnixWare 7
  • Caldera OpenUnix 8
  • SUN Solaris 2
  • System V Release 3 (SVR3)
  • System V Release 4 (SVR4)
  • Wyse V/386
  • ISC Interactive Unix

Jelikož zavádění binárních spustitelných programů je záležitostí jádra, je nutné jej upravit. Je možno volit mezi přímým zakompilováním podpory do jádra, nebo zaváděním pomocí modulů. Já jsem zvolil první možnost, neboť považuji spouštění aplikací za natolik základní záležitost, že extra zavádění modulů mi přijde nadbytečné. Je to ale jen můj čistě subjektivní názor, bez jakéhokoliv technického opodstatnění (u tohoto druhu aplikací), takže kdo má raději moduly, může zvolit moduly.

Patch je k dipozici pro jádra řady 2.4, v současné době (14. 09. 2004) do verze 2.4.26. Přestože v dokumentaci upozorňují na možnost konfliktu v patchovaných jádrech distribucí, nedalo mi to a zkusil jsem aplikovat linux-abi-2.4.18.0.patch.bz2 na distribuční jádro Debianu, samozřejmě odpovídající verze 2.4.18. Nepochodil jsem, ačkoliv se jedná o číselně správnou verzi, rozdílů proti vanilla jádru bylo příliš. Bylo ohlášeno několik konfliktů a jádro jsem nepřeložil ani na několikátý pokus.

Po této zkušenosti jsem se rozhodl vrátit k doporučenému vanilla jádru. A když už jsem musel použít jádro mimo distribuci, použil jsem 2.4.21 – poslední, na které byl v té době dostupný patch (nyní je již linux-abi-2.4.26–0.patch.gz). Pro jistotu jsem nakonfiguroval a jádro přeložil ještě bez linux-abi, abych si byl jistý, že případná chyba bude skutečně způsobena následnou aplikací patche a nikoliv mojí chybnou konfigurací jádra.

Aplikování souboru linux-abi-2.4.21.0.patch.bz2 z linux-abi.sourcefor­ge.net/patches proběhlo bez chyb a pomocí make oldconfig jsem jádro zkonfiguroval a přeložil. Na tomto místě si dovolím varovat před přílišným megalomanstvím :-). Některé z api jsou vzájemně v konfliktu, a když jsem záměrně (z cvičných důvodů) zvolil podporu všech nabízených systémů, nepodařilo se mi jádro zkompilovat vůbec. Když jsem pak „ubral“ a nechal začlenit vše mimo chybového modulu, proběhla kompilace v pořádku. Stejně jsem pak vyzkoušel i jinou kombinaci, v níž byla opět zahrnuta i výše zmíněná chybová volba, a opět v pořádku. Z toho usuzuji na zmíněný konflikt.

Vypouštění do výběhu

Poté, co jsem zakompiloval podporu do jádra, jsem se pustil do spouštění prvních binárek přenesených ze systému SCO OpenServer. Podle očekávání ne vše je možné spustit. Naštěstí je v mém případě stěžejní aplikace (a všechny potřebné aplikace od Oracle) ve formátu coff, který spustit lze. Formát elf z SCO OpenServer spustit nelze. Takže jsem musel opustit myšlenku na přenesení i stěžejních systémových utilit, jako byla konkrétní verze bourne shellu a několik dalších, které sice mají své linuxové ekvivalenty, ale nejsou s nimi zcela kompatibilní. Naštěstí se tato nekompatibilita dala poměrně jednoduše opravit změnou uživatelských parametrů při jejich volání (tj. proběhla úprava v uživatelské aplikaci na úrovni zdrojového kódu).

Krmení a podestýlka

Ovšem podpora při spouštění „cizích“ programů nekončí u jejich zavedení. Okamžitě po zavedení začaly složitější programy hlásit neexistenci několika souborů a zařízení. Pokud jde o soubory, lze se s problematikou snadno vypořádat zavedením vhodných linků, pokud se tyto soubory v Linuxu nacházejí, ale na jiných místech. Některé soubory se v Linuxu nenacházejí a bylo nutné je přenést z původního systému. V mém případě se však jednalo jen o soubor /etc/default/lang, textový soubor obsahující obdobu locale. Víc jsem nepotřeboval, protože Oracle má všechny binárky (naštěstí) slinkované staticky. Podle dokumentace by měly pracovat i dynamicky linkované knihovny přenesené z původního systému, ale samozřejmě je potřeba v takovém případě vlastnit i licenci k původnímu systému, jehož části by byly použity. V mém případě by to stejně nebyl problém, neboť máme SCO OpenServer samozřejmě legálně zakoupen pro všechny instalace (aby ne, když tam dosud spolehlivě pracoval).

ict ve školství 24

Dalším problémem je podpora potřebných zařízení v adresáři /dev. Ani tady se ale nejedná o nepřekonatelnou překážku. Očekávaná zařízení se buď jen jinak jmenují, nebo je lze vytvořit příkazem mkdev. Začnu nejzbabělejší, ale funkční metodou. Opatřil jsem si starý balíček iBCS z RH6.2 a potřebná zařízení z něj do /dev nakopíroval pomocí mc (fuuuj). Čistší metoda spočívá v použití scriptu mkdev.ibcs z již zmíněného balíčku a jeho prostudováním se lze dobrat toho, že zařízení ptypX a ttypX jsou jen symbolické odkazy na linuxové ptyX a ttyX (kde X je pořadové číslo). Ostatní zařízení se vytvářejí pomocí mknod a příslušných parametrů.

Chovatelské úspěchy

Nakonec musím říci, že v mém konkrétním případě funguje ABI skvěle, následný „ostrý“ přechod z SCO OpenServeru na Linux proběhl bezproblémově. Dnes je systém v rutinním provozu na několika identických instalacích a uživatelé změnu nepoznali. Snad s výjimkou podstatně vyšší rychlosti na novém stroji.