2009. november havi bejegyzések

Az IIS 7 felügyelete távolról

Távfelügyelet Az Internet Information Services 7 egyik újdonsága, hogy a webkiszolgálót üzemeltető rendszergazdák távolról is teljeskörűen hozzáférhetnek a webszerver beállításaihoz. A korábbi, MMC konzolon alapuló megoldás gyakorlatilag csak belső hálózaton keresztül volt használható, most viszont szabványos és titkosított HTTPS csatornán keresztül csatlakozhatunk az IIS Managerrel a szerverhez.

A távoli felügyelet kulcsa az IIS 7 részeként külön telepítendő Web Management Service (WMSvc) komponens, amelynek beállításait csak webkiszolgáló szinten és csak a szerver helyi rendszergazdája módosíthatja. A WMSvc csak titkosított csatornán keresztül képes működni, ezért mindenképpen igényel egy SSL tanúsítványt, melyből egy önaláírt változatot WMSvc-GÉPNÉV néven telepít is a rendszer magának. A beállítások között megadhatjuk, hogy a kommunikáció melyik IP címen (alapértelmezés szerint All Unassigned) és porton (alapértelmezés szerint 8172) történjen, illetve hogy milyen IP című kliensektől fogadunk el csatlakozási kérelmeket vagy éppen tiltjuk a hozzáférést. A hozzáféréseket a rendszer képes naplózni, a naplók alapértelmezés szerint a %SystemDrive%InetpublogsWMSvc mappába kerülnek.

A Web Management Service csatlakozáskor hitelesítést követel a klienstől, ami lehet Windows vagy IIS Manager alapú, tehát nem kötelező Windows felhasználói fiókokat létrehoznunk a webkiszolgáló távoli felügyeletéhez. Ez a lehetőség a Feature Delegation funkcióval kombinálva lehetővé teszi a webkiszolgáló egyes funkcióinak távoli felügyeletét nem rendszergazdák számára is. A kliens oldal akár Windows XP operációs rendszer is lehet, az IIS Manager alkalmazás a www.iis.net oldalról más platformra is letölthető.

Demó

A demóban bemutatjuk a Management Service telepítését, bekapcsolását, konfigurálását és azt, hogy a kliens hogyan tud a webkiszolgálóhoz vagy a kiszolgálón futó egyik webhelyhez vagy alkalmazáshoz kapcsolódni.

Távfelügyelet - Kattints ide a demó videó megtekintéséhez Lejátszáshoz kattints a képre

Letöltés: Tavfelugyelet.wmv (19:02, 85.2 MB)

Első lépések

Az Internet Information Services 7 komponensei között telepítsük fel a Management Service komponenst. Ezek után az IIS Managerben válasszuk ki a webkiszolgálónkat, majd kattintsunk a Management Service modulra és az Enable remote connections opció bekapcsolásával engedélyezzük a távoli kapcsolódást. Ellenőrizzük, hogy a tűzfal szabályok között megjelent-e a Web Management Service (HTTP Traffic-In) kivétel, amelyik engedélyezi a 8172-es TCP porton a bejövő forgalmat.

Jó tudni

A Web Management Service (WMSvc) komponens alapértelmezés szerint Manual indítási mód beállítással települ, tehát ha a szerver újraindul (például egy javítócsomag telepítése miatt) vagy leáll a http.sys komponens, csak akkor fogunk tudni távolról csatlakozni a webkiszolgálóhoz, ha a szerveren manuálisan elindítjuk a szolgáltatást. Ezt elkerülendő célszerű a WMSvc szolgáltatás Startup type értékét Automaticra állítani, parancssorból például így: sc config WMSvc start= auto

Amennyiben módosítjuk a Web Management Service-hez rendelt portot, manuálisan kell frissítenünk a bejövő forgalmat engedélyező tűzfal szabályt. A WMSvc bármilyen paraméterének módosításához le kell állítanunk a szolgáltatást, majd újra kell indítanunk.

A Management Service szolgáltatás csak Windows Server 2008-on és Windows 7-en található meg, a Windows Vistába épített IIS 7 ezt a komponenst nem tartalmazza.

Érdekesség

A WMSvc szolgáltatás alapértelmezés szerint a Local Service felhasználói fiók nevében fut. A Windows Vistában és a Windows Server 2008-ban bevezetett új lehetőségnek köszönhetően azonban a szolgáltatás által igényelt összes erőforrás egy szolgáltatás specifikus, NT ServiceWMSvc security identifierrel (SID) van védve.

További információk

Reklámok

ASP.NET-es webalkalmazások futtatása Server Core-on

A Windows Server 2008 R2 operációs rendszer egyik legfontosabb újdonsága, hogy immár a Server Core változat is képes .NET platformra írt alkalmazások futtatására. Ennek a számlájára írható, hogy már Server Core-on is van PowerShell, és ennek köszönhető az is, hogy immár Server Core-on is futtathatunk ASP.NET-es alkalmazásokat. Ebben a cikkben lépésről lépésre megyünk végig azon a folyamaton, mellyel egy csupasz Core-ból távolról, grafikusan felügyelhető webszervert készítünk, rajta egy futó ASP.NET-es alkalmazással.

Tovább a cikk folytatására »
(A teljes cikk a magyar nyelvű TechNet Portálon olvasható.)

 

Technorati-címkék: ,,,

Alkalmazások bemelegítése IIS 7.5 alatt

Mint minden szoftvernél, webalkalmazások esetén is előfordulhat, hogy az alkalmazásnak induláskor inicializálnia kell magát, adatbázis kapcsolatokat kell felépítenie, cache-t kell feltöltenie, sőt az összes olyan rendszer- és platform komponenst is inicializálnia kell, amelyre ráépül. A .NET keretrendszerre épülő alkalmazások esetén ehhez még hozzájön a just-in-time fordítás, mellyel összességében az alkalmazáshoz érkező első kérés kiszolgálása zavaróan elhúzódhat.

Erre a problémára a hagyományos megoldás az, hogy a felhasználói kéréseket megelőzve mi küldjük be az első kérést a webalkalmazásnak, így mire a valódi felhasználók megérkeznek, már a bemelegített, villámgyors honlappal fognak találkozni. Ezzel a megoldással sajnos legalább három probléma van:

  • Meg kell írnunk a kliens szkriptet, ami HTTP kérésekkel bombázza a webalkalmazásunkat.
  • Gondoskodnunk kell arról, hogy a bemelegítő szkriptünk az alkalmazáskészlet minden indulásakor lefusson.
  • IIS 7.5 előtt a felhasználóktól érkező kérések megelőzhetik a bemelegítő szkriptet (architekturális korlát).

Szerencsére a Windows 7-ben és a Windows Server 2008 R2-ben megjelent IIS 7.5 ezen a területen jelentősen fejlődött. A kulcskérdés az, hogy az alkalmazás minek a hatására kezdi el inicializálni magát?

Tovább a cikk folytatására » 
(A teljes cikk a magyar nyelvű TechNet Portálon olvasható.)

 

Teljesítménynövelés az IIS 7 beépített funkcióival

Az Internet Information Services 7 komponensei között találunk két olyan elemet, amelyek segítségével jelentősen növelhetjük a webkiszolgálónk teljesítményét, mégpedig gyakorlatilag a webalkalmazás módosítása nélkül, pusztán üzemeltetői eszközökkel.

Teljesitménynövelés Az egyszerűbb funkció a tömörítés, azaz a compression. Ezzel a funkcióval a szervertől a böngésző felé menő forgalmat csökkenthetjük azáltal, hogy a kiszolgáló átküldés előtt tömöríti az átküldendő adatokat, amit a böngésző automatikusan kitömörít. A háttérben ez úgy valósul meg, hogy a kliens egy Accept-Encoding fejléc átküldésével jelzi a szervernek, hogy képes tömörített válasz feldolgozására. Az IIS 7-ben a statikus állományok tömörítése alapértelmezés szerint be van kapcsolva, a dinamikus állományokra (.aspx, .php stb.) pedig külön engedélyezhetjük a tömörítést. A grafikus felületen nincs lehetőség a funkció finomhangolására (például a tömörítés fokának a megadására), azt közvetlenül az applicationHost.config állományban tehetjük meg a system.webServer/httpCompression elemben.

A másik teljesítményfokozó funkció a gyorsítótárazás, azaz a kiszolgáló oldali cache használata. Ezzel a funkcióval a webkiszolgáló képes a statikus fájlokat vagy a generált oldalak HTML kódját memóriában tartani és így elkerülni azok ismételt felolvasását a diszkről, illetve szükség esetén a fordítását és futtatását. Az IIS 7 bizonyos körülmények között akár kernel szintű gyorsítótárazásra is képes, amely jelentős teljesítmény növekedést eredményez. Az IIS Manager grafikus felületén akár kiterjesztés szerint megadhatjuk, hogy mennyi ideig próbálja a rendszer gyorsítótárban tartani a fájlt, valamint megadhatjuk azt is, hogy különböző fejléc mezők (pl. Accept-Language) vagy query string értékek szerint több változat is gyorsítótárba kerüljön.

Demó

Tömörítés és gyorsítótárazás - Kattints ide a demó videó megtekintéséhez Lejátszáshoz kattints a képre

Letöltés: Teljesitmeny.wmv (19:04, 94.8 MB)

Első lépések

Ahhoz, hogy a tömörítés és a gyorsítótárazás működjön, telepítenünk kell a Performance, a Static Content Compression és a Dynamic Content Compression modulokat. Ezek után az IIS Managerben az Output Caching és a Compression menüpontok alatt tudjuk bekapcsolni ezeket a funkciókat.

Jó tudni

A tömörítés jelentős processzor terhelést generálhat a szerveren, melynek finomhangolására system.WebServer/httpCompression ágban számos opciót találunk. Ezeket a paramétereket csak a konfigurációs állományban módosíthatjuk, nincsenek kivezetve a felhasználói felületre.

A gyorsítótárazás bekapcsolása után nem kerül minden fájl automatikusan a cache-be, az IIS 7 meghatározza, hogy melyek azok a fájlok, amelyek célszerű memóriában tartani. Alapértelmezés szerint ehhez az szükséges, hogy az adott állományt 10 másodpercen belül legalább kétszer kérjék le a kliensek. Ezek a beállítások a system.WebServer/serverRuntime ágban található frequentHitThreshold és frequentHitTimePeriod attribútumokkal módosíthatóak.

További információk

Monitorok egymás felett

Rádugtam a laptopomra egy külső monitort, amit sajnos nem tudtam mellé elhelyezni, csak fölé. Adódott is rögtön a kérdés, hogyan lehet a desktopot nem vízszintesen, hanem függőlegesen kiterjeszteni? Windows 7 alatt megnyitottam a Screen Resolution ablakot és bár erre nincs opció, azért be lehet állítani.

Egyszerűen meg kell fogni a második monitort és az elsőhöz képest oda kell tenni, ahol használni akarjuk, például drag-and-drop az első fölé:

Monitorok egymás felett

Miután először kimorogtam magam, hogy erre miből kellett volna rájönnöm, azután pedig elcsodálkoztam rajta, hogy jobban végiggondolva ez a legtermészetesebb megoldás (de tényleg, csak mi már bekockultunk), felötlött bennem, hogy mit csinál az, aki nem használ egeret? Kipróbáltam billentyűzettel, ki lehet választani a kis monitort és lehet tologatni, még zoomol is automatikusan, érdemes kipróbálni, tényleg szépen megcsinálták. Azért megnézném azt a projekttervet, amiben ez külön tételként szerepelt 🙂

Próbált már valaki több monitort, lehet a monitor ikonokkal tetrisezni?

Technorati-címkék: ,,

ASP.NET MVC csővezeték

asp_net_mvc_poster_thumbnail Steven Sanderson Pro ASP.NET MVC Framework c. könyvében (Apress) van egy ábra, amin jól végig lehet követni, hogy ASP.NET MVC környezetben hogyan történik a bejövő kérések feldolgozása. Nem csak az szerepel az ábrán, hogy melyik komponens után melyik jön, hanem az is, hogy az egyes szereplők miért vannak a feldolgozási csővezetékben. A RedGate oldaláról ingyenesen letölthető a poszter.

Technorati-címkék: ,

TFS-t mindenkinek

Korábban már írtam arról, hogy a Dev10 hullámmal megváltozott az online és az offline MSDN is. A teljes képhez hozzátartozik, hogy az MSDN előfizetések is megváltoznak:

If you have this active subscription on March 22, 2010:

…then your subscription will become this:

…and you’ll get everything you had before, plus:

Visual Studio Team System Team Suite with MSDN Premium

Visual Studio 2010 Ultimate with MSDN

Visual Studio 2010 Ultimate, Team Foundation Server 2010 + CAL

Visual Studio Team System editions with MSDN Premium (Architecture, Database, Development, Test)

Visual Studio 2010 Ultimate with MSDN

Visual Studio 2010 Ultimate, Team Foundation Server 2010 + CAL

Visual Studio Professional with MSDN Premium

Visual Studio 2010 Premium with MSDN

Visual Studio 2010 Premium, Team Foundation Server 2010 + CAL

Visual Studio Professional with MSDN Professional

Visual Studio 2010 Professional with MSDN

Visual Studio 2010 Professional, Team Foundation Server 2010 + CAL

Visual Studio Professional with MSDN Embedded

Visual Studio 2010 Professional with MSDN Embedded

Visual Studio 2010 Professional

MSDN Operating Systems

MSDN Operating Systems

 

Lehetne még arról is írni, hogy az előfizetők a Windows Azure-ban mennyi időt, helyet és sávszélességet kapnak, de nem az itt a fontos szerintem. Egyszerűen nem lehet nem észrevenni, hogy a TFS – amit eddig csak külön lehetett megvenni – ott van szinte mindegyik előfizetésnél, és nem a Workgroup Edition az 5 felhasználós limitjével, hanem a teljes!

Ez szerintem óriási előrelépés, különösen, hogy a telepítés és az üzemeltetés lényegesen egyszerűbb lett. Immár kisebb fejlesztőcsapatok is könnyen használhatják, hiszen a Basic telepítőben (nem edition, csak a telepítő egyszerűsített változata) szinte csak Next-Next-Finish van, ráadásul most már lehet tartományvezérlőre, sőt kliens operációs rendszerre is telepíteni (nem mindenhol állnak hegyekben a szerverek). Ebben sincs felhasználó limit, de van source control, bug tracking és build automation! Aki pedig szeretne mindent szépen beállítani, az a Standard telepítővel mindent testreszabhat. Az üzemeltetés pedig MMC-ből történik, ahogy az kell.

Erről kár is sokat szövegelni, Brian Harry blogja tele van képernyőfotókkal, aki nem hiszi, nézze végig a képregényt itt és itt.

Van még kifogás?

Technorati-címkék: ,,