suf

Karácsonyi ajándékként megcsináltam a full-text feedet. Ezek után a költözés végleges (remélem). Tehát az új cím még1x: http://www.it-pro.hu/Blogs/tabid/94/language/hu-HU/Default.aspx

Már korábban írtam róla, hogy elkövettem egy ingyenes vírusirtót az Exchange 2007-hez. Most elkészült ennek az Exchange 2003-al vagy IIS SMTP szerverrel használható változata. Mind a kettő megtalálható a http://www.clamagent.org -on.

Van néhány technikai nehézségem az új bloggal. A komment nagyon apróbetűs, és nem tudtam megoldani a full text feedet egyenlőre. Amíg ezek nem lesznek rendbetéve addig ide is, oda is kiteszek mindent.

Nem, nem akarom mégegyszer felhívni a figyelmem az angol nyelvű blogomra a http://www.clamagent.org -on.

Másról van szó. Költözöm. Az elmúlt néhány évben jó szolgálatot tett a live-os blog. Most szépen lassan elköltözöm. Lehet, hogy még írok ide, de ritkán. Sok okom van, hogy miért jutottam erre az elhatározásra, de álljon itt a legfontosabb: CSAK.

Szóval, a saját írásaim a jövőben itt lesznek elérhetőek:

Kicsi is, savanyú is, nincs is még kész, de az enyém.

Ja ma pont írtam oda valami vicceset.

Folytatva az előző bejegyzést (ClamAgent), ma útjára indítottam az angol nyelvű blogomat itt.

Elkészült a legújabb elkövetményem. Ezt most remegő kézzel adom közkézre, mert ilyet még nem csináltam. Mit is? Portált. Pontosabban írtam egy programocskát (ilyen már volt) és ehhez készítettem egy web protált (ilyen még nem volt).

Ha valakit érdekel, hogyan lehet az Exchange 2007-hez ingyenesen vírusirtót fabrikálni, akkor az itt talál megoldást:

Ez a bejegyzés elköltözött. Jelenleg itt található:
http://www.it-pro.hu/Blogs/tabid/94/EntryId/24/MNB-Arfolyamok-CRM.aspx

Az automata telepítőkkel kapcsolatban korábban már írtam néhány dolgot. Most ide összeszedem ezek elérhetőségét:

 

Valamikor a múltban a Skype-nak még nem volt MSI telepítője:

 

WAIK és WDS:

 

Az MSI gyártás eszközei (ennek a cikknek el fogom készíteni az aktualizált változatát):

 

Paint.NET MSI:

 

Adobe CS3:

 

A fenti cikkek egy része még biztosan elő fog kerülni, némi ráncfelvarrásra

Kezdjük el az MSI csomaggyártást!

Az első csomag amit elkövetek az a Microsoft .NET 1.1. Ha már csomagot csinálok, akkor a mindenféle később kiadott javításokat is belerakom.

Ehhez a történethez három dolog kell az internetről:

Microsoft .NET Framework 1.1
http://www.microsoft.com/downloads/details.aspx?familyid=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en
Microsoft .NET Framework 1.1 Service Pack 1
http://www.microsoft.com/downloads/details.aspx?FamilyID=a8f5654f-088e-40b2-bbdb-a83353618b38&DisplayLang=en
Microsoft .NET Framework 1.1 Service Pack 1 Hotfix KB928366
http://www.microsoft.com/downloads/details.aspx?FamilyID=281fb2cd-c715-4f05-a01f-0455d2d9ebfb&DisplayLang=en

Ha ezeket letettük egy könyvtárba, akkor a következő script le fogja gyártani nekünk az MSI telepítőkészletet (a letöltött fájlok elérési útvonalát természetesen módosítani kell):

 

 

 

 

 

Az elmúlt másfél, két év során rengeteget foglalkoztam automatikus telepítéssel. Ennek során összeraktam egy infrastruktúrát, ami rengeteg küzdést, némi programkódot, de leginkább rengeteg információt tartalmaz. Ezt az egész csomagot, felépítése során nem dokumentáltam, mára viszont égetővé vált ennek a hiánynak a pótlása. Arra gondoltam, hogy a dokumentációt rögtön publikálom is. Ezen a blogon, sok részben fogom közzétenni.

A mai irány nagy vonalakban az automatikus telepítésre az, hogy csinálunk egy szabványosított mintagépet, erről készül egy image, amit egy központi eszközből, mondjuk WDS-ből (Windows Deployment Services) letolható a kliensre (vagy akár szerverre). Ennek a megoldásnak vannak előnyei és hátrányai. Az elsődleges előnye, hogy nagyon gyors. Egy telepítés csak néhány percet vesz igénybe, ráadásul bizonyos technológiákkal (multicast deployment) ezen még lehet tovább gyorsítani.

Ezt a telepítési elvet és nem különösebben szeretem. Ennek több oka van:

- Rosszul adaptálható egy heterogén környezetben (szedett-vedett géppark)

- Rugalmatlan. Nem tudjuk a felhasználónak biztosítani a választás szabadságát (a megengedett alkalmazásokból milyen csomagot vállogat össze magának)

Ebből adódóan és más utat szoktam követni. Nem imageből építem a gépeket, hanem nulláról telepítek, lehetőleg úgy, hogy a legkevesebb kézi beavatkozásra legyen szükség. Majd ezek után központilag publikálom a felhasználó által telepíthető, és az automatikusan települő alkalmazásokat.

A rendszer felépítés során az volt a célom, hogy az operációs rendszeren és a telepítendő alkalmazásokon túl, ne legyen szükségem kereskedelmi szoftverre. Ebből adódóan megoldás, a WDS-t, a Windows PE-t, a Microsoft Installert és a Group Policy-t tartalmazza.

A telepített kliens operációs rendszer a Windows XP. Későbbiekben elképzelhető, hogy mást is bele fogok gyűrni ebbe az infrastruktúrába.

Ha végiggondolom, több csoportba tudom szedni a rendszer elemeit, a cikkeket is ezek köré fogom csoportosítani:

- Kliens operációs rendszert építő környezet

- Windows PE-t építő környezet

- Meghajtó könyvtár

- GPO konfiguráció és WMI szűrők

- MSI csomagok

A cikkek valószínüleg össze-vissza fognak érkezni, attól függően, hogy a saját infrastruktúrámban nekem éppen mit kell megvalósítanom, a már elkészült dolgok közül mit kell frissítenem.

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:

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.

Az elmúlt időszakban az időm egy részében Microsoft Dynamics CRM bevezetéssel foglalkozom (na álljunk meg egy pillanatra, mielőtt valaki ilyesmit feltételezne: NEM ÉRTEK A MICROSOFT DYNAMICS CRM-HEZ !!!), egy külső cég vezeti be nálunk és én vagyok a belső IT és bizonyos mértékig üzleti támogatója a történetnek.

Az eset kb. két hete történt. Eljutottunk addig a fázisig, hogy a teszt rendszeren való bohóckodás kezd a végéhez érni és az első fázis beállításait, fejlesztéseit be kellene izzítani az éles rendszeren. Ehhez kellene éles rendszer. Neki is álltam telepíteni, amúgy parasztosan/magyarosan. Doksit nem olvasunk, mert minek, next-next-finish oszt jól van (végül persze nem volt ilyen egyszerű a telepítés maga, de van némi múltbéli gyakorlatom, így megugrottam az akadályt). El is indítottam a telepítőt, ami kapásból közölte, hogy termékkulcs kéne.

Semmi gond, fejest ugrok a safe-be, elővakarom a licence papírt, irány az eopen (https://eopen.microsoft.com), mert ugye volume licence-ről van szó. Belépek, megadom a szükséges infókat, látom is a licence-t. Olvasom alatta az apróbetűst amiben közli velem, hogy regisztrálnom kell itt: http://www.microsoft.com/BusinessSolutions/MBSRegistration, mert addig nem tudom használni. Ok semmi gond, megyek a web oldalra, pontosabban mennék, mert az bizony nem létezik.

Némi kutakodás után kiderítem, hogy az oldal itt van: https://mbs.microsoft.com/mbsregistration

Regisztráltam is a licenszet. Küldtek egy e-mail-t, hogy a https://mbs.microsoft.com/customersource weboldalon tudom igénybe venni a licence-hez kapcsolódó szolgáltatásokat. Felmentem az oldalra, hozzárendeltettem a passportomat a licence-hez. Hosszas keresgélés után megtaláltam a termékkulcs kéréshez tartozó aloldalt. Itt közölte a rendszer, hogy adjam meg az e-mail címem, oda el fogják küldeni annak az oldalnak a címét, ahonnan hozzá tudok jutni a kulcshoz. Megadtam a címem, kaptam egy levelet. Rákattintottam a linkre a levélben. Erre visszakerültem ugyanarra az e-mail címkérős oldalra. Most tüzetesebben elolvastam az apróbetűs részt is ami tudatta velem, hogy miután volume licence-em van, a kulcshoz a volume licencing oldalon (eopen) fogok hozzájutni.

A kör bezárult. Licence nincs.

Hívtam a beszállítót, hogy most mi van. Ők sem tudtak kapásból válaszolni, de volt egy olyan feltételezésem, amivel egyetértettek, hogy esetleg várni kell egy napot mert talán kézzel rakják ki a kulcsot.

Vártam.

Nem egy napot, hanem ötöt, mert épp jött az Október 23.-ai hosszú hétvége. Hétfőn felhívtam a beszállítót, hogy nem történt semmi. Addigra nekik már volt némi információjuk. Azt mondták, hogy töltsem le azt a telepítő csomagot, ami az eopen oldalon van, mert valamelyik ügyfelüktől (és nem a Microsofttól !!!) kapott információ szerint az egy prekeyed telepítő.

A fenti dolgot kicsit kétkedve fogadtam, de arra gondoltam, hogy nem veszthetek semmit. Letöltöttem, és láss csodát, ez valóban egy működő prekeyed telepítő.

CRM felment, örülünk!

Ugye milyen egyszerű dolog ez a licencing!?

A történet nagyjából két éve kezdődött.

Én is mint sokan mások kénytelen vagyok FTP szervert üzemeltetni. Miután elsősorban Microsoft technológiákat használok, ezeket ismerem valamilyen szinten, a feladataimat elsősorban a Windows beépített szolgáltatásaival próbálom megoldani. Ebből adódóan FTP szervernek is a Windows beépített FTP szerverét választottam (Itt még az IIS6 FTP-ről beszélek). Ennek ugyanakkor nagyon nem vagyok elégedett a biztonságával (FTP és biztonság, fábol vaskarika, tudom): Nyílt jelszóküldés, AD Authentikáció (tehát olyan accountal is lehet authentikálni amit én nem szeretnék), stb. Végigjártam az összes lehtséges biztonsági reszelést, de semelyik nem oldotta meg azt a problémát, hogy szótár alapon folyamatosan próbálkoznak a jelszó megszerzésével. Szerettem volna egy megoldást arra, hogy a szerver tiltsa, azokat az IP-ket melyekről mondjuk 5 hibás bejelentkezési kísérlet történik. Beépített megoldás nem volt erre, így fejlesztettem egyet (ezt a megoldást, mint forráskódot, telepíthető eszközt a későbbiekben leírtak miatt nem fogom közölni).

A megoldás lényege az volt, hogy beállítom az FTP szerveren, hogy ODBC-n egy oda telepített SQL 2005 Express adatbázisba logoljon, amire került egy trigger, ami figyelte a sikertelen bejelentkezéseket, és egy IPSEC szabállyal letiltotta a forrás címet, ha a kísérletek száma meghaladta a limitet, továbbá létrehozott egy scheduled task-ot ami 24 óra elteltével törölte az IPSEC szabályt feloldva ezzel a tiltást.

Céges átszervezések és időhiány miatt ez a megoldás sosem került bevezetésre (szerencsére közben nem törték fel a szervert). Néhány héttel ezelőtt az informatikai átalakításunk miatt, úgy gondoltam, hogy újra nekiugrok az FTP kérdésnek. Miután 2008-at írunk, az IIS7-hez külön letölthető FTP szervert választottam. Ez ugyen tud például SSL-es FTP-t (ez most SFTP vagy FTPS, így hirtelen nem tudom fejből, keverem a kettőt. ), ugyanakkor ez a biztonsági megoldás nem ad választ a fenti prolémára. Ezért nekiláttam, hogy az ODBC-s, SQL-es, IPSEC-es megoldásomat implementáljam erre a szolgáltatásra.

Nem sikerült.

Miért? Ezen piszokul meglepődtem, ez ugye egy nagyban "fejlesztett" szolgáltatás. És tényleg. Nagyot fejlesztettek rajta. Kifejlesztették belőle az adatbázisba logolás lehetőségét.

Kicsit félretettem megint az FTP kérdést, és pénteken elővettem újra. Félretettem a Microsoftos megoldásokat és elővettem a FileZilla FTP szervert (ez ugye még mindíg egy ingyenes sztori). És láss csodát! Ez adatbázisba logolni ugyan nem tud, de tudja mind az SSL-es FTP-t mind az IP cím tiltást (és mindkettőt külső segítség nélkül).

Azt, hogy mennyire lesz használható a gyakorlatban, még nem tudom, de a jelek bíztatóak.

Újabb cikk az Email és a Detektívek oldalon:

Azt hiszem, már sokunkat idegesített, hogy kaptunk egy védett Adobe PDF formot amit csak kitölteni és kinyomtatni lehet, de elmenteni, ne adj isten olyasmit szerkeszteni benne, amit az elkövető fixen rakott bele, nem lehet.

Én ma egy ilyen esetbe futottam bele.

Van egy formanyomtatványom, amit tavaly kaptam. Ma használnom kellett volna. Ki is töltöttem, de mire a végére értem és be akartam írni a dátumot, szomorúan tapasztaltam, hogy a 2007-es év vasalva található meg benne.

El kezdtem gondolkozni, mi tévő legyek. A következő lehetőségek kerültek elő:

1. Kérek a dokumentum tulajdonosától egy aktualizált formot. Ezzel két bajom van: a/ ha reggel 5-kor kérek ilyet e-mailen, legjobb esetben is csak 9-után kapom meg. b/ Újra ki kell töltenem az egészet.

2. Kinyomtatom így és jön a javítófesték, elvégre faxon kell elküldenem. Na ne már! Infomókus vagyok és nem titkárnő.

3. Kinyomtatom XPS-be és majd csak kezdek vele valamit. Nem lehet nagy ügy kijavítani egy számot egy XML-ben (Gondoltam én. Vagy mégis?)

A harmadikat választottam.

Neki is ugrottam a dolognak. Elkészült az XPS, megnyitottam a notepadben, bináris szemét. Jájj!!!

Nézzük csak meg. Az első két karakter: PK. Ja, hogy ez valószínűleg tömörített, ugyanúgy, mint az Office 2007 formátumai. Zip-re átnevez, Vista hisztizik, hogy a kiterjesztést biztos meg akarom-e változtatni, mert, ha igen akkor szigorított ejnye-bejnye, igen, biztos akarom.

Kicsomagol.

Szokásos fastruktúra, elkezdek keresgélni, a Documents\1\Pages\1.fpage fájlban meg is találom a 2007-es dátumot.

Kijavítom. Visszarakom a Zip-be. Visszanevezem XPS-re. Kinyitom. Nem hiszek a szememnek. Maradt a 2007. Mi van???

Keresgélek össze vissza, sehol máshol 2007. Visszamegyek és nézem azt a sort, amiben a 2007 szöveg volt. Így néz ki:

Gyanus. Az az Indices mintha ASCII kódgyűjtemény lenne. A 21, a 2, a két 19 a 0, a 26 a 7, de mi a fülem az a 72? Mindegy. Kijavítom a 26-ot 27-re és természetesen a 2007 szöveget 2008-ra.

Megnézem az eredményt. Jó helyen járok, de nem működik. a 7-es helyett most egy kockát kaptam. Mégis van valami jelentősége annak a 72-nek? Egy negyed órán keresztül pakolgatom a számokat ide-oda sehogy se jó.

Ok, akkor gondolkozzunk fordítva. Fogom a notepad-et. Beleírom, hogy 2008, kinyomtatom XPS-be. Az eredmény:

Hoppá. Annak a 72-nek semmi jelentősége. Most veszem észre, hogy ott vessző van a számok között és nem pontos vessző. Akkor ez valami kitöltő, igazítás stb. lehet. Próbáljuk ki. Megnézem a 21;19;19;26 sorozattal, az eredmény 2007. Megnézem a 21;19;19;27 sorozattal, az eredmény 200 plusz a kocka.

Ezek szerint amikor az XPS-t rendereli a driver, a fontból csak azokat a karaktereket teszi bele amik szerepelnek a dokumentumban (hurrá tömörítés!).

Megnézem, milyen fonttal írták a szöveget. Olyan Verdana Bold formája van. Elő egy Word, teljes abc belekalapál, Verdana Bold beállít, XPS-be kinyomtat.

Kikeresem a font fájlt, kicserélem az eredeti XPS-ben. Eredmény: Haladunk, az XPS olvasó, mostmár az egész dokumentumot minősíti hibásnak.

Biztos kihagytam valamit a fontból.

Gondolkozzunk másképp. Mi van, ha nem kicserélem a fontot, hanem berakom plusz darabként és csak az egy 2007-8-es szövegnél adom meg az új fontot.

Tehát kicseérélem ezt:

Erre:

Nem túl rég hírt adtam arról, hogy a szakmai cikkeim az emaildetektiv oldalon fognak megjelenni. Azóta nem túl sok időm volt írni. Arra gondoltam, hogy amikor ott megjelenik egy cikk, itt is hírt adok róla. Íme:

Akit érdekel ez a blog esetleg kérdezheti, hogy miért írok ilyen ritkán, és miért nincsenek szakmai cikkek.

Nem, nem nyaralok, igen, csinálok szakmai munkát. Dokumentálni, publikálni, fórumot, levlistát olvasni, na erre kb. 0 időm van. Ezt most lelkiismeret furdalások közepette írom, mert mástól veszem el az időt. De már nem bírtam ki, ez a sztori már nálam is kiverte a biztosítékot. Ilyenekkel megy el az időm.

A történet valamikor három éve kezdődött...

 

 

Három évvel ezelőtt két cégünk, akiknek az informatikája/pénzügye közösen működött úgy döntött, hogy új pénzügyi rendszert vezet be. E rendszer kiszolgálására vettem egy új szervert. Miután a két cégben folyamatos súrlódások voltak, hogy mi kié, úgy döntöttem, hogy a gépek nem egyik vagy másik cég nevéből következő neveket kapnak, hanem a Dzsungel könyve lesz az alap. Így kapta a szerkezet az Akela nevet.

A rendszerek telepítése meg is történt. Működött is, majd jöttek a problémák:

1. Némi frissítés telepítése után, csak sokszori noszogatásra volt hajlandó elindulni.

Majd némi idő elteltével:

2. Egy leállítás után nem indult el. Újratelepítés, backupból visszatöltés lett a vége.

Egy költözés után:

3. Újra a 2. eset következett be.

A cégek szétváltak és Akela nálam maradt, visszaköltözött az én szerverszobámba. Majd újabb idő eltelte után:

4. Memória hibajelzés.

Az egyik memória modul vissza a nagykerbe, csere, a gép megy, mint a kisangyal.

Eltelt vagy 2 év ebben az idilli állapotban.

Nemrég elkezdtem a régi domain struktúránkat felszámolni. Ennek kapcsán a pénzügyi rendszert virtualizáltam (Hozsána néked vmWare Converter)...

 

 

Hopp, miért is vmWare Converter? Én alapvetően a Microsoft virtualizációs eszközeit használtam. vmWare Server azért született, mert épp bevezetünk egy Microsoft Dynamics CRM rendszert és a szállító a teszt rendszert vmWare image formátumban adja át. Terveim szerint meg is szüntetném a vmWare-t, de jött ez a migrációs feladat. A következő lehetőségeim voltak:

1. Keresek valami ingyenes p2v migrációs eszközt (kerestem, nem találtam jót)

2. Végigcsinálom ezt mégegyszer (there is no fucking way)

3. Megveszem és megtanulom a System Center Virtual Machine Manager használatát (a 2. alapján nem picit fáztam attól, hogy megint több napos szívás lesz belőle)

4. vmWare Converter.

Ez utóbbi lett. Most jöhetne egy jó szaftos, hogyan szívtam a konverzióval cikk. Nem jön.

- Csináltam a konverzióhoz egy virtuális szervert (3 kattintás, két perc)

- Felraktam rá a vmWare Converter-t (Next, Next, Finish)

- Felraktam az Akelá-ra a Converter Agent-et (Next, Next, Finish)

- Leállítottam az SQL Sever-t (a biztonság kedvéért)

- Elindítottam a Converterről a konverziót (néhány egyszerű, értelmes paraméter megadása)

- A kész virtuális gépet átraktam a vmWare szerverre.

- Némi konfiguráció után, a régit lelőttem, a virtuálist elindítottam, a vmAdditions felraktam

Működik, béke van.

 

Na jól elkalandoztam az eredeti témáról, akkor most vissza.

Kezemben az Akela hardware, kezdjünk vele valamit.

Először is nekikezdtem a BIOS upgrade-nek. Pontosabban 4 db különböző firmware upgrade-nek amit különböző helyekről lehetett előadni. Agyrém, fél nap.

A cél, hogy CRM front-end-et csináljak belőle. Az átalakítások során kiderült, hogy ez egy 64bit-es vas (eredetileg erről fogalmam sem volt). Mint ilyen gondoltam jó lenne, ha a 2 gigánál némileg több memóriát és x64-es Windowst kapna. Benyúltam a fiókba és beleraktam az első két DDR2-es modult ami szembe jött.

Meg se nyikkant.

Kísérleteztem mindennel, ami a kezem ügyébe került, semmi.

Ok, akkor nézzük meg, mit mond a sillabusz. Találtam a gyártónál egy (nem hazudok) 33 oldalas doksit ami csak a tesztelt memória konfigurációkról szól. Ki is vadásztam belőle néhány típust, amit esetleg be tudok szerezni. Találtam is a nagykerben egy pár 2 gigás modult ( DDR2-400 ECC Registred, Dual Rank ).

Bedugtam a gépbe, mellé a meglévő két 1 gigás mellé ( DDR2-400 ECC Registred, Single Rank ). Nem indult el.

1 gigások ki, csak a két 2 gigás marad. Elindul.

Ezzel hagytam is a dolgot, mert mennem kellett haza.

Másnap jön az ember CRM-et telepíteni. 10 perccel előtte lemegyek a szerver szobába, bekapcsolom a gépet. Látom, hogy összesen 2 giga memóriát mutat. Hopp, 4 van benne. Szétszedem, pakolászom a memóriákat össze vissza. Már el sem indul.

Megnézem közelebbről a memória foglalatokat: az egyiknek begyűrődött két lába. Jól van, hülye vagy Gömöri, ezt kinyírtad.

Ember jön. Megmondom neki, hogy a szerver halott, tehát mehet haza. Megkérdezem, hogy mit csinált volna. Kiderül, hogy csak next-next-finish. Ezért nem kell mégegyszer jönnie, ezt én is meg tudom csinálni.

Vissza a szerverhez.

Hívom a nagykert, hogy az alaplap döglött, kéne csere (ugye, egy 3 éves cuccról van szó).

Ember a nagykerben (nem a szokásos, akivel beszélni szoktam): - Garanciális?

Én: - Nem.

Ember: - Akkor e-bay.

Én: - Jó. (Anyád)

 

Elkezdtem gondolkozni, keresgélni, kiderül, hogy mégis van még egy hónap a garanciából.

Megint hívom a nagykert. Sokszor. Már nincs kedvem, a megszokott emberen kívül mással beszélni, ő pedig ebédel. Sokáig.

Előkerül, előadom neki az ügyet. Garanciális csere. Leadom az alaplap himlőújraoltási bizonyítványszámát. Megrendelik.

Várok két napot.

Felhívom a nagykert, kérem az embert.

Szabadságon, majd holnap lesz.

Megpróbálom kideríteni a többiektől, hogy mi van az alaplappal.

Nem tudnak semmit.

Másnap.

Hívom az embert.

Ja, hogy az alaplapom, az már megjött (Hú de gyorsak vagytok. Azért lehetett volna telefonálni, hogy ott van, de mindegy).

Emberem elmegy érte, elhozza.

Beszerelem.

Belerakom mind a 6 giga memóriát.

Bekapcsolom.

Elindul.

Látja a 6 gigát.

Hurrá, de miért lila a képernyő?

Ekkor elkezdtem megmozgatni a kábeleket. Ki is cseréltem. Semmi. Nézem az alaplapon a VGA csatlakozót. Mintha kicsit beljebb állna. Megigazítom. Semmi. Még mindig lila.

Kínomban kiszerelem az alaplapot. Tüzetesen megnézem a VGA csatlakozó másik oldalát. Ezt nem hiszem el: az egyik láb nincs beforrasztva. Ilyen nincs. Most küldjem vissza megint a gyártónak, hogy szart küldtek?

Eddigre már kicsit ideges lettem a sztoritól. Előkaptam a forrasztópákát, beforrasztottam, visszaszereltem és láss csodát, meg lett a zöld szín is. Boldogság.

Na, itt hagytam abba a géppel való foglalkozást. Még végig kell csinálnom újra a firmware upgrade-eket, és fel kell raknom a CRM-et.

Ha lesz vele gáz, akkor folytatom a történetet.

Vége.

Egyenlőre.

Mint sokan mások én is iPod felhasználó vagyok. Hogy ebből lelkes-e? Igen is meg nem is. Lelkes, mert a cucc jól néz ki és jó minőségű anyagokból készült. Ezért mosolyognom kellene, de ez a mosoly kicsit kínvigyorra sikeredett, mert:

1. Az iPod vételre az a tény kényszerített rá, hogy az autómba ez volt az egyetlen beszerelhető mp3 lejátszó.

2. Az iPodra felpakolt cuccokat az iTunes képtelen a gépre visszatölteni (tudom, hogy van erre a piacon alkalmazás, de akkor is)

3. Sokadrendű állampolgárok vagyunk: az iTunes Store szempontjából a térképen sem vagyunk rajta.

Most aki nagy Apple rajongó felhördülhet, hogy: De kérem, már van iTunes Store Magyarország!!!

Igaz! Ma nekiálltam a feleségem iPod Touch-át frissíteni a 2.02-es szoftverre, amikor is az iTunes közölte, hogy ez bizony fizetős lesz. Egy életem, egy halálom, megpróbáltam csinálni egy Magyar accountot - és láss csodát - sikerült!!!

Ezek után el kezdtem nyomozni, hogy ez most újdonság, vagy csak én nem vettem észre, hogy van egy ideje.

Én voltam figyelmetlen. Most rá is találtam a linkre:

Na ezen, ha lehet még jobban felhúztam magam. Hú de boldog vagyok!!! Vehetek frissítéseket, szoftvereket!!! Maga a csoda!!!

Ja, hogy tartalom (zene, film, stb.) nincs, hát erre már nem mondok semmit...

 

A fenti szöveget tegnap írtam le. Írtam hozzá egy jó másfél oldalas listát. A listában a múltnak nyoma sem volt, csak a teendőknek címszavakban. Majd elsodort a nap, tárgyalásokra rohangásztam, és a nap végén elmentettem a listát. Rájöttem, hogy ilyen listákat írogatok évek óta, majd elrakom őket valahova, és a listáktól függetlenül megcsinálom, ami épp eszembe jut.

Valami rendszert kellene vinnem az életembe. Többször próbáltam az Outlook ToDo-ját használni, de valahogy nem áll igazán kézre. Most megpróbálkozom valami mással.

Pontosan ezzel:

 

Meglátjuk...

Itt: http://gzoli.spaces.live.com/blog/cns!F9E7FFBC4B3008EB!909.entry írtam, hogy nem tudtam beüzemelni a SkyDrive-ot mert Magyarországon vagyok. Ma olvastam itt: http://computerworld.hu/5-gigabajt-internetes-tarhely.html, hogy végre nálunk is elérhető. Kipróbáltam, működik. Talán csak nem kezdünk rákerülni a térképre?

Egy pár nappal ezelőtt Petrényi Józsi elindította az Email és a Detektívek nevű oldalát, ahol társszerzőként szerepelek. Ezentúl, az Exchange-el kapcsolatos írásaim ezen az oldalon fognak megjelenni, valamint a www.gomori.hu -ról és erről a blogról a szerintem közérdeklődésre számot tartó cikkeimet összegyűjtve, aktualizálva meg fogom jelentetni.

Köszönöm a lehetőséget Józsinak, valamint Gabának aki helyet ad ennek az oldalnak.

Elérhetőség:

 

Hát kétlem, hogy 2008-ban ilyet még szabad egy Microsoft méretű cégnek elkövetnie. Hahó! Microsoft! Felejtsük már el, hogy a világ csak a 437-es kódlapból áll!

 

A múlt héten Seattle-ben voltam a Microsoft 2008 MVP Global Summit nevű rendezvényen. A keynote előadáson Steve Balmer megkérdezte a hallgatóságot, hogy ki használ keresőnek Live Search-öt. Lanyha 10-20%. Google-t. Kb 80-90%. Yahoo-t kerek nulla. Senki sem tette fel a kezét. Ezen az úr nagyon megdöbbent. Megvenni egy céget cirka 45B$-ért akinek a termékét a saját szakértőid egyáltalán nem használják. Háát...

Volt még egy mondata amin elgondolkoztam. Megkérte a hallgatóságot, hogy egy hétig próbálgassa a Live keresőt. Ezen elgondolkoztam. Miért is ne.

Ma egy kolléga nyamotatási problémája miatt elkezdtem keresgélni internet printing ügyben. A google erre a kérésre:

http://www.google.co.uk/search?hl=en&q=windows+internet+printing+protocol&meta=

Második helyen kidobta ezt a linket:

Ezek után gondoltam kicsit célzottabban keresek. Bementem ide: (a cikk címe: Overview of Internet Printing in Windows 2000)

És rákerestem erre (Internet Printing):

Kaptam egy nagy büdös semmit. Még a fenti cikket sem. Ha jól gondolom, a Microsoft saját keresői alatt legalábbis a Live Search motorjának kellene lennie. Ezek után, hogyan vegyem rá magam az egy hetes áttérésre?

Az elmúlt néhány hétben újabb és újabb próbálkozásokat tettem a szoftverfrissítésre - eredménytelenül. Próbáltam Vista-ról, próbáltam XP-ről, próbáltam brick üzemmódban (megvártam, amíg a patkolt firmware féltéglát csinált a készülékből, és így felrakni a patkolatlan magyar szoftvert), semmi sem segített. Elkezdtem levelezgetni fórumokon hátha jön valami. Jó ideig nem volt semmi használható, majd ma megszületett a megoldás:

A kulcsszó, hogy nem 3435 byte-ot hanem 3431 byte-ot kell cserélni a firmware elején. Valahogy így néz ki:

1. Letöltjük azt a firmware-t amit bele szeretnénk rakni a telefonba

2. Letöltjük azt a firmware-t ami hajlandó beletöltődni a telefonba

3. Kicsomagoljuk mindkettőt (pl. 7-Zippel)

4. Fogunk egy Hex Editort és a 2-es pont firmware-ének első 3431 byte-játval felülírjuk az 1-es pont firmware-ének első 3431 byte-ját

5. A HPRUU-val letoljuk a módosított firmware-t a telefon torkán.

Hurrá!

Az összes probléma a dologgal, hogy ettől a készülék termékszáma nem változik meg, tehát ha kijön egy újabb firmware akkor azt is patkolni kell.

 

Néhány napja volt egy problémám az Exchage 2007 ActiveSync és a Nokia telefonok összekötésével. Akkor és ott felvetettem néhány lehetséges megoldást, ugyanakkor valójában megoldani nem sikerült a problémát, csak megkerülni.

Ma reggel, miközben egy ActiveSync-ről szóló prezentáció anyagát kezdtem előkészíteni, megtaláltam a megoldást. Az Exchange lehetővé teszi, hogy ne csak a Default Virtual Serveren legyen ActiveSync, hanem máshol is, ezzel a probléma megoldható.

Az egész történettel egyetlen probléma van, amit nem igazán lehet orvosolni. Ha a cégnek egyetlen publikus IP címe van, akkor a dolog nem fog működni, mert egy IP-n host headerrel különböző SSL tanúsítványokat nem kezel az IIS.

A lépések nagy vonalakban a következőek:

- Csináljunk egy ActiveSync (vagy bármi más) nevű website-ot
- Készítsünk hozzá az IIS Managerből egy sima tanúsítványt (SAN nélkül)
- A tűzfalon és az interneten tegyük meg a szükséges NAT és DNS beállításokat
- PowerShell-ből adjuk ki a következő parancsot: