Ez a cikk folytatása is, meg nem is a korábbi Akela cikknek (http://gzoli.spaces.live.com/blog/cns!F9E7FFBC4B3008EB!970.entry). Folytatása abból a szempontból, hogy a gép, amin a történet folyatódik a keresztségben az Akela nevet kapta, de fizikailag nem az a vas, amiről korábban írtam. Folytatás abból a szempontból, hogy az alkalmazás, amiről írni fogok ugyanaz ami a korábbi Akelán futott.
A korábbi cikk végét kicsit nyitva hagytam. A korábbi gép (ex Akela, jelenleg Bagira) él és virul, kapott egy új, immáron x64-es operációs rendszert, valamint egy Dynamics CRM-et.
Amiről itt szó lesz az kizárólag szoftver. A feladat, hogy egy megnevezni nem kívánt üzleti alkalmazást át akartam költöztetni a régi Akeláról, az újra. Pontosabban a feladat a következő:
Adva van egy alkalmazás IIS6/PHP4/Zend Optimizer/MSSQL 2000 környezetben, egy gépen, egy korábbi domainben, egy virtuális gépen (a korábbi akeláról vmWare Converterrel http://www.vmware.com/products/converter/ virtualizálva). Ezt át kell helyezni az új domainbe oly módon, hogy az alkalmazás + IIS6/PHP4/Zend Optimizer az egyik, az MSSQL 2005 a másik gépen van.
Előre bocsájtom, hogy az alkalmazás gyártójával régi és nagyon jó kapcsolatom van. Az alkalmazás, üzleti szempontból kielégíti az igényeinket, sőt sok olyan lehetőséggel is rendelkezik, amit az egyéb hasonló rendszerek nem, vagy csak vért izzadva képesek produkálni.
E cikk kapcsán viszont kénytelen leszek benézni a motorháztető alá, és amit ott látok az mind üzemeltetési, mind biztonságtechnikai szempontból tökéletesen elborzaszt. Az az érzésem, hogy ékes példája az everyonefullcontroll típusú fejlesztési hozzáállásnak.
Kezdjünk bele:
1. A cég adott ajánlatot a költözés kivitelezésére, de bizonyos megfontolásokból azt választottam, hogy megcsinálom magam. (Elsősorban talán azért, mert szeretek teljes kontrolt gyakorolni az üzemeltetett rendszereim felett)
2. Konzultáltam a céggel és kaptam néhány alapinformációt:
– a program beállításai egy Config.php nevű fájlban találhatóak
– php-ből meg se próbáljam az 5.x-es szériát használni, mert csak a 4.x-el működik.
3. Próbálok óvatos lenni, a php-hez nem értek, ráadásul több okból szükségem lesz arra, hogy a működő rendszerből legyen egy standalone virtuális verzióm, ezért először egy gépre, SQL-el együtt próbálom összerakni a történetet. Csináltam egy virtuális w2k3-at, ráraktam egy SQL 2005 Express-t.
4. El kezdtem küzdeni a php-vel, nézegettem az eredeti konfigurációt és első lépésben nem jöttem rá, hogy mitől működik (hát persze, mert az IIS-hez sem értek). Hosszas küzdés, az eredeti konfig vizsgálata és a neten lévő mindenféle doksik olvasása után rájöttem, hogy az eredeti állapot CGI-t használ. Én azt gondoltam, hogy ezt nem szeretném, ezért ISAPI szűrőként raktam fel a PHP-t (letöltöttem a PHP 4.4.9-et ami az utolsó 4.x-es verzió). Hátha valaki akar ilyet csinálni, ezért gyorsan leírom a lépéseket (talán ez egyszerűbb, mint a 20 oldal körüli doksi):
– Kicsomagolni a php zip csomagját a c:\php4 könyvtárba
– Read és Execute jog a C:\php4 könyvtárra az IUSR_GÉPNÉV felhasználónak
– A C:\php4\php.ini-recomended másolása C:\php4\php.ini névvel
– A php.ini-ben az extension_dir = "c:\PHP4\extensions" beállítása
– A path-ba beírni a c:\php4 és a c:\php4\extensions könyvárakat
– A c:\PHP4\dlls és a c:\PHP4\sapi könyvtár tartalmát átmozgatni a c:\PHP4 könyvtárba
– IIS Admin-ban az Internet Information Services\AKELA\Web Service Extensions alatt hozzáadni a C:\PHP4\php4isapi.dll-t és Allowed státuszba állítani
– IIS Admin-ban az Internet Information Services\AKELA\Web Sites\Default Web Site\Properties\Home Directory fül\Configuration alatt a php kiterjesztéshez hozzáadni a C:\PHP4\php4isapi.dll-t
– Ennyi. Lehet tesztelni ezzel a nagy bonyolultságú kóddal:
<?php
phpinfo();
?>
phpinfo();
?>
Ezzel a php meg is van. Miután ezzel megvoltam még felraktam a Zend Optimizer-t, mert a fejlesztő védi a saját kódját ezerrel (sajnos az én adataimat ennél sokkal kevésbé). A Zend-et ugyanúgy teszteltem a fenti php kóddal, megvolt. OK.
5. Elkezdtem összeszedni az alkalmazás saját specifikumait. A következőket tapasztaltam (itt kezdtem a plafonra mászni):
– Az IUSR_GÉPNÉV as az IIS_WPG felhasználónak full controll joga van az InetPub\wwwroot könyvtárra
– Az adatbázisban használt két felhasználónak a neve (ami ráadásul elég egyszerű) megegyezik a jelszóval
– Az adatbázisban a két felhasználónak dbo joga van (még jó, hogy nem sa joga az egész SQL szerverre)
6. Beraktam az alkalmazás fájljait a helyükre, visszatöltöttem az adatbázisokat (az élesen backup, itt restore), beállítottam ezeket a csoda felhasználókat.
7. Megpróbáltam elindítani a rendszert, kaptam két ronda warrning-ot és ennyi. Nem működik. Ekkor nekikezdtem a php.ini reszelésének. Néztem az eredetit. Javítottam az újat, majd minden egyes lépésnél kipróbáltam, hogy működik-e már. Nem működött, ráadásul egy rakás olyan beállítást találtam, amiről az ini azt írja, hogy ne használd, mert biztonsági probléma. Végére értem a beállításoknak. Addigra a két warrning-om is eltűnt, csak egy üres fehér böngésző ablak jött. A szoftver szuper. Nem logol sehova, még véletlenül sem ad infót arról, hogy mi a baja.
8. Kicsiit tanácstalan lettem, elkezdtem hívogatni a fejlesztőt, hogy mi lehet a gond. Egyetlen infót kaptam. Dobjam ki a 4.4.9-es PHP-t és használjak 4.3.3-at, mert későbbiekkel nem garantálnak semmit, és különben sem fog működni. Arra a kérdésemre, hogyan lehet hibát keresni, vagy logolást bekapcsolni, nyente, nyista, nothing. Konkrétan mintha fel se tettem volna a kérdést, elengedték a fülük mellett.
9. Elkezdtem reszelni a php.ini-t és az IIS hiba riportolást. Valahogy nagy nehezen jött egy access denied az adatbázisra. Kicsit turkáltam és rájöttem, hogy én vagyok a hülye. Elfelejtettem a felhasználókon az SQL password policy-t kikapcsolni így ki tudja miért meg akarta változtattatni velem azt a fönti kifejezetten "erős" jelszót. Renderaktam, elindult, béke. Ja persze működik a 4.4.9-es php-vel.
Az első feladat teljesítve, jöhet a második. Csináljunk kétgépes, x64-es rendszert.
10. Végeztem némi x64-es tanulmányt a PHP kontra IIS tárgykörben. A 4.x-es PHP-ből nincs, az 5.x-es PHP-ból nincs stabil x64-es implementáció. Az IIS-hez van egy beállítás (http://technet2.microsoft.com/windowsserver/en/library/36f8964c-cf86-44cf-94a4-2873ad0d175f1033.mspx?mfr=true) amitől a 32 bites PHP menni fog rajta, csak arra kell vigyázni, hogy ne legyen 64 bites web alkalmazás mellette. Miután ilyen nincs, gond sem lesz. Legalábbis én így gondoltam.
11. Összeraktam az egészet a 64 bites gépen és nem működött. Kerestem össze-vissza a neten, semmi értelmes dolgot sem találtam. Eléggé egyértelművé vált, hogy az SQL eléréssel van valami gáz. A gyanúsítottam a 32/64 bit volt. Arra gondoltam, hogy a talán a 32 bites php alkalmazás próbál valami 64 bites SQL kliens dll-t piszkálni, ami nem megy neki. Próbáltam mindenféle SQL native klienst, meg hasonlókat felrakni, semmi sem segített.
12. Arra gondoltam, hogy üres lappal kezdek. csináltam egy 32 és egy 64 bites virtuális gépet, azonos beállításokkal, mind a kettőt a távoli SQL-re konfigurálva. Láss csodát egyik sem ment. Közben találtam valami adatbázis teszt php-t és az sem ment rajtuk. Hoppá! Akkor nem is biztos, hogy a 64 bittel van a gond. Keresztpróba:
Az éles szervert (régi Akela virtualizált változat) átállítottam az új adatbáziskezelőre. Az eredmény: félsiker. Bejelentkezni ugyan be tud, tehát onnan jó az adatbázis kapcsolat, de működni, nem működik, mert csodálatos szoftverünk tartalmaz egy kriptográfiai konfigurációs kódot, ami azonnal invalid lesz, ha belenyúlok a config.php-be (közli, hogy read only az adatbázis). Márpedig belenyúlok, mert máshol van az adatbázis (megint tetten érhető, hogy a saját rendszerem iszonyúan védem, az ügyfél adatait pedig …)
Leszűrve a dolgot valami gond van a távoli adatbázis eléréssel, méghozzá kliens oldalon, ami a régi gépen jó, az újakon pedig nem. Újabb keresgélés a neten. Ezúttal már találok némi értelmes infót. A tettes, jó eséllyel egy NTWDBLIB.DLL nevű egyed. Megnézem az éles gépen és az új teszten és a cliconfig-ban látszik is a különbség, csak eddig nem szúrtam ki.
Miről is van szó? A szerkezet, ami hiányzik Network DB Library néven szerepel és utoljára az SQL 2000-ben volt megtalálható. A 2005-ön is használható, mint kliens, csak éppen se az operációs rendszerben se a SQL 2005-ben nincs benne.
13. Akkor szerezzünk egy ilyen DLL-t. Hosszas keresgélés után kiderül a dokumentációból, hogy az SQL 2000-hez van egy redistributable komponens (a nevére már nem emlékszem) ami tartalmazza. Elő is szedem valahonnan, mert külön nem letölthető. Először is valamiért nem volt hajlandó települni, másodszor pedig szétszedve a telepítőt, nyomát sem találtam a fenti dll-nek. Végül kínomban leszedtem az SQL 2000 SP4-et és kibányásztam a dll-t belőle.
Ezek után azon műsorozott a cliconfig, hogy az msvcr71.dll hiányzik. Ez ugye a Visual C++ 7.1 futtatókörnyezet egyik darabja. Ez ugye a Visual Studio.NET 2003 csomag része. Megpróbáltam szerezni egy ilyen futtatókörnyezetet. Ez sem töltehtő le a Microsofttól. Az egyetlen dolog, ami ezt hivatalosan tartalmazza az a .NET Framework v1.1 SDK. Na remek. Ez azt jelenti, hogy egy production serverre, rakjak fejlesztő eszközt. Az a gyanúm, hogy ez sem kifejezetten felel meg a biztonsági irányvonalaknak. A vége az lett, hogy a többi szükséges dll-t is az SQL 2000 SP4-ből vadásztam ki.
14. Kipróbáltam. Elindult. Pontosabban csak read only módban, mert rossz volt a config.php kódja. Elküldtem a fejlesztőnek, hogy ez a végleges, tessék a kódot belerakni. Ez volt csütörtökön. Péntek délután meg is jött a kód (bonyolult lehet az a kódgenerálás). Szombaton otthonról ki is próbáltam. Nem ment, visszaküldtem, hogy nem nyert. Hétfőn valamikor délelőtt végre megjött a működő konfigurációs állomány.
Végre béke van, működik. Boldog nem vagyok, mert a biztonsági lyukakból csak az adatbázis jelszót sikerült betömni, a többi változatlanul ott van, él és virul. Még jó, hogy ezt az alkalmazást nem kell a net felé publikálni.
suf 