2013. november havi bejegyzések

IIS konfiguráció auditálás

Az IIS konfigurációs beállításai között nem nehéz olyat találni, aminek az átbillentése egy csapásra nem biztonságossá teszi a szervert. Éppen ezért nagyon fontos, hogy a konfiguráció változásait tudjuk követni, monitorozni. Szerencsére ez egy beépített lehetőség a webszerverben, csak nem ott kell keresni, ahol az összes többi opciót.

Indítsuk el az Event Viewert, majd navigáljunk el az Application and Services Logs –> Microsoft –> Windows –> IIS Configuration –> Operational ágig. Kattintsunk ezen az ágon jobb egérgombbal és válasszuk az Enable Log menüpontot az auditálás bekapcsolásához:

iis-config-audit-log

Ezek után minden egyes IIS módosítás megjelenik ebben a naplóban:

iis-config-audit-general

A General nézetben a módosított beállításon kívül jóformán csak a módosítás ideje és a felhasználó neve jelenik meg, de a Details nézetben több információt is találunk:

iis-config-details

Nem árt tudni, hogy csak azok a módosítások jelennek meg, amik az IIS Manageren vagy az objektum modellen keresztül történnek; ha az applicationHost.config fájlt Notepaddel szerkesztjük, annak sajnos nem lesz nyoma a naplóban.

 

Technorati-címkék: ,,,

Git Extensions: Syntax error near unexpected token

Frissen telepített Git Extensionsben az első klónozáskor belefuthatunk az alábbi hibaüzenetbe:

git-credential

Ebből a hibaüzenet pontosan ez:

\"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore/
git-credential-winstore.exe\" get: -c: line 0: 
syntax error near unexpected token `('

A problémát a C:\Users\<Felhasználónév>\.gitconfig fájlban kell keresnünk, azon belül is ez a sor az oka mindennek:

[credential]
helper = !\\\"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore/git-credential-winstore.exe\\\"

A megoldás, hogy vegyünk ki a sor elejéről és a végéről is 2-2 backslasht, hogy csak 1-1 maradjon:

helper = !\"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore/git-credential-winstore.exe\"

Így már működni fog.

 

Technorati-címkék: ,

Azure sebesség teszt

Ha aszerint akarod eldönteni, hogy melyik Windows Azure adatközpontban legyen az alkalmazásod, hogy melyik a leggyorsabb, akkor a Windows Azure Speed Test oldal segítségével összemérheted őket:

http://azurespeedtest.azurewebsites.net/

 

Köszönet a linkért Gál Tamásnak.

 

Technorati-címkék: ,

Visual Studio változatok

A héten megjelent Visual Studio Online (korábbi nevén Team Foundation Service) tovább bővítette a Visual Studio változatok korábban sem éppen átlátható kínálatát. Már ennyi féle van (nem beszélve az Express termékekről):

Összehasonlító táblázatok:

A licenceléssel kapcsolatos leggyakoribb kérdéseket a 34 oldalas Visual Studio and MSDN Licensing White Paper foglalja össze, ez is frissült most novemberben.

 

Technorati-címkék: ,,

IIS távoli felügyelete Windows 8.1-ről

Az Internet Information Services (IIS) Manager (inetmgr.exe) egyik kiváló szolgáltatása, hogy a saját gépünkön elindítva, grafikus felületen keresztül, távolról felügyelhetjük vele a webszervereinket. Ehhez nem kell mást tennünk, mint kiválasztanunk a File menüből a Connect to a Server menüpontot:

inetmgr-connect-to-file-menu

Ez végigvezet egy varázslón, és ha a szerveren telepítve van a Web Management Service, akkor pillanatok alatt csatlakozhatunk a webszerverünkhöz, webhelyünkhöz vagy webalkalmazásunkhoz.

A gond akkor van, ha nincs ilyen menüpont, márpedig nincs. Sem Windows 7-en, sem Windows 8-on, sem 8.1-en. bezzeg Save Connections van (igaz, disabled állapotban), de vajon minek?

inetmgr-default

Windows 7 esetén még történeti okokra hivatkozva talán megértem, de az újabb kliens operációs rendszerek esetén nem találok magyarázatot. Ha már mindenképp külön kell letölteni, akkor lehetne például az RSAT része.

Oldjuk meg hát a problémát, irány a Web Platform Installer, ahol például a “remote” szóra keresve pillanatok alatt megtalálhatjuk az IIS Manager for Remote Administration v1.1 verziót:

inetmgr-webpi-search

Senkit ne tévesszen meg a két évvel ez előtti dátum, pont ez kell nekünk. Bökjünk a sorban az Add, majd alul az Install gombokra, végül a következő ablakban az I Accept gombra kattintva fogadjuk el a licenc előírásait. Elindul a letöltés, megkezdődik a telepítés, majd jön a hidegzuhany:

inetmgr-webpi-sorry

Nem sikerült a telepítés, mert Windows 7 vagy újabb kell neki. De hát ez egy Windows 8.1, jaj!

Próbálkozzunk meg ismét a telepítéssel, de most a licenc elfogadása ablakban kattintsunk inkább a Direct Download Link hivatkozásra:

inetmgr-webpi-licence

Ennek hatására az alapértelmezett böngészőnk letölti a telepítőt oda, ahova mi szeretnénk. A letöltési cím egyébként a hibaüzenet melletti View log here gombra kattintva megjelenő naplófájlból is kicsalható, az én esetemben ez volt:

http://download.microsoft.com/download/D/A/5/DA588562-C4A4-4337-AE36-3A4548700CDF/inetmgr_amd64_v1.1_en-US.msi

Mielőtt elindítjuk a telepítőt, nyissuk meg az MSI fájlhoz tartozó Properties ablakot és a Compatiblity fülön álljunk vissza korábbi Windows verzióra:

inetmgr-compatibility

Nyomkodjuk végig a varázslót, indítsuk újra az IIS Managert és már kapcsolódhatunk is a szerverünkhöz, ahonnan előfordulhat, hogy az első alkalommal újabb modulok töltődnek le:

inetmgr-features

 

Technorati-címkék: ,

Több website-ot tartalmazó solution publikálása Azure-ra

Az Azure Websites egyik kiváló szolgáltatása, hogy közvetlenül hozzá lehet kapcsolni forráskód kezelő rendszerhez, így amikor a forráskód frissül, az automatikusan azonnal kikerülhet a felhőbe.

Ezt pofonegyszerű összevarázsolni, csak indítsuk el a New –> Compute –> Web Site –> Custom create varázslót:

multisite-new

Az első lépésben adjunk nevet a webhelynek, és pipáljuk be a Publish from source control jelölőnégyzetet:

multisite-name

Ennek hatására megjelenik a varázsló második lépése, ahol kiválaszthatjuk a forráskódkezelő rendszerünket, például GitHubot:

multisite-where

GitHub esetén egy OAuthos authentikáció következik, majd meg kell adnunk, hogy melyik repository-nak melyik ágát (már nem csak mastert lehet!) kívánjuk erre a webhelyre publikálni:

multisite-repo

A pipára kattintva meg is történik a varázslat, pár másodperc alatt létrejön a webhelyünk és már települ is rá az alkalmazás.

De mi van akkor, ha a forráskód olyan Visual Studio solutiont tartalmaz, amiben több webes projekt vagy több website van, melyik fog települni? Az első.

Azonban mi nem mindig ezt szeretnénk.

Ha az Azure website-ra mindig a solution egyik projektjét kívánjuk telepíteni, akkor létrehozhatunk a repo gyökerében egy .deployment nevű INI fájlt, amiben megadhatjuk a telepítendő projektet:

[config]
project = MySolution/MyWebProject.csproj

Előfordulhat azonban, hogy több Azure website-unk van, és az egyikre a solution egyik webes projektjét, a másikra a másik webes projektjét kívánjuk telepíteni. Ebben az esetben a beállítást nem drótozhatjuk bele a forráskódba, hanem a felhőben kell trükköznünk. Látogassunk el a CONFIGURE oldalon belül az app settings szekcióba, ahol vegyünk fel egy új beállítást Project néven:

multisite-appsettings

Az értékként adjuk meg a .csproj fájlra vagy az ASP.NET website mappájára mutató repo-gyökér relatív elérési utat.

Mentés után a következő deploymentnél már ennek figyelembe vételével fog történni a telepítés.

 

Technorati-címkék: ,,,