IIS AppPool kontra Group Policy

Már írtam róla többször, hogy üzemeltetőként az egyik kedvenc IIS 7 újdonságom az Application Pool Identity, ami nagyon hasonló a Windows Server 2008 R2-ben bevezetett Managed Service Accountokhoz. Ez egy kiváló platform szolgáltatás, ám sajnos még nagyon új, ezért nem támogatja minden szoftver. Elszomorodtam, amikor ezt tapasztaltam az SQL Serverről és meglepődtem, amikor a csoportházirendekkel kapcsolatban is hasonló problémába sikerült belefutnom.

A minap ez fogadott az Application logban:

Source: SceCli

Event ID: 1202

Description: Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done.

Szerencsére még az eseménynapló bejegyzésben le van írva, hogy mit kell tenni ilyenkor, így hamar kiderült, hogy a Default Domain Controller Policy 4 helyen hivatkozik a DefaultAppPool és a Classic .NET AppPool fiókokra, amiket azután a csoportházirend érvényesítésekor nem tud SID-hez rendelni. Persze, hogy nem, hiszen azok a fiókok az IIS AppPool nevű “domainben” vannak, tehát ezt kellene odaírni elé, és máris megtalálná.

Eddig az elmélet, a gyakorlat azonban nem ennyire szép. Windows Server 2003-ról szerkesztve a GPO-t azonnal hibát kaptam, hogy nem találja az IIS AppPool\DefaultAppPool felhasználót. Nosza átültem egy Windows Server 2008 MMC elé, ott nem volt ilyen probléma, elhitte, amit mondtam neki. Csak éppen nem mentette el, ami úgy derült ki, hogy legközelebb megnyitva a GPO-t, megint hiányzott a “domain” prefix. Az a megoldás nyilván szóba se jöhetett, hogy törlöm az érintett csoportházirend beállításokat, maradt tehát a házirend (Default Domain Controller Policy) megszerkesztése Notepaddel, amihez a fájlt itt lehet megtalálni:

SYSVOL\tartomány neve\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

Ezután egy gpupdate /force kiadásakor már nem került bejegyzés az eseménynaplóba.

A dolognak két szépséghibája van:

• A GPO következő szerkesztésekor megint eltűnhet a tartomány előtag, méghozzá figyelmeztetés nélkül. Az érintett kulcsok a User Rights Assignment szekcióban találhatóak:
  • Adjust memory quotas for a process
  • Generate security audits
  • Log on as a service
  • Replace a process level token
• Ugyanez előfordulhat, ha szolgáltatás fiókoknál az NT Service előtag hiányzik (pl. NT Service\WdiSystemHost).

A jó hír, hogy Redmondban tudnak a hibáról és a KB974639, valamint a KB977695 szerint van is rá hotfix, amit egyedileg lehet igényelni.

Még egy rövid, de fontos kiegészítés a témához: miután egy házirendben vagy egy mappa ACL-ben hivatkozunk egy ilyen speciális fiókra, óvatosan az alkalmazás-készlet átnevezésével, mert utána megint nem fog működni a házirend és az ACL sem fog érvényre jutni. Kérdés, hogy ezt miből vesszük majd észre?

Technorati-címkék: IIS,Group Policy,security,Windows Server 2008 R2

Áttérés MVC 3-ra

Ahogy már korábban írtam róla, 10 napja megjelent az ASP.NET MVC 3 végleges változata. Az új verzió nagyon sok újdonságot tartalmaz, ezért nem is meglepő, hogy az előző verzióról történő átállás sem két kattintásos varázslós feladat. Szerencsére van néhány külső eszköz, amely segíthet ezt egyszerűbbé tenni.

Az egyik az ASP.NET MVC 3 Project Upgrade Tool, amellyel egy MVC 2 solution fájlt nyithatunk meg és migrálhatunk gyorsan MVC 3-ra. Az eszközt az ASP.NET csapat készítette, a működéséről részletesen Marcin Dobosz blogjában olvashatunk. Ugyanitt találunk útmutatót MVC 1 projektek frissítésére is.

Az egyik legnagyobb újdonság az MVC 3-ban (és egyébként az ASP.NET WebPages-ben is) a Razor view engine. Ám sajnos aki erre át akar állni, annak karakterről karakterre át kell írnia az ASPX oldalait, ami nem éppen szívderítő feladat. Ezen próbál segíteni Li Chen ASPX to Razor Converter projektje, amely a CodePlexen érhető el. Ez nem Microsoftos produktum, hobbiból készül, viszont a készítője előszeretettel használja is a saját projektjeiben, és saját bevallása szerint eddig elég jó eredményeket ért el. Egy próbát biztosan megér.

Aki mégis úgy dönt, hogy nem bízik a kitt-katt eszközökben és marad a kézi munkánál, annak mindenképpen célszerű elolvasnia az MVC 3 Release Notes-ban található Upgrading an ASP.NET MVC 2 Project to ASP.NET MVC 3 c. fejezetet, ahol pontosan leírják az áttérés lépéseit.

Technorati-címkék: ASP.NET,ASP.NET MVC

Egy DLL minden platformra

Tavaly írtam arról, hogy Silverlightból kezd zavaróan sok változat lenni, ami már csak azért is kellemetlen, mert a DLL-ek ettől újrafelhasználhatatlanná válnak. Ezen próbál segíteni a Portable Library Tools projekt típus, aminek a kimenete szintén DLL, csakhogy erre a fájlra hivatkozhatunk .NET 4, Silverlight 4, Windows Phone 7, XNA és XBOX 360 projektekből egyaránt. A BCL csapat egyelőre csak egy CTP változatot adott ki, ami letölthető innen.

Technorati-címkék: Silverlight,.NET,Visual Studio,Windows Phone

Could not load file or assembly (0x80131515)

Érdekes hibába sikerült ma belefutnom a Visual Studioval: egy projekt gyönyörűen fordult Debug konfigurációban, de amikor Release-ben akartam fordítani, az alábbi hibaüzenetet kaptam:

"SGEN: Could not load file or assembly ‘file:///C:\TFS\Ize\Bize\bin\MyLibrary.dll’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)".

Na, mondjon nekem valami olyan okot, ami miatt egy a References listában szereplő DLL-lel ez történik, de csak Release konfigurációnál!

A leírás alapján az ember elkezdhet az sgen.exe-re gyanakodni, megpróbálhatja engedélyezni távoli betöltést a loadFromRemoteSources attribútummal, esetleg elgondolkodhat azon, hogy mi is az a Generate serialization assembly opció a projekt tulajdonságai között, és hogy vajon melyik lehet a kedvező beállítása.

Pedig a megoldás ennél sokkal egyszerűbb: Jobb klikk a fájlon, Properties, Unblock:

Ez a gomb a háttérben a Zone.Identifier nevű streamet törli a fájlról, amit a VS egyébként észre sem vesz, sőt ha megpróbáljuk TFS-be checkinelni a változtatásokat, azt fogja mondani, hogy nincs mit. Tipikusan azon a gépen fog egyébként előjönni ez a probléma, ahova a neten talált kész library-t, például az AjaxControlToolkit.dll-t letöltöttük.

Technorati-címkék: Visual Studio,MSBuild

WebMatrix: Enter the Web

A mai nap különös jelentőségű a Microsoft platformon dolgozó webfejlesztők számára: ma ismerte be a Microsoft, hogy az ASP.NET nem egy bárki által hipp-hopp elsajátítható tákoló környezet, hanem egy bizony elég komplex platform, amibe beletanulni komoly erőfeszítéseket igényel. Szerencsére nem pusztán a tények beismeréséről van szó, hanem megoldást is kapunk a problémákra.

Most kezdődik az online is streaming adás formájában követhető Enter the Web esemény, ahol a Microsoft számos új technológiát jelent be, melyek jelentősen meg fogják változtatni az ASP.NET fejlesztők életét. Ma lesz elérhető az ASP.NET MVC 3, az IIS Express, az SQL Compact 4.0 és a WebMatrix, na meg a Web Platform Installer 3.0, ami mindezeket és a rakás külső gyártó által készített bővítményeket összefogja és teszi egyszerűen telepíthetővé.

Ez a számos remek termék egy nagyon hosszú fejlesztési folyamat eredménye (először több, mint 1,5 éve hallottam róluk), aminek a nulladik lépése az volt, hogy Redmondban végre felfogták, hogy a Microsoftos web platformra fejleszteni egyszerűen túl bonyolult. Önmagában minden technológia nagyon szép és nagyon érett, de ha valaki ezeket egyszerre és hatékonyan akarja használni, akkor nagyon sok alapismeretre van szüksége. Ezek a problémák sajnos nem csak a kezdőket (Microsoftos terminológiában “hobbistákat”) érinti, hanem konkrétan a profi fejlesztőket is. Ma elmondhatjuk, hogy a legfájóbb pontokra kapunk megoldást:

A fejlesztői keretrendszer

Az ASP.NET WebForms a megjelenésekor azzal tudott hódítani, hogy a webes fejlesztést közel hozta a desktop fejlesztéshez, méghozzá két nagyon fontos tulajdonságával: a vezérlők (controls) használatával és az eseményvezérelt programozás bevezetésével. Az üzenet az volt, hogy úgy lehet webalkalmazást készíteni, hogy szinte azt sem kell tudnod, mi az a HTTP, és ez gyakorlatilag igaz is. Azóta azonban nagyon sokat változott a világ, előtérbe kerültek olyan szempontok, amik a generált HTML kód teljes kézbentarthatóságát igénylik. Ha ASP.NET WebForms környezetben teljesen szabályozni szeretnénk a generált kódot, akkor ahhoz nagyon kell ismerni a WebForms technológia részleteit. Ezt a problémát akarta megoldani az ASP.NET MVC azzal, hogy a kimenet teljes vezérlését a programozó kezébe adta (és persze ezek mellett még sok egyebet is).

Az ASP.NET MVC egy kiválóan működő és gyorsan bővülő technológia, azonban van egy közös tulajdonsága a WebForms-szal: az MVC is meglehetősen bonyolult, ráadásul több szinten:

1. Bonyolult az MVC koncepció

Az MVC (és a WebForms) elvei bonyolultak, hosszú időbe telik, míg az ember megtanulja őket. Persze utána nagyon szép, strukturált, tesztelhető és karbantartható kódot írhatunk vele, de valóban szükség van erre a szofisztikáltságra minden szinten? A sarki kisállatkereskedés honlapjához tényleg kell modell, view és controller? Nyilvánvalóan nem. Megvan a helye tehát a kevésbé strukturált felépítésnek is, mert bizonyos esetekben az lesz az egyszerűbb. Ezt a megközelítést pedig úgy hívják, hogy ASP.NET WebPages.

2. Bonyolult a markup

A fejlesztőnek végeredményül egyfajta markup kódot kell írnia, ami azonban tele lesz olyan értékekkel, amik szerver oldalon generálódnak. Lássuk be, az ASP.NET WebForms és az MVC markupja valójában éppúgy spagetti kód, mint anno az ASP kód volt. Sőt, ugyanúgy spagetti kód, mint a PHP kód. A PHP sikere azonban bebizonyította, hogy ez a kevert kód nem is olyan rossz, mert nagyon gyorsan meg lehet tanulni és utána nagyon gyorsan el lehet készíteni. Ez tehát a jó irány, amit még azzal lehetne megfejelni, hogy az írandó kódot egyszerűbbé, rövidebbé, átláthatóbbá tesszük. Erre megoldás az ASP.NET MVC-vel és a WebPages-zel használható új Razor szintaktika.

3. Bonyolult a fejlesztőeszköz

A Visual Studio egy kiváló fejlesztőeszköz, tud mindent, amire egy .NET-es fejlesztőnek szüksége lehet. Azonban annak, aki először látja, hihetetlenül bonyolult. Sőt, aki már használja egy ideje, az is simán találhat minden héten egy új menüpontot, amire korábban még nem figyelt fel. Nem megoldás a Visual Studio Web Developer Express sem, mert bár kevesebbet tud, még mindig nagyon komplex fejlesztőeszköz. Kellene valami sokkal, úgy értem sokkal egyszerűbb, ami illeszkedik az előző gyors-és-egyszerű koncepcióhoz. Itt jön a képbe a ma megjelenő WebMatrix, aminek az elsajátítását ráadásul egy rövid és könnyen követhető, az alapoktól induló gyakorlatsorozat is segíti.

A webszerver

Az Internet Information Services mint webszerver, nagyon jól megállja a helyét a szervereken, sajnos azonban a fejlesztőknek napi problémákat tud okozni. A legnagyobb gond, hogy a Visual Studioba épített fejlesztői webszerver (Cassini) nem azonos az IIS-sel, sokkal kevesebbet tud. A másik nagy probléma, hogy a nagy IIS konfigurálásához admin jogok kellenek és ismerni kell hozzá az IIS gazdag funkciókészletét. Ez inkább üzemeltetői ismereteket és gyakorlatot igényel, ami a fejlesztőknek egyszerűen nincs meg és lássuk be, nem is nagyon vágynak rá. A megoldás az IIS Express, ami felváltja a Cassinit egy olyan webszerverrel, ami teljesen kompatibilis az IIS-sel, tudja futtatni az IIS modulokat, tudja az SSL-t, sőt még admin jog sem kell hozzá. Ez gyakorlatilag egy mini IIS motor, ami leveszi a fejlesztő válláról az IIS konfigurálásának nehézségeit és lehetővé teszi, hogy a fejlesztőkörnyezet közel 100%-osan kompatibilis legyen az éles futtatókörnyezettel.

Az adatbázisszerver

A TechEden beszélgettem egy open source CMS vezető fejlesztőjével, aki azt mondta, hogy a support kérdéseik 80%-a az SQL Server komplexitására vezethető vissza. Egyáltalán nem triviális a telepítése, aminél már csak a megfelelő jogosultságok beállítása nagyobb kihívás. Nem véletlen, hogy egy csomó webhosting környezetben egyáltalán nincs SQL Server, hiszen nem csak a telepítése, hanem az alkalmazások elszigetelése is nagyon komoly feladat. Helyette sok helyen még mindig az Access dívik, mert ott még az adatbázist sem kell telepíteni. A most elérhetővé vált SQL Server Compact Edition 4.0 ezeket a fejlesztői és üzemeltetői problémákat oldja meg azzal, hogy az SQL Server legfontosabb funkcióit telepítés nélkül is elérhetővé teszi. Az SQL Compact mindössze pár DLL, amit elég bemásolnunk az alkalmazásunk bin könyvtárába és máris működik. Ugyanígy az adatbázist is elég csak felmásolnunk a szerverre. Nincs telepítés, nincs adatbázis attach-olás, de tud SQL-ül, sőt még megy vele a LINQ to SQL és az Entity Framework is. Az SQL Compact korábbi verzióit nem lehetett többszálú környezetben használni, mostanra azonban ezt is megoldották, így tökéletes relációs adatbázis motorrá vált ASP.NET alkalmazások alá.

Újrafelhasználás

A komponens alapú fejlesztés egyik alapelve az elkészült modulok, komponensek újrafelhasználása. Ez egy ASP.NET projektnél tipikusan eddig azt jelentette, hogy a gyártó oldaláról le kell töltenünk egy csomagot, amiből a DLL-eket és a markup fájlokat be kell másolnunk a megfelelő könyvtárakba, majd módosítanunk kell a web.config megfelelő részeit. Sajnos ez minden egyes bővítmény esetén garantálhatóan teljesen máshogy történik, és általában több idő kideríteni, hogy mit kell csinálni, mint elvégezni ezt a néhány apró módosítást a forráskódunkon. Ezen az összevisszaságon az új NuGet Package Manager fog segíteni, ami egy PowerShell alapú, jól szkriptelhető motor a bővítmények kezelésére. Természetesen nem kell mindenképpen parancssorból kezelnünk a csomagokat, a NuGet beépül a WebMatrixba és a Visual Studioba is. Kell némi Facebook funkció a weboldaladra? Van hozzá NuGet package. Vagy PayPal? Ahhoz is van helper, sőt még nagyon sok mindenhez, elég csak körülnézni a most épp 376 csomagot tartalmazó galériában, merthogy persze van egy közös gyűjtemény ezekből a bővítményekből.

Indulás nem nulláról

Akik nem szenvednek not invented here szindrómában, azok már rég belátták, hogy az open source világban nagyon komoly eredmények vannak. Már egyáltalán nem ciki fogni egy nyílt forráskódú alkalmazást és annak a kódjából kiindulva, némi testreszabással elkészíteni a saját megoldásunkat. A WebMatrix, az új Web Platform Installer 3.0 és a hozzá kapcsolódó Web Application Gallery ezt nagyon komolyan támogatja. Alig néhány kattintással le tudunk tölteni és be tudunk üzemelni a saját gépünkön egy nyílt forráskódú CMS, blog vagy galéria webhelyet az összes függőségével együtt! Ez utóbbi nagyon nagy szó ám, gondoljunk csak az adatbázis szerver és az adatbázis séma telepítésének és konfigurálásának kínjaira! Sőt, maga a Microsoft is belépett a nyílt forráskódú CMS alkalmazások “piacára” az Orchard projekttel.

Hoszting

Mi lesz az elkészült alkalmazások sorsa, hol tudjuk hosztolni? Sajnos Windowsos hoszterből messze nincs annyi, mint PHP-sból, tehát az egyik probléma, hogy nem egyszerű megfelelőt találni. Azután ha sikerült választani, akkor még mindig adott a fejlesztőkörnyezet és a futtatókörnyezet konfigurálásának feladata. A fejlesztőnek tudnia kell a szerver paramétereit, az üzemeltetőnek pedig ismernie kell az alkalmazás tulajdonságait és az egyedi telepítési igényeket. Ne felejtsük el, hogy a fejlesztők és az üzemeltetők teljesen más világban élnek, más nyelvet beszélnek, itt viszont könyörtelenül egymásra vannak utalva. Itt lép be a képbe a Web Deployment Tool 2.0, és az új Web Hosting Gallery, ami ezt a folyamatot nagyban tudja egyszerűsíteni és automatizálni.

A fenti felsorolásból egyértelműen látszik, hogy ma egy új világba léptünk a Microsoft web platform területén, a fenti eszközök és technológiák már letölthetőek az új Web Platform Installer 3.0-val. A Microsoft az alapoktól újragondolta a platform minden egyes részét és kiegészítette ott, ahol a legkomolyabb nehézségekkel találkoztak a profi fejlesztők és a platformmal most ismerkedők. Az új jelszó az egyszerűség, mert ahogy Leonardo da Vinci mondta, “az egyszerűség a kifinomultság csúcsa”.

ps. A teljes képhez még egyetlen apróság hiányzik, ez pedig a VS IDE támogatás az IIS Expresshez és az SQL CE-hez, de az sincs már messze, a most épp bétában lévő VS 2010 SP1 hozza el őket hamarosan.

Tetszenek az újdonságok, mit gondoltok, jó ez az egyszerűség irány?

Chrome tag H.264 nélkül

A Chromium blogon azt írják, hogy a Chrome hamarosan fel fog hagyni a HTML 5 <video> tag-ben a H.264 formátum támogatásával a nyílt codecek javára.

Vajon mi fog történni, kihal a H.264, vagy ismét szeretni fogjuk a Flasht? Még az is lehet, hogy megjelenik egy rakás Chrome plugin, ami ezt tudni fogja.

Szerintetek ez jó lépés vagy ezzel a Chrome alaposan elásta magát?

WP7 vs WP7

Mióta a Microsoft elérhetővé tette a Windows Phone 7 operációs rendszert, számos gyártó jelent meg WP7-es készülékkel. Mivel a Microsoft elég sok közös követelményt ír elő a hardverrel kapcsolatban, elég nehéz megkülönböztetni egymástól az egyes készülékeket. Az alábbi infógrafika (Forrás: ElektricForest) sokat segít ebben (katt a teljes méretért):

Sajnos az ábrán nem minden tulajdonság szerepel, például a tárhely mérete és az SD kártya bővíthetőség eltérhet az egyes modelleknél. A készülékekről szép hosszú lista található a Microsoft Devices at a Glance oldalán.

Aki használ WP7-es telefont, a többiek érdekében akár meg is írhatná ide kommentben, hogy melyiket és miért azt választotta, vagy mit szeret rajta.

Webszolgáltatás hívás kimenő IP címének beállítása

Ma egy olyan webszolgáltatást kellett meghívnom, ami előtt egy tűzfal csak bizonyos IP című kliensekről engedélyezi a hozzáférést. Ez normális esetben nem is szokott gondot okozni, most is megbeszéltem az ottani rendszergazdákkal, hogy milyen IP címről akarom küldeni a kérést, és ők készségesen lyukat ütöttek a tűzfalba. A nehezítést az jelentette, hogy a hívó épp egy szerver, aminek több IP címe van, és persze alapból nem arról ment ki a kérés, ahonnan én akartam. A kérdés tehát, hogy hogyan lehet megadni egy webszolgáltatás hívásnál a hívó IP címét?

A dolog szerencsére megoldható, de nem olyan egyszerűen, mint szeretnénk. A Visual Studio varázslója olyan proxy osztályt generál, ami a SoapHttpClientProtocol ősosztályból származik, aminek persze egy fikarcnyi ide vágó property-je sincsen. Viszont a HTTP híváshoz ő belül a HttpWebRequest osztályt használja, amin szerencsére lehet ilyen jellegű fogódzót találni. Persze csak alapos kereséssel, ugyanis a tulajdonságot úgy hívják, hogy ServicePoint, aminek a BindIPEndPointDelegate tulajdonságát (!) kell beállítani egy delegate-re! Én bizony ezt biztosan nem így csináltam volna, de gondolom jó okuk volt rá, hogy így döntöttek.

Sajnos a belső WebRequest példány szintén nincs kivezetve a SOAP proxy osztályban, így nincs más lehetőségünk, mint a VS által generált proxy osztályból egy újabb osztályt származtatni, és ott felülírni azt a metódust, ami a WebRequest példány előállításáért felelős. Miután ezt így fejben levezette az ember, a kód már meglehetősen rövid:

class MyServiceWrapper : MyVSGeneratedServiceProxyClass
{
  public IPAddress SourceIPAddress { get; set; }

  protected override WebRequest GetWebRequest( Uri uri )
  {
    HttpWebRequest request = (HttpWebRequest) base.GetWebRequest( uri );
    request.ServicePoint.BindIPEndPointDelegate = new BindIPEndPoint(
      delegate( ServicePoint servicePoint, 
                IPEndPoint remoteEndPoint, 
                int retryCount )
      {
        return new IPEndPoint( this.SourceIPAddress, 0 );
      });
    return request;
  }
}

Persze akinek nem jön be ez a tömör névtelen metódusos megoldás, az írhat olvashatóbb kódot két metódusba:

protected override WebRequest GetWebRequest( Uri uri )
{
  HttpWebRequest request = (HttpWebRequest) base.GetWebRequest( uri );
  request.ServicePoint.BindIPEndPointDelegate = 
    new BindIPEndPoint( this.OnBindIPEndPoint );
  return request;
}


private IPEndPoint OnBindIPEndPoint( ServicePoint servicePoint, 
                                     IPEndPoint remoteEndPoint,
                                     int retryCount )
{
  return new IPEndPoint( this.SourceIPAddress, 0 );
}

Végül már csak annyi dolgunk maradt, hogy a Studio által generált osztály helyett a sajátunkat példányosítjuk és beállítjuk a SourceIPAddress tulajdonságot a kívánt IP címre.

Technorati-címkék: webservice