Hibajelenség

Az MVC alkalmazásom HTML form ablakában a mezők kitöltését követően a Submit folyamat megkezdésekor a rendszer az alábbi hibaüzenetet adta:

[InvalidOperationException: Operation is not valid due to the current state of the object.]
   System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded() +2420558
   System.Web.HttpValueCollection.FillFromEncodedBytes(Byte[] bytes, Encoding encoding) +58
   System.Web.HttpRequest.FillInFormCollection() +159

Hiba oka

A Microsoft 2011-12-29-én kiadta a Microsoft Security Bulletin MS11-100 – Critical szintű bejegyzést. A bejegyzés hibajavítására kiadták 2012-01-12-vel az MS KB Article ID 2661403 cikket és a hozzá kapcsolódó hibajavítást. Ez MINDEN eddigi Windows rendszerben a sérülékenységet orvosolja, viszont számomra ez a korlát jelenti a valódi problémát:

A rendszerekben ugyanis a DOS (Denial of Service) támadások elkerülése végett beépítésre került egy alapértelmezett válaszban megadható elemszám méret. Ez alapértelmezésben 1000! Amennyiben az ASP.NET form működése során ennél nagyobb elemszámmal találkozik, akkor a fenti hibaüzenettel fémjelzett kivételt dob.

Megoldás

Talán elsőre is látható, hogy a legegyszerűbb javítás az lenne, ha az elemszámot a számunkra szükséges mértékben megnövelnénk. Nos erre van lehetőség, az alkalmazás Web.Config fájl-t kell megfelelően kiegészíteni:

  <appSettings>

    <add key="aspnet:MaxHttpCollectionKeys" value="1500" />

  </appSettings>

Ezt követően az alkalmazás minden hibajelzés nélkül rendben lefut. Figyeljünk azonban a kapcsolóra és feleslegesen ne növeljük az elfogadható elemszámot, ezzel is védve az alkalmazást és futtató környezetét.

További információ:

• Microsoft KB Article
• December 2011 Out-Of-Band Security Bulletin Webcast Q&A
• Stackoverflow Post

Hosszadalmas nézelődés után arra jutottam, hogy a hiba oka ott keresendő, hogy az érintett megosztást az adott munkaállomás csak lassan (500-700 milisec vagy hosszabb idő alatt) tudta elérni, viszont a policy ennyit nem vár. Keresgélésem innentől célirányossá vált, és az alábbi Policy beálltásra bukkantam, mellyel a probléma orvosolható:

Local Computer Policy\Computer Configuration\Administrative Templates\System\Logon szekcióban található egy Always wait for the network at computer startup and logon beállítás. Ennek értékét kell ilyen esetben Enable-re állítani.

E beállítást követően a rendszer már szépen megvárja, hogy az érintett megosztás megfelelően beállításra kerüljön, mielőtt tovaszáguld a következő utasításunk felé…

Ennek eredményeképpen találtam rá joeware.net-re és az ott elérhető tool-okra. Ezek segítségével számos feladatot könnyedén elvégezhetünk mindenféle scriptek nélkül, így például a felhasználói könyvtárak elérési útjának módosítását is. Mintaképpen álljon itt egy home könyvtár cseréjére szolgáló egyszerű paranccsori utasítás:

adfind -b "OU=Test,DC=w2k,DC=pl" -s subtree –f "(&(objectClass=user)(objectCategory=person))" samaccountname -adcsv | admod "homeDrive::Z:" homeDirectory::\\server\homes\{{samaccountName}}

Nem is olyan bonyolult ugye? Természetesen az AD lekérdezés módosításával további szűréseket lehet egyszerűen megvalósítani…

Szép kihívás! Nézegettem és megpróbáltam logikusan gondolkodva eredményre jutni. Sok minden látszik – és a programozói múlttal érthető is – de végül teljes sikert nem tudtam elérni. A kisérletek alapján nekizuhantam a netnek és az alábbi linken egy jó és hasznos megoldást sikerült találnom:

http://exchangeserverpro.com/how-to-move-wsus-30-to-a-new-server

A cikk tiszta és világos, s így együtt már sokmindenre választ és megoldást adott. Remélem sokaknak segít még.

powercfg.exe /hibernate off

Részletesebben: http://support.microsoft.com/kb/920730

Hosszas magyarázkodás helyett álljon itten a megoldás, törölni kell a registry-ből a  HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate kulcsot (a teljes kulcsot és ami alatta van), majd újra kell indítani a Windows Update Service-t.

Akit részletesebben érdekel az nézze meg a vonatkozó blog bejegyzést.

http://support.microsoft.com/kb/938245/

A cikk címe: A Windows Server rendszer szolgáltatásainak áttekintése és a rendszer hálózatiport-követelményei

Első lépésben végigmentem az upgrade procedúra előkészítésén (cseréltem és eltávolítottam programot, meghajtót, stb.) majd nekikezdtem. Jól megírt dolog ez az upgrade és valóban szépen és jól megcsinált mindent, valóban azt és úgy végezte el amit és ahogy kellett.

Természetesen nem várhatom az informatikától, hogy minden elsőre jól menjen, így saját kis notimon (Compaq nc6320) miért is működne a Bluetooth driver? Hát nem megy! A driver okés, minden úgy fest, hogy működik, s mégsem. Úgyhogy nekikezdek és vadászok egy használható megoldást erre a kis gondra. Viszont ettől függetlenül ajánlom mindenkinek, aki még habozik, hogy igenis fusson neki a tesztelésnek és vegye kezelésbe az új rendszert, nézze meg mennyire jót lehetett megint alkotni (hiába az MS-nél ez egy sima egy fordított alapon zajlik )!

Jó kísérletezést!

The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine

Néztem ki a fejembõl bután, mi is történt. Némi utánolvasást követõen az alábbiakat találtam:

The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine on my Vista 64 bit machine today. I made no code changes since I run it on a 32 bit OS.

Mit is kezdhetünk ezzel a problémával? A legegyszerûbb, ha a fordításkor fixen megmondjuk, hogy ez a program x86-os üzemmódban fusson. Miképp kell ezt megtennünk?

1. Töltsük be Visual Studio-ba a projektünket
2. Válasszuk ki a projekt fájl tulajdonságait
   Ennek hatására az alábbi ablak jelenik meg:
   
3. Válasszuk ki a Build fület
4. Állítsuk be a Platform Target-et x86-ra
5. Fordítsuk újra az alkalmazást

Ezt követõen a programunk szépen fog mûködni. A kérdés már csak az, hogy miért is nem lehet ezt x64 alatt simán futtatni? Miért nem tudja ezt a fõ zászlóshajók egyike sem (Vista x64, Windows2008 Server) futtatni?
Merõ luxus és felvágás csak ez az x64!

Lapzárta után érkezett:
Amúgy az MS KB-k között van egy cikk ami sokak szerint megoldás: http://support.microsoft.com/kb/278604

A clusterek önálló állatfajták, kezelésük, használatuk – minden ellentétes híreszteléssel szemben – azért kihívások elé állítja a rendszer üzemeltetõket. Tudom, hogy sokak szerint ez nem bonyi, mert ott a GUI és csak össze kell kattintgatni, de amint gond van, nincs más csak a parancssor és ilyenkor az is sokszor megtagadja a munkát.

Miért tagadja meg? Mert nem fut a cluster szolgáltatás (clussvc.exe). Miért nem fut? Mert a quorum, az alap névtér és a saját ip cím kell hozzá. Huhh, de hát nincs qourum! Akkor most mit csináljak? A parancssor sem mûködik (már ez is a service-hez akar kapcsolódni a parancsok kiadása végett).

Nálunk egy mai hiba kapcsán az alábbi megoldás vezetett eredményre (Alaphelyzet: Minden szolgáltatás áll, mert a qourum diszk kiesett):

1. A qourum diszk külsõ alrendszeren való helyreállítása, a fizikai diszk szolgáltatás visszaállítása (igaz üres diszkkel)
2. A szerveren a Cluster Service szolgáltatás manual-ba állítása
3. A szerver újraindítása (így már nem fog a szolgáltatás Starting… állapotba befagyni)
4. A parancssori konzolon a szolgáltatás elindítása -resetqourumlog kapcsolóval
   net start clussvc /resetqourumlog
   A rendszer ennek hatására megkísérli a cluster szolgáltatás elindítását, és a qourum újbóli létrehozását.
5. A szolgáltatás sikeres elindulását követõen kicsit várjunk, mert a cluster teljes erõbõl nekiindul és az összes szolgáltatás elindítása a legcombosabb gépet is könnyen lefékezi. Az elsõ nagy erõbedobást igénylõ mûveletek után már “símán” használhatjuk megszokott Cluster Admin-unkat és minden mehet tovább.

Amennyiben szükséges a cluster service kapcsolóinak az Microsoft KB-ban a Q258078-as cikkben nézhetünk utána.

Sebezhetõségi verseny op.rsz-k között

A PWN2OWN hackerversenyen három ugyanolyan laptopra összerakott és biztonsági patchekkel felvértezett MAC OS X, Windows Vista és Ubuntu Linux állt csatasorba. Az elsõ magát megadó operációs rendszer – többek megdöbbenésére talán – a MAC OS X. A nyertes az Independent Security Evaluators vezetõ elemzõje, Charlie Miller, aki tavaly nyáron bukkant egy kritikus sérülékenységre az iPhone-ban. Ugyanezt a problémát használta ki most, és egy percen belül lerogyasztotta az AirBook-ot. Miller elzárkózott a sebezhetõség közlésétõl, de kiderült, hogy a hibáért a Safari volt a ludas. Miller és két kollégája három hetet töltött a verseny elõtt a problémát kihasználó kód megírásával. (forrás: SecurityFocus)

Új, biztonsági internetböngészõt fejlesztenek az Illinois Egyetem kutatói

Mivel véleményük szerint minden modern webes böngészõ “alapvetõen gyári hibás” és állandó támadásoknak teszik ki a felhasználókat, ezért az Illinois Egyetem kutatói a nulláról kezdve olyan böngészõ fejlesztésébe kezdtek, melynek legfõbb tulajdonsága a biztonsága.
Az OP (Opus Palladium) kódnevû új böngészõ alapötlete egy olyan kisebb alrendszerekbõl felépülõ rendszer készítése, melyben az alrendszerek közti kommunikáció egyszerû és világosan áttekinthetõ. A struktúra lelke egy kis böngészõmag, mely összehangolja az alrendszerek munkáját, emellett ezen keresztül zajlik azok kommunikációja is. A böngészõmag így képes arra, hogy monitorozza, felügyelje és természetesen érvényesítse a megkívánt biztonságot.
A kutatócsoport már elkészítette a teljes értékû prototípust, melyet a májusi ’2008 IEEE Symposium on Security and Privacy’ címû rendezvényen mutatnak be. Ez a változat Linuxon fut és egyelõre a KHTML motort használja, de a hosszú távú tervek szerint a cél egy olyan többplatformos ‘Webkészlet’ elkészítése, melyet a nyíltkódú közösség rendelkezésére bocsátanak. (forrás: eWeek)

A Microsoft vonja vissza a Windows Vista-t

Errõl már egy másik bejegyzésemben megemlékeztem külön is, mert nagyon tetszett a kezdeményezés mögött állók indokhalmaza. Van benne igazság is, bár azért nem mindig kellene a fejlõdés elé menni, igaz a fejlesztés sem minden áron kell…

Egy hónap múlva jön a Windows XP SP3

A Microsoft egyelõre nem kommentálta a TechARP értesülését, a vállalat szóvivõje csak a korábban is megállapított határidõt ismételte meg: “2008 elsõ felében jön ki az XP SP3 RTM (a gyártásra kész változat), az idõzítés pedig, mint mindig, a felhasználói visszajelzések fügvényében alakul.” Mint arról korábban beszámoltunk, a Microsoft legutóbb bõ egy hónappal ezelõtt tette közzé az XP SP3 RC2-t, vagyis a szervizcsomag második kiadásra jelölt változatát a Windows Update rendszerén keresztül. A fájlcserélõ hálózatokon két hete felbukkanó, 5503-as buildrõl a szoftvercég elismerte, hogy valódi, bár csak a bétatesztelõk szûkebb csoportjának szánták; ezzel kapcsolatban sietve leszögezték, hogy – mivel nem hivatalos forrásról beszélünk – a kód illetéktelen módosításokat tartalmazhat.
A Windows XP történetében 2008. június 30. és 2009. január 31. lesznek a következõ mérföldkövek. Nyáron fejezik be ugyanis az immár SP3-as rendszerek viszonteladói és “dobozos” értékesítését, januártól pedig az összes terjesztési csatornát lezárják, beleértve a számítógépgyártókat is. A Windows XP támogatása ezzel együtt sem szûnik meg egészen 2010-ig, vagyis a Windows 7 tervezett megjelenéséig; 2009. áprilisában csupán az XP SP2 “mainstream” támogatása ér véget. (forrás: Computerworl.hu)

Nekültem tehát, hogy az eddig mostohaként kezelt – értsd nem használt – felhasználó kezelést megismerjem és használatba vegyem. Elsõ lépésben áttekintettem mit is nyújt számomra az IIS 7 majd átnéztem milyen kontrolok és lehetõségek vannak az ASP.NET 3.5 felületen – a Visual Studio 2008-ból elérhetõen – a kezemben. A terület elsõre sem rövid – hát még ha az ember bele is mélyed – de azért megpróbálom a benyomásaimat érthetõ formára hozva felvésni.

Nézzük mire is jutottam.

IIS 7.0 ASP.NET szolgáltatásai

Elsõ lépésben elõvettem teszt virtuális környezetemet és feltettem rá az IIS 7-t (meg persze elõtte a Windows 2008 Standard Servert ). Kellemes meglepetés fogadott üzemeltetõi szemmel nézve a dolgokat, mert elérhetõ és kényelmesen kezelhetõ minden olyan szolgáltatás amit a fejlesztõi felületen ASP.NET Configuration site-n keresztül lehet használni (sõt még további “apróságok” is).

Amint az a fenti képeken is jól látható, az IIS 7 gyárilag tartalmazza már a Role, az User és a többi komponens adminisztrációjához szükséges felületeket. Ezen felül valóban lehet adminisztrálni is ezeket, azaz már egy üzemi szolgáltatásnak nem feltétele, hogy az ember saját maga megírja az adminisztrációhoz szükséges alapvetõ felületeket. Gondoljunk csak arra, hogy éles üzemben bármikor szólhatnak, hogy nézzünk utána ennek vagy annak a felhasználónak létezik-e, és az ember nem szeret ilyenkor SQL táblákban és query-kben kutakodni. Természetesen fontos az is – amennyiben másképp nem rendelkezünk – a rendszer titkosítva tárolja a felhasználói azonosítás során kapott jelszavakat (hány rendszer bukik meg ezen apró de lényeges kérdésen a SOX auditok kapcsán).

Melyek a legfontosabb beállítási lehetõségek – szerintem -, vegyük Őket sorba:

• Alkalmazás beállítások
• Machine Key beállítások
• Felhasználókezelés és beállításai
• Role-ok beállítása
• Connection String-ek kezelése
• SMTP beállítások
• Session State kezelés beállításai

Van még egy fontos beállításokat tartalmazó terület, ez az Application Pool kezelését szabályzó rész.

IIS 7 ASP.NET Alkalmazás beállítások

Az alkalmazás paramétereit számos helyen és módon szabályozhatjuk az IIS 7-ben. Ezeket jellemzõen egy rendszerben csak egyszer állítunk be, illetve nem mindennap módosítjuk, hisz ezek nagyban befolyásolják rendszerünk mûködését.

Elsõ legfontosabb terület, hogy az alkalmazás fix paramétereit tudjuk könnyen kezelni (Application Settings). Az itt kezelt paramétereket a webes alkalmazásunk mint állandókat alkalmazza, de nekünk lehetõségünk van arra, hogy az egyes paramétereket minden esetben külön-külön szabályozhassuk.

Az alkalmazás mûködésének következõ beállítási felülete, az ASP.NET kódlapkezeléseket szabályzó oldala, az ASP.NET Globalization oldal. Ezen az oldalon egyenként adhatjuk meg, hogy a rendser mely fájlokat milyen kódlap szerint kezeljen alapértelmezésben (nem semmi! Ezzel régebben azért volt nyûg).

Ezután jön egy fontos beállítási lehetõség, a Machine Key beállítások halmaza. A képet nézve szerintem nem kell sok magyarázat ahhoz miket is lehet itt szabályozni. Fontos és lényeges, hogy itt kell beállítani milyen módon kezeljük a hozzánk érkezõ bizalmas adatokat, és miképp tároljuk azokat.

Ezek után már csak egy rész maradt, itt a folyamatszálak kezelését lehet szabályozni.

Kapcsolati stringek

Az egyes alkalmazások mûködése során jelentõs fontosságú, hogy mikor merre és milyen paraméterekkel kapcsolódunk az alkalmazás által használt adatbázisokhoz. A rendszer alapértelmezésben alkalmazott LocalSqlServer kapcsolata mellett a számunkra illetve az alkalmazásunk számára szükséges mennyiségû kapcsolati stringet vehetünk fel.

Érdekesség, hogy a LocalSqlServer kapcsolat mûködése alapértelmezésben az adatbázishoz csak a futásidõben kapcsolódó adatbázis szolgálja ki, amely alapesetben az ASP.NET DataDirectory-ban (/app_data) található aspnetdb.mdf fájl. Amennyiben a rendszerünk kiszolgálását nem MS SQL 2005 Express szolgálja ki, úgy ezen a beállításon – a számunkra szükséges módon – de változtatnunk kell!

SMTP E-mail beállítások

Amennyiben az alkalmazásunk bármilyen oknál fogva levelezni kíván – akár a felhasználókezelés miatt, akár általunk programozottan – akkor szükségünk van az E-mail szolgáltatások elérésének beállítására. Ezt az ASP.NET E-mail beállítások-nál tehetjük meg.

A beállítások értelmezése nem bonyolult, egy fontos dolog van, amennyiben az SMTP szerverhez a Use Localhost kapcsolót kapcsoljuk be, akkor szükségünk van a szerverünkre telepített – és megfelelõen konfigurált – SMTP szolgáltatásra. Ez alapértelmezésben megtalálható az IIS szolgáltatások között, de természetesen telepíthetünk a szerverre Exchange szervert is.

Role-k

A role-k az alkalmazásunk felhasználóinak logikai csoportosítását teszi lehetõvé, akár secuirty group-nak is kezelhetjük. Adminisztrációja roppant egyszerû, hisz csak egy nevet kell felvenni, vagy módosítani. Figyeljünk azomban arra, hogy az alkalmazás programozása során a neveket fixen kell “beégetni”, azaz ne nagyon piszkáljuk el a neveket, ha az alkalmazás forráskódja nincs a kezünkben!

Felhasználók kezelése

Végül eljutottunk az egész másik fontos részéhez a felhasználók kezelésének adminisztrációjához. A rendszer alapértelmezésben az ASP.NET felhasználókezelésében csak a gyári paramétereket kezeli, de ezeket – amennyiben szabályosan konfiguráljuk a rendszerünket a web.config fájlban – mi magunk is szabályozhatjuk. Az így megadott konfiguráció a kezelõfelületek is mûködését is szabályozzák!

Persze nem kis dolog, hogy listázni lehet a felhasználóinkat, de ugyanilyen fontos az is, hogy mi magunk is felvehetünk felhasználókat. Ezen felhasználókat az Add .NET User wizard-on keresztük vehetjük fel.

A felvehetõ paraméterek ebben az esetben csak a gyári adatok – míg a webes felület felvételi részén további paramétereket is “kikényszeríthetünk”, felvehetünk. Lényeges, hogy a Wizard is figyeli a web.config fájlban megadott jelszó szabályokat. Alapértelmezésben – ha másképp nem szabályozzuk – a rendszer minimális jelszóhossza 7 karakter, és ebbõl legalább egy karakter nem alfanumerikus jel kell legyen.
Második lépésben a meg kell adnunk, hogy felhasználónk milyen role-k birtokosa. Ezt egyszerûen az érintett role-k bekattintásával végezhetjük el.

Ezt követõen a Finish gomb megnyomására a rendszer elvégzi a szükséges ellenõrzéseket, majd – ha semmilyen gondot nem érzékel – akkor létrehozza a szükséges felhasználót. A felhasználónk automatikusan aktív állapotú lesz, és ezt követõen akár azonnal bejelentkezhet és használhatja alkalmazásunkat.

ASP.NET 3.x felhasználókezelési szolgáltatásait – az olvashatóság és kezelhetõség végett – egy következõ bejegyzésben tárgyalom.

A kommenteket nézegetve megdöbbentõ volt látni, hogy még mindig mekkora elfogultsággal és bigottsággal nézik emberek az IT rendszereket. Míg a bejegyzés az alábbi érdekes két bekezdést tartalmazta:

Az igazgató – aki szerint ezek a dolgok mûködnek jól a nyílt forrású közösségben – példákat ír arra, hogy hogyan alkalmazták ezeket az elveket a Windows Server 2008 fejlesztése során. Bevallotta, hogy tanultak és folyamatosan tanulnak a nyílt forrású fejlesztési elvekbõl.

Sam Ramji elõadást fog tartani errõl San Francisco-ban az Open Source Business Conference rendezvényen, aholis a Linux Foundation részérõl Jim Zemlin fog beszélni arról, hogy “Mit tanulhat a nyílt forrás a Microsoft-tól és a proprietary világtól” címmel.

Addig magyar barátainakt nem ez, hanem a “lopnak tõlünk”, felhang kötötte le! Elképesztõ! Fel kéne már odáig nõni embereknek, hogy szinte semmi sem most kitalált dolog, hanem az eredeti “õs” számítástechnika megfelelõ adoptációja. Az egész LINUX-WINDOWS hitvita teljesen elképeszt újra és újra. Miért hiszi bárki, hogy az egyik jobb mint a másik? Nincs szent grál, csak egyik vagy másik feladatnak jobban megfelelõ, vagy kevésbé alkalmas rendszer. És itt már nem csak a bitszintû dolgokkal kéne foglalkozni!

Az eredeti cikk Port25 oldalán, a HUP.HU cikke – és bejegyzései – meg a hup oldalán olvasható.

http://windowsvienna.com/