MNB – Árfolyamok – CRM

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
Reklámok
Kategória: Dynamics CRM | 14 hozzászólás

Deployment – Korábbi cikkek

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
Kategória: Windows Installer | 20 hozzászólás

Deployment – MSI – Microsoft .Net FRamework v1.1 + SP1 + Hotfix

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:
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):
 
@echo off
setlocal
set MSI_SOURCE_PATH=C:\DATA\MSI Packages\Source\Microsoft .NET Framework v1.1 EN
rd /S /Q "%MSI_SOURCE_PATH%\Package"
 
"%MSI_SOURCE_PATH%\dotnetfx.exe" /Q /C /T:"%MSI_SOURCE_PATH%\Expanded"
msiexec /quiet /a "%MSI_SOURCE_PATH%\Expanded\netfx.msi" TARGETDIR="%MSI_SOURCE_PATH%\Package"
 
md "%MSI_SOURCE_PATH%\Patch"
"%MSI_SOURCE_PATH%\NDP1.1sp1-KB867460-X86.exe" /Xp:"%MSI_SOURCE_PATH%\Patch"
msiexec /p "%MSI_SOURCE_PATH%\Patch\S867460.msp" /a "%MSI_SOURCE_PATH%\Package\netfx.msi"
rd /S /Q "%MSI_SOURCE_PATH%\Patch"
md "%MSI_SOURCE_PATH%\Patch"
"%MSI_SOURCE_PATH%\NDP1.1sp1-KB928366-X86.exe" /Xp:"%MSI_SOURCE_PATH%\Patch"
msiexec /p "%MSI_SOURCE_PATH%\Patch\M928366.msp" /a "%MSI_SOURCE_PATH%\Package\netfx.msi"
 
rd /S /Q "%MSI_SOURCE_PATH%\Expanded"
rd /S /Q "%MSI_SOURCE_PATH%\Patch"
endlocal
 
Kategória: Windows Installer | Megjegyzés hozzáfűzése

Deployment – Bevezetés

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.
Kategória: Windows Installer | Megjegyzés hozzáfűzése

Akela, avagy szeretünk PHP

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();
  ?>
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.
Kategória: Computers and Internet | 15 hozzászólás

A Licencing útvesztői

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!?
Kategória: Computers and Internet | 6 hozzászólás

Én és az FTP

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. Smile), 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. Sad
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.
Kategória: Computers and Internet | 8 hozzászólás