Dotaz: Odhad náročnosti instalace CentOS, Apache, PHP, Oracle OCI

[Karel Čížek]

Chtěl bych se poradit ohledně odhadu pracnosti případně pak návrhu řešení.

Úkolem je rozchodit server se softwarem Centos 6.8 + Apache 2.4 + PHP 5.6 + Oracle OCI ovladač. Cílem není instalovat Oracle DB, ta už běží jinde -- tady jde "jen" o ovladač.

Předesílám, že to není triviální úkol, nestačí nainstalovat pár balíčků z repozitáře. Problémy jsou hlavně s Oracle OCI ovladačem (proprietární software, co taky čekat než problémy :-/).

Kromě toho, že by to mělo fungovat, by to mělo být v produkční kvalitě -- nejde o to, to nějak zbastlit, aby to s odřenýma ušima běželo, ale mělo by to být spolehlivé, důvěryhodné a udržovatelné. Neměly by v tom figurovat RPMka z pochybných zdrojů nebo nějaké neprofesionální postupy. Až vyjde nová verze Apache nebo PHP, mělo by být možné snadno upgradovat a tento postup by měl být zdokumentovaný.

Kdybyste tenhle úkol dostali jako zaměstnanec, o kolik času byste si řekli? Dělali jste to někdy? Staráte se někdo o podobný systém v produkci? Kdybyste to dostali za úkol jako externí konzultant, kolik by to stálo?

Podle mého názoru, profesionál, který má s touhle kombinací zkušenost (hlavně s tím obskurním ovladačem), by to měl zvládnout během jednodenního školení/workshopu naučit dalšího člověka, nainstalovat s ním testovací server a předat mu tuto zkušenost. Je tenhle odhad OK, nebo je to mimo a tohle je práce na čtrnáct dní?

P.S. nechci aby tu někdo dělal za mě mojí práci, tenhle úkol řeší kolegové a mě se to přímo netýká, jen bych rád znal názor někoho třetího případně jim nějak pomohl.

P.P.S. původně jsem se ptal na Rootu, omlouvám se za duplicitní dotaz, ale tam za celé dva dny nikdo neodpověděl (ani trollové, což je co říct).

Odpovědi

[Bedňa]

Oracle k svojim riešeniam predáva platenú podporu, takže by som sa spýtal tam, kde som platil.

[Peter Golis]

Je dosť reálna šanca že bude lacnejšia podpora od Oracle, alebo zakúpenie plateného RHEL ako dvojtýždňový workshop pre človeka čo podľa popisu nikdy nespravoval server s linuxom, len navrhol zdanlivo lacnejšie riešenie aby sa dostal k školeniam.

[Karel Čížek]

Ne, nejde o to, někoho dva týdny učit spravovat GNU/Linux -- jde o předání konkrétních zkušenosí:

• Dostat do Centosu dané verze tyto verze Apache a PHP -- čistou cestou, nejlepší praktiky, kderé má někdo vyzkoušené v produkci.
• Rozchodit tam PHP OCI modul (instalace samotného Oracle OCI ovladače je taky triviální, jen RPM, i když je to proprietární sračka a pak si ještě musíš ručně nastavit cestu, aby byly vidět dané knihovny, jinak to nefunguje).

[Peter Golis]

Mne išlo o to, že živiť niekoho dva týždne aj s jeho školením je obvykle drahšie ako pripravené komerčné riešenie. Teda, pokiaľ toho človeka neplatíte podobnou sadzbou ako v Lidli za kasou.

[bigBRAMBOR]

nic tezkeho, nainstalujes centos, pridas repo pro apache 2.4 a php 5.6, ve standardu jsou starsi. Doinstalujes oracle-instantclient, ORACLE nabizi rovnou RPM, pres pecl doinstalujes OCI8, pri iinstalaci mu reknes kde je adresar a oracle clientem, a pak napr v PHP.D povolis extencion OCI8. I s instalaci OS mas po obede hotovo.

[Karel Čížek]

Kéž by to bylo tak jednoduché -- ale viděl jsem dva lidi, jak si na tom vylámali zuby a strávili na tom přes čtrnáct dní. A když to před nějakou dobou zkoušel jiný kolega na Windowsech, tak strávil týden jen s rozcházením toho Oracle OCI ovladače. Musí tam být něco hodně smradlavého. Proto mi přijde nejvhodnější řešení najít někoho, kdo má s tímhle konkrétním úkolem zkušenost a vyřeší to za den, než aby se s tím trápili lidi a šli na to přes obecné/obvyklé postupy.

pridas repo pro apache 2.4 a php 5.6

Které repo konkrétně? Kterému se dá dost věřit pro produkční nasazení.

Nebylo by lepší si stáhnout zdrojáky přímo od Apache a PHP a sestavit si z nich vlastní RPM?

Doinstalujes oracle-instantclient, ORACLE nabizi rovnou RPM

To sice ano, i když je to pěkná sračka (viz komentář výše -- proměnná).

pres pecl doinstalujes OCI8, pri iinstalaci mu reknes kde je adresar a oracle clientem

Tohle byl kámen úrazu (nevím přesně proč, nebyl jsem přímo u toho).

I s instalaci OS mas po obede hotovo.

Tomu moc nevěřím. Můj optimistický odhad je, že bych to dal za den, třeba přes víkend a pak jim to vyfakturoval ale cítím tam celkem vysoké riziko, že to za den nedám (na základě toho, že na tom jiní strávili týdny), dálší čas se mi s tím nebude chtít trávit a výsledkem je ztracený den a nic z toho.

Lituji, že to neběží třeba na PostgreSQL... (nebylo to moje rozhodnutí).

[bigBRAMBOR]

hledáš problémy a ne řešení

Které repo konkrétně? Kterému se dá dost věřit pro produkční nasazení.

Ani samotnemu CentOS nemuzes moc verit. Apache 2.4 je v EPELu, celkem bezne pouzivane repo, Instalace EPEL rpm je primo v centos base. PHP 5.6 je tusím v centos extras, repo primo od autorů.

To sice ano, i když je to pěkná sračka

pokud chceš tu sračku instalovat, tezko se bez te sračky obejdes. Cestu nastavujes jednou při překladu OCI8

Tohle byl kámen úrazu (nevím přesně proč, nebyl jsem přímo u toho).

Pak to byl určitě zapeklitý problém

ale cítím tam celkem vysoké riziko, že to za den nedám (na základě toho, že na tom jiní strávili týdny)

místo pindání čti návody

Kéž by to bylo tak jednoduché

ano je to jednoduché, instaloval jsem to na centos asi 10x

[Max]

Naprostý souhlas s "bigBRAMBOR". Nechápu, kdo co mohl řešit 14 dní. Osobně jsem to instaloval také, u nás ve firmě pro produkci(kucí to mj. používají v php) a nevidím v tom problém, stejně jako "bigBRAMBOR". Zabralo mi to myslím také půl den, možná den, než jsem si vše pročetl a u všeho se ujistil.
Navíc, pokud je k dispozici dokumentace, tak zaškolit lidi navíc je otázkou chvilky. Člověk ukáže dokumentaci, což se vejde na jednu A4 úplně v klidu (kdo by chtěl být hodně podrobný, tak dva listy), maximálně ukáže, na co si dát pozor a hotovo.

Sestavovat si vlastní apache + php je smrt na údržbu. Kdo má stále sledovat každé bezpečnostní uprdnutí každé app. Prostě dělám full update systému a neřeším. Servisní úkon to je na chvilku.
Pokud jde o údržbu oracle části, tak ta se dělá jako u OracleDB, žádný repo s balíčky, všechno ručně hlídat a ladit. Kdybych měl spravovat více serverů, tak bych si pak dělal vlastní balíčky a distribuoval je přes lokální repo.

Má odpověď je tedy též max. den.
To se ovšem vztahuje pro člověka, který tomu aspoň trochu rozumí, né pro někoho, kdo se rozhoduje, zda bude ladit apache+php ze zdrojáků nebo z repa, protože mu zdrojáky přijdou "bezpečnější".
Resp. já bych to dal v klidu do dne. Pokud je otázka, zda to dá někdo jiný v klidu do dnes, tak jak to mám vědět?
Zdar Max

[Ivan2]

Opravdu nechapu co je na tom tak tezkyho. Zvlast kdyz uz dneska mame google.

http://www.oracle.com/technetwork/articles/technote-php-instant-084410.html

http://stackoverflow.com/a/20355309/836215

Tvuj problem je dost trivialni a pokud na tom nekdo zabil tyden casu, tak je problem nejspis nekde jinde nez ho hledate. A nikdo vam nepomuze, dokud nereknete co jste vsechno vyzkouseli a jakou chybu vam to vraci.

Jinak IMHO je PHP + Oracle ta nejhorsi mozna kombinace pro produkcni aplikacni server.

[citanus]

apache + php mas v redhat software collections: https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html/2.2_Release_Notes/chap-RHSCL.html#sect-RHSCL-Changes-Overview takze se s tim trapit vubec nemusis.

 

Instalace oracle clienta, taky neni nic narocneho. Max den prace.

[Karel Čížek]

Díky! Ty Collections vypadají jako řešení. (osobně jsem spíš na Debian/Ubuntu, takže tenhle RPM svět až tak moc neznám)

Ze zvědavosti jsem to vyzkoušel -- chvilku jsem hledal, jak je to v CentOSu a pak jsem asi za deset minut dostal do čisté instalace systému toho Apache 2.4 a PHP 5.6. Zbývá tedy ten PHP OCI modul. Takže tomu asi dám nějakou hodinu ve volném čase a uvidíme, jestli se zadaří -- už to nevypadá jako riskování celého dne práce s nulovým výsledkem

[Bill Gates]

Tak hodina času po čisté instalaci CentOS. Pokud vedení firmy není zaseklé, raději než CentOS bych to stavěl na Debianu, ale jelikož systemd už je i tam, tak na Devuanu, kde za to můžu dát ruku do ohně, že to opravdu poběží bez nějakých "nečekaností" - což je zkušenost z praxe.

Pokud se to má naučit někdo jiný, a má to umět, tak klidně i 14 dnů času.

Nebo i 100 let, pokud to bude opice.

[alkoholik]

To asi zalezi na tom, jestli jedes proti full nebo instant clientu.
Instant je jen par RPM a novy vychazi jenom s velkym releasem databaze.

[Karel Čížek]

Nevím, pro mne je to nutné zlo Stačí nějaké minimum, aby se šlo z PHP připojit k Oraclu. Takže snad ten Instant Client.

[Arnošt Málek]

V podstatě takto "polo" automaticky instaluju, není to problém. Client buď instant, nebo full, dle potřeb. A Apache + PHP přímo ze zdrojáku, configure - make - make install ... už mám nachystané 2 jednoduché sh kde je voláno configure s volbama. Takže to je otázka "pár minut".

[Karel Čížek]

To mi právě jako moc udržovatelné nepřijde -- ze zdrojáků klidně, ale mělo by z toho vypadnout RPM, které se následně nainstaluje. Jednak se dá kompilovat na jiném stroji než na tom, kde to pak bude běžet, a jednak má balíčkovací systém přehled o tom, které soubory patří kterému programu.

Nicméně nejlíp asi vypadají ty kolekce, jak navrhoval někdo výše.

[Karel Čížek]

Tak jsem to dnes vyzkoušel. Stručný postup:

Z kolekcí nainstalovat httpd24 a rh-php56.

Chtělo to schválit nový GPG klíč repozitáře, což jsem v rámci testu udělal jen tak. Ale u produkčního nasazení bude potřeba ověření otisku z důvěryhodného zdroje.

Potom stáhnout Oracle Instant Client + jeho SDK a nainstalovat tyto dva RPM balíčky.

rpm -i oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm
rpm -i oracle-instantclient12.1-devel-12.1.0.2.0-1.x86_64.rpm

Ručně je potřeba udělat:

echo /usr/lib/oracle/12.1/client64/lib > /etc/ld.so.conf.d/oracle-instant-client.conf
ldconfig

Jinak ten Oracle není kompatibilní sám se sebou (ldd na jeho binárkách i knihovnách říká, že chybí knihovny).

Potom potřebujeme OCI modul do PHP:

yum install gcc
yum install rh-php56-php-devel
yum install rh-php56-php-pear

pecl install oci8-2.0.10

echo "extension=oci8.so" > /etc/opt/rh/rh-php56/php.d/50-oci8.ini
service httpd24-httpd restart

BTW: ten pecl funguje bezvadně na první dobrou, až jsem se divil, ale jde to mimo distribuční repozitáře, stáhne to prostě odněkud zdrojáky a zkompiluje -- jak je zde zajištěna integrita, aby někdo neudělal MITM?

Chyba:

PHP Warning: PHP Startup: Unable to load dynamic library '/opt/rh/rh-php56/root/usr/lib64/php/modules/oci8.so' - libclntsh.so.12.1: cannot enable executable stack as shared object requires: Permission denied in Unknown on line 0

Řešení:

setsebool -P httpd_execmem 1
# http://antoine.hordez.fr/2012/09/30/howto-install-oracle-oci8-on-rhel-centos-fedora/
# Configure SELinux : allows httpd to execute programs that require memory addresses that are both executable and writeable

Je to OK? Mně to přijde spíš trochu WTF? Proč oraclí klient (!) potřebuje spustitelnou a zároveň zapisovatelnou paměť?

service httpd24-httpd restart

Pak to jde spustit a v phpinfo() vidíme modul OCI8, ale když se z PHP skriptu zkusíme připojit k DB, následuje chyba:

oci_connect(): ORA-12546: TNS:permission denied

Řešení:

setsebool -P httpd_can_network_connect on
# http://www.emsperformance.net/2013/12/20/connecting-to-oracle-database-from-php-with-oci8/
service httpd24-httpd restart

Je to OK? Má se to takhle dělat? Není to moc dřevorubecké?

Byla to práce asi na půl hodiny a výsledkem je, že se můžu z PHP skriptu připojit do Oracle databáze.

Má to ale "drobný" háček:

Apache/2.4.18 (Red Hat)
PHP/5.6.5

Ten Apache asi může být. Ale PHP 5.6.5 vyšlo 22. ledna 2015 tzn. víc jak rok a půl zpátky. Aktuální verze této větve je 5.6.23. Nebo to RedHat patchuje a backportuje opravy tak, že je to lepší než 5.6.5 stažená z PHP.net?

Z jakých repozitářů tam dostanu novější verzi PHP?

[bigBRAMBOR]

REMI, to je takovej odvážnej repositář, přehulí ti default PHP v CENTOS, ale muzes si vybrat repo s PHP 5.5 - 7.1

[Karel Čížek]

A jak to dělají zákazníci RedHatu? Platí si podporu u RH a nakonec si nainstalují PHP z repozitáře od někoho jiného?

[bigBRAMBOR]

nevím, já nejsem zákazník, znám jenom Centos a Oracle. Asi nepouzívají nejnovejsi sw, proto si platí distro s dlouhou podporou. JInak chyby opravují a backportují a do nizsích verzí.

[pavele]

Nebo to RedHat patchuje a backportuje opravy tak, že je to lepší než 5.6.5 stažená z PHP.net?

RedHat backportuje opravy po celou dobu životnosti tohoto distra.

Jestli je to lepší, než verze stažená odněkud? To musí posoudit ten, který takové změny provádí.

[Bedňa]

jak je zde zajištěna integrita, aby někdo neudělal MITM?

Klasické korporátne riešenie, takže nijak. Nejak sa to nelíši od Dockeru od RedHat a podpory pre Win z ulož.to.

Veľa zdaru.