Chocolatey és a biztonság

Úgy döntöttem, hogy a Windows 10-zel frissen újratelepített gépemre Chocolatey-vel fogom feltelepíteni az alkalmazásokat. Valójában az első ötletem az volt, hogy OneGet-et fogok használni, ami a Windows 10-ben megjelent csomagkezelő-kezelő, és aminek van egy előzetes Chocolatey providere, de mivel ezzel rövid kísérletezés után nem sok sikerélményem volt, maradtam közvetlenül a Chocolatey-nél.

Az első lépés a Chocolatey telepítése, aminek legegyszerűbb módja admin parancssorban annak az egysoros szkriptnek a futtatása, ami megtalálható a chocolatey.org honlapon:

C:\> @powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1’))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Ezzel a paranccsal három dolgot érünk el egy csapásra:

  1. Letöltünk egy PowerShell szkriptet.
  2. Futtatjuk a letöltött szkriptet a saját gépünkön rendszergazdai jogosultságokkal.
  3. Kiegészítjük a PATH környezeti változónkat.

Nem tudom, ki hogy van vele, a 2. lépéstől kiráz a hideg. És ha már itt tartunk, álljunk meg egy pillanatra és gondoljuk végig, mire vállalkozunk: gyakorlatilag ismeretlen forrásból származó alkalmazásokat fogunk telepíteni a gépünkre, hiszen amikor kiadjuk mondjuk a

choco install adobereader

parancsot, akkor fogalmunk sincs, hogy honnan mi fog letöltődni és települni a gépünkre.

Mit tehetünk?

Először is csak olyan choco csomagokat telepítsünk, amiket moderátorok jóváhagytak. A moderálás egy manuális folyamat, csúszhat bele hiba, de mégis egyfajta ellenőrzés. Egy moderált csomag, például az Adobe Reader oldalán ez jelenik meg felül nagy zöld keretben:

This package was approved by moderator gep13 on 6/11/2015.

Egy moderátori ellenőrzésen nem átesett csomag, például a Notepad2 esetén ugyanott piros keretben ezt találjuk:

This package was submitted prior to moderation and has not been approved. While it is likely safe for you, there is more risk involved.

Ha már a csomag részletes oldalán vagyunk, érdemes elolvasni mindent, amit ott találunk. Például a 7-zip csomag oldalán ezzel a figyelmeztetéssel találkozhatunk:

NOTE: The installer for 7-Zip is known to close the explorer process. This means you may lose current work.

Ugyanitt találkozhatunk hasznos opciókkal is, például Firefox esetén megadhatjuk, milyen nyelvű verziót szeretnénk telepíteni:

choco install Firefox -packageParameters "l=en-US"

Ha pedig egy kicsit lejjebb görgetünk, a kommentek között találhatunk olyan utalásokat, amik eltántoríthatnak minket egy-egy csomag telepítésétől. A CDBurnerXP csomag kommentjei között megemlítik az OpenCandy nevű szemetet, amiről eszembe jutott, hogy bizony nem egy olyan telepítővel találkoztam már, amin ha ész nélkül next-next-finish-sel megyünk végig, kapunk “ajándékba” egyéb programokat is.

Az oldal közepe táján sok esetben megtaláljuk a telepítő PowerShell szkriptet, érdemes lehet átnézni, mert abból kiderülhet, hogy milyen telepítőcsomagot tölt le és honnan. Az Adobe Reader csomagjánál ez a szkript mindössze 6 sor, a közepén ott virít az URL és könnyen érthető, hogy mi történik. De ugyanezt nem lehet elmondani a Firefox csomag 117 soros szkriptjéről, vagy a Node.js csomag egyetlen soros szkriptjéről, ami két másik csomagra hivatkozik.

Összességében a Chocolatey használata véleményem szerint egy jókora lutri. Elvégezhetjük ezeket a manuális ellenőrzéseket, frissíthetjük az operációs rendszerünket, beüzemelhetünk egy víruskeresőt, kiszűrhetjük a csibész hostokat, de a végeredmény az, hogy ismeretlen szerző ismeretlen kódját futtatjuk a gépünkön, ami sehogy sem tűnik jó ötletnek.

Én ezeket a csomagokat telepítettem fel, egyelőre nem égett le a ház tőlük:

adobereader
7zip
emet
fiddler
filezilla
firefox -packageParameters "l=en-US"
gitextensions
google-chrome-x64
join.me
keepass
nodejs
paint.net
silverlight
skype
sysinternals
vlc

Ti mit gondoltok, használtok ilyet, meritek használni, és ha igen, milyen csomagokat szoktatok még feltenni?

 

Technorati-címkék: ,,
Kategóriák:Biztonság, Windows Címke: ,

Bitlocker TPM nélkül

2015.08.19. 11:28 Hozzászólás

A közhiedelemmel ellentétben igenis használható a Windows beépített Bitlockere a merevlemez tartalmának titkosítására akkor is, ha nincs a gépünkben TPM chip. Azokat a meghajtókat, amik az adatainkat tartalmazzák, simán hagyja is a Windows titkosítani, mindössze egy jelszót kér, és felajánlja a recovery key mentését fájlba, USB meghajtóra, sőt akár a felhőbe is. Ha viszont a C: meghajtónkat akarjuk bebitlockerezni, akkor találkozhatunk ezzel a hibaüzenettel:

This device can’t use a Trusted Platform Module. Your administrator must set the “Allow BitLocker without a compatible TPM” option in the “Require additional authentication at startup” policy for OS volumes.

bitlocker-1-tpm-error

Szerintem ez egy egészen jó hibaüzenet, mert megmondja, hogy mi a gond, és azt is, hogyan tudunk kimászni belőle. Ha még azt is megmondaná, hol keressük pontosan ezt a beállítást, egészen tökéletes lenne!

A “policy” szóra keresve ugyanis léptem nyomon a Local Security Policy-ba futhatunk bele, pedig nem az kell. A Group Policy Object Editorra van szükségünk még akkor is, ha workgroupban van az adott gép és nem tartományban. (A csoportházirendekről nekem mindig a címtár jut eszembe…)

Indítsunk tehát egy Microsoft Management Console-t (mmc), majd adjuk hozzá a Group Policy Object Editor snap-int (katt a teljes képért):

bitlocker-2-mmc-add-snapin

Ezen belül a Local Computer Policy –> Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption –> Operating System Drives ág alatt találhatjuk meg a hibaüzenetben megjelölt beállítást:

bitlocker-3-policy-path

A beállításra duplán kattintva előbb válasszuk ki az Enabled lehetőséget, majd alul pipáljuk be az Allow Bitlocker without a compatible TPM jelölőnégyzetet:

bitlocker-4-policy-setting

Miután mindent leokéztunk még frissítenünk kell a házirendet, amit a gépünk újraindítása nélkül legegyszerűbben parancssorból a gpupdate parancs kiadásával tehetünk meg:

bitlocker-5-gpupdate

Ezután már gond nélkül titkosíthatjuk az operációs rendszert tartalmazó meghajtónkat is.

 

Technorati-címkék: ,,
Kategóriák:Windows Címke: , ,

Windows 10 telepítés: UEFI, secure boot, USB, GPT, error

Windows 10-et próbáltam telepíteni, amihez letöltöttem az ISO image-et az MSDN-ről, majd a jól bevált Windows USB/DVD Download Tool segítségével kiírtam pendrive-ra. Azonban a gép nem akarta felismerni a pendrive-ot, nem kínálta fel azt a lehetőséget, hogy bootoljak róla. A BIOS-ban a boot beállítások UEFI boot ON, secure boot ON értéken álltak, ami jól bevált az adott gépen korábban futó Windows 8.1 esetén, de most épp ez okozta a problémát. Ha átkapcsoltam ugyanis Legacy boot ON, secure boot OFF értékre, akkor máris megjelent a pendrive, és el is indult a telepítés. Itt azonban még nincs vége a történetnek, később ugyanis elakadt a telepítő

Windows cannot be installed to this disk. The selected disk is of the GPT partition style.

hibaüzenettel.

windows-install-gpt-error

Rövid guglizás után számos megoldást találtam arra, hogy lehet egy GPT partíciót MBR-re alakítani (a teljes diszken lévő adatok elvesztésével vagy 3rd party boot CD-vel), de szerencsére annál van egyszerűbb megoldás is.

 

Az egyszerűbb megoldás

A probléma valódi gyökere, hogy az UEFI boot nem megy NTFS-re formázott pendrive-val (legalábbis az én gépemen), a megoldás tehát, hogy

FAT32-es pendrive kell.

Sajnos az eszköz, amit az ISO image kiírásához használtam, mindenképp NTFS-re formázza a pendrive-ot, még akkor is, ha korábban már meg volt formázva, tehát máshogy kell előkészítenünk a telepítő pendrive-ot.

Például diskpart, ami egy beépített parancssori eszköz a Windows-ban.

Indítsuk el:

diskpart

Listázzuk a meghajtókat:

list disk

A listában meg fog jelenni a pendrive is (mert remélhetőleg előtte bedugtuk), a mérete alapján meg fogjuk ismerni. Válasszuk ki:

select disk 2 (a 2 helyére természetesen a valódi szám kerüljön)

Töröljük le (minden adat el fog veszni):

clean

Hozzunk létre rajta egy FAT32 partíciót:

create partition primary
select partition 1
active
format quick fs=fat32
assign

Ezután ki is léphetünk a diskpartból:

exit

Ezután már csak rá kell másolnunk a telepítőkészletet a pendrive-ra. Ehhez először mountoljuk fel az ISO-t, majd másolhatunk például így (a példában D: a felmountolt ISO, F: a cél pendrive):

xcopy d:\* f:\ /s /e

Ezek után már fel fogja ismerni a BIOS a pendrive-ot, és a meghajtó kiválasztásánál sem lesz probléma a GPT partícióval.

 

Technorati-címkék: ,,
Kategóriák:Windows Címke:

Szerdán SQL-es developer meetup

2015.04.13. 11:13 Hozzászólás

Ezen a héten szerdán ötödik állomásához érkezik a LogMeIn és a Microsoft Magyarország közös szervezésében készülő Enterprise Developer Meetup sorozat. Erre az alkalomra csupa adatbázisos témával készülünk, lesz szó teljesítményről, biztonságról és természetesen a felhőről is. Várunk mindenkit, akit érdekelnek a Microsoft adatbázis platformjának újdonságai, akár távolabbról architektúra szintjén, akár közelebbről, kód szinten.

kalen-delaney

Az első előadónk Kalen Delaney, aki 26 éve foglalkozik az SQL Serverrel, így nem véletlen, hogy az ő nevéhez kötődik szinte az összes “inside” és “internals” könyv a témában. Kalen kifejezetten a LogMeIn meghívására érkezik hazánkba, és szerdán az SQL Server 2014-ben bevezetett, korábban “Hekaton” kódnéven futó SQL Server In-Memory OLTP-ről fog beszélni. A Hekaton lényege, hogy az adatbázis motort az adatok memóriában történő tárolására optimalizálták, amivel természetesen jelentős teljesítmény növekedést lehet elérni.

 

koszo-karoly

Második előadónkat, Kószó Károlyt a magyar SQL fejlesztőknek nem kell bemutatni, hiszen 1996 és 2013 között a Microsoft Magyarország munkatársaként számos rendezvényen adott elő az SQL Serverről. Szerdán az SQL Server jogosultságkezeléséről fog beszélni, kitérve olyan kevésbé ismert témákra is, mint a tulajdonosi lánc és az aláírt tárolt eljárások. Érdemes elmélyednünk a témában, hiszen a legféltettebb adataink biztonságáról van szó!

 

 

 

dudas-viktor

Harmadik előadónk, Dudás Viktor, korábban már szerepelt nálunk, akkor az Azure Machine Learningről és gépi tanulásról beszélt. He is back! Ezúttal a Tabular Analysis Servert veszi górcső alá, természetesen a felhőben.

 

 

 

 

A társaság jó, a részvétel ingyenes, a szervezés érdekében csak annyit kérünk, nyomjatok egy RSVP: Yes-t előre.

Bővebb információ és jelentkezés itt:
http://www.meetup.com/Enterprise-Developer-Meetup/events/221592899/

Szeretettel várunk mindenkit szerdán 19 órakor a LogMeInben (Paulay Ede u. 12.)!

 

Technorati-címkék: ,,
Kategóriák:Adatkezelés Címke: ,

C# kód futtatása Node.js környezetben Roslyn segítségével

Amikor a Microsoft Managed Languages csapata 2013. decemberében bejelentette, hogy a korábbi C# és Visual Basic fordítót lecserélték, és már a Visual Studio következő verziójának napi buildjei is egy új fordítóval készülnek, hirtelen mindenki számára egyértelművé vált, hogy valami nagyon komoly dolog van készülőben. Az új, “Roslyn” kódnevű eszköz messze túlmutat a korábbi csc.exe és vbc.exe képességein és lehetőségein, nem véletlenül kapta végül a .NET Compiler Platform elnevezést.

Itt ugyanis nem egyszerűen arról van szó, hogy szeretnénk a forráskódunkat futtatható formára alakítani, hiszen arra már sok éve volt kiváló eszközünk. A Roslyn célja, hogy a fordító tudását API-kon keresztül megnyissa a fejlesztők és a fejlesztőkörnyezetek (például a Visual Studio) előtt, azaz egy fordító-mint-szolgáltatás (compiler-as-a-service) megoldásról beszélhetünk.

Miért van erre szükség? Leginkább azért, mert a fordítók nagyon összetett szerkezetek, és futásuk közben igen komoly mennyiségű információval rendelkeznek a forráskódunkról:

compiler-architecture

Ezt a tudást vétek bezárni egyetlen eszközbe, sokkal jobban járunk, ha a fordító által felhalmozott információkból más eszközök is mazsolázhatnak. A fordító az egyetlen eszközünk, amely valóban érti a forráskódunkat, hiszen a kód minden egyes betűjéről tudja, hogy az utasítás, adat, komment stb. Ezt felhasználva sokkal jobb fejlesztőeszközöket készíthetünk, például a Visual Studio 2015 kódszerkesztőjében számos funkció a Roslyn nélkül valószínűleg soha nem valósulhatott volna meg.

Az alábbi ábra a Roslyn platform felépítését mutatja (katt a teljes képért):

roslyn-architecture

Aki szeretne minden egyes dobozt megérteni, bátran látogasson el a projekt honlapjára, én itt most csak annyit emelnék ki, hogy a forráskód olvasásától az értelmezésén keresztül egészen a futtatható kód generálásáig megtalálható itt minden, és mivel platformról van szó, természetesen mindenhez van API.

A kulcs elem a sárgával bekeretezett Syntax Tree, ami a Parser által létrehozott belső reprezentációja a teljes forráskódunknak. Az ehhez tartozó API-t hívják Roslyn Syntax API-nak, aminek segítségével nem csak forráskódból értelmezhetjük a forráskódunkat, hanem módosíthatjuk is azt. Példaként vegyük az alábbi utasítást:

Regex.Match("my text", @"\pXXX");

Ebből a Roslyn az alábbi szintakszisfát építi fel:

Turner_Figure4_hires

(A példát az MSDN Magazine Use Roslyn to Write a Live Code Analyzer for Your API című cikkéből kölcsönöztem, amiben egy Visual Studio bővítményt készítenek erre alapozva.)

Hogy mi ezt a fát pusztán csak nézegetjük, elemezzük, vagy módosítjuk is, az már kizárólag csak rajtunk múlik.

Felismerte ezt a TypeScript csapat is, és az 1.3 verziótól kezdve már a Roslyn motor szolgáltatja Visual Studioban a kódszerkesztő funkciókhoz a szükséges adatokat. Ennek köszönhetően a TypeScript fordító architektúrája nem csak hogy jelentősen letisztult, hanem egyúttal könnyebben érthetővé is vált:

typescript-architecture

Történetünk szempontjából az egyik fontos komponens az alsó dobozban szereplő Parser, a másik pedig az Emitter. A Parser feladata, hogy felépítse az absztrakt szintakszisfát – jelen esetben a TypeScript forráskódból –, az Emitter feladata pedig, hogy a szintakszisfa alapján elkészítse a fordító kimenetét – jelen esetben JavaScript (.js), definíció (.d.ts) vagy source map (.js.map) formában.

Érdemes észrevenni, hogy a Roslyn és a TypeScript architektúrája teljesen hasonló: a forráskódból előbb fát építünk, majd a fából más nyelvű kódot generálunk. A Roslyn esetén ez C# –> fa –> IL, a TypeScript esetén egy TypeScript –> fa –> JavaScript.

Mivel a két fa azonos, összekapcsolhatjuk a kettőt és így máris eljutunk az alábbi megoldáshoz:

flow

Azaz a Roslyn és a TypeScript felhasználásával képesek lehetünk C# forráskódot JavaScriptre fordítani!

A módszer előnye, hogy mivel közvetlenül a C# forráskódból indulunk ki (ellentétben például a JSIL projekttel, ahol Common Intermediate Language kódot fordítanak JavaScriptre), minden olyan információ rendelkezésünkre áll, ami a forráskódban még elérhető (például láthatóság, öröklés stb.), de egyébként a C# fordító kimenetén már nem jelenik meg. Mindez meglepően hatékony optimalizálási lehetőségeket nyújt!

Példaként vegyük a JSIL projekt oldalán elérhető Raytracer demót. A teljes C# forráskód 429 sor, a JSIL által készített JavaScript kód 793 sor. Mondhatnánk,  hogy örülhetünk, hogy egyáltalán fut, csakhogy a memória kezelése korántsem optimális:

raytracer-memory

Ugyanezt a forráskódot a Roslyn Parser + TypeScript Emitter kombináción átfuttatva az alábbi eredményt kapjuk:

raytracer-memory-2

Az Internet Explorer Developer Toolsban (F12) lévő UI Responsiveness eszköz segítségével megmértük a CPU utilization és a Visual throughput (FPS) értékeket is, és mindkét mutató jelentősen jobb értékeket mutatott.

Persze a kedvezőbb memória gazdálkodás és a jobb teljesítmény nem jön ingyen, a generált kód nagyobb lett, összesen 1844 sor. A jelentős méretnövekedést az okozza, hogy az IL kóddal ellentétben a szintakszisfa tartalmaz információt az osztályokról és azokon belül a tagok láthatóságáról, amit JavaScriptben csak körülményesen lehet leképezni, de ha megtesszük (és a TypeScript Emitter meg tudja tenni), akkor több kód letöltése árán összességében jobb teljesítményt tudunk elérni. Más alkalmazások vizsgálata során is ugyanerre a megállapításra jutottunk.

A módszer természetesen nem csak böngésző alapú alkalmazásoknál, hanem natív JavaScript alkalmazásoknál, például Node.js környezetben is működik. A fejlesztés lépései a következők:

  1. Telepítsd a Node.js Tools for Visual Studio bővítményt, ami lehetővé teszi Node.js appok készítését Visual Studioval.
  2. Töltsd le a Node.js with C# bővítményt a Visual Studio Gallery oldaláról (hamarosan elérhetővé tesszük).
  3. Telepítés után meg fog jelenni Visual Studioban a C# projektek között egy “Node.js application” nevű projekt sablon, annak segítségével kell létrehozni a projektet.
  4. Írd meg az alkalmazásod forráskódját C#-ban, ehhez természetesen használhatod a Visual Studiot.
  5. A szokásos módon működik a debuggolás (F5) és a futtatás is. A projekt sablon tartalmazza a szükséges MSBuild targeteket, ami a Roslyn és a TypeScript segítségével előállítja a JavaScript kódot, amit azután a Node.js Tools for Visual Studio fog átadni a Node.js futtatókörnyezetnek.

Tesztelőket keresünk! A Visual Studio plugin publikálása előtt szeretnénk egy szélesebb körű tesztet végezni. Ha szívesen vállalkoznál erre, kérlek itt olvasd el az útmutatót, majd hagyj egy kommentet alább és felveszem veled a kapcsolatot!

 

Frissítés:

reddit-node

http://www.reddit.com/r/node/comments/31r872/write_your_nodejs_app_in_c_with_roslyn/

 

Kategóriák:Webfejlesztés Címke: , ,

Öröklésnél elveszik az Error message tulajdonsága

Ilyen kódot már mindenki látott:

try {
  throw new Error('Oh, nooooo!');
} catch (e) {
  console.log(e.message);            // Oh, nooooo!
  console.log(e instanceof Error);   // true
}

Ha nagyon sok hasonló keletkezik, akkor előbb-utóbb az ember rájön, hogy szükség lenne saját hiba osztályokra, még JavaScriptben is. Jó ötletnek tűnhet valahogy így létrehozni egyet:

function OhNoooError() {
  Error.call(this, "Oh, nooooo!");
  this.name = "OhNoooError";
}

Az eredmény azonban meglepő lehet:

try {
  throw new OhNoooError();
} catch (e) {
  console.log(e.message);                 // undefined
  console.log(e instanceof OhNoooError);  // true
  console.log(e instanceof Error);        // false
}

Az elkapott kivételünk ugyanis nem számít klasszikus Errornak (nem abból származik), és elveszítette a message tulajdonságát is.

Íme egy módszer, amivel ezeket a hibákat orvosolni lehet:

OhNoooError.prototype = Object.create(Error.prototype);
OhNoooError.prototype.constructor = OhNoooError;

function OhNoooError() {
  this.message = "Oh, nooooo!";
  this.name = "OhNoooError";
}

A kimenet is szebb lesz:

try {
  throw new OhNoooError();
} catch (e) {
  console.log(e.message);                 // Oh, nooooo!
  console.log(e instanceof OhNoooError);  // true
  console.log(e instanceof Error);        // true
}

A lényeg tehát, hogy a message tulajdonságot kézzel kell beállítani. Ha az öröklést esetleg CoffeeScriptben az extends kulcsszóval valósítjuk meg, a message tulajdonsággal akkor is manuálisan kell elbánnunk.

 

Technorati-címkék: ,
Kategóriák:Webfejlesztés Címke: ,

WebStorm, ne keresgélj a node_modules mappában!

2015.03.13. 16:53 Hozzászólás

Idegesít, hogy szinte bármire keresel egy node.js projektben, a WebStorm legalább ezer találatot hoz a node_modules mappából?

Semmi gond, irány a Project ablak, jobb klikk a problémás mappán, majd Mark Directory As –> Excluded:

webstorm-exclude-folder-from-search

Nem fog eltűnni a mappa a Project ablakból, de már nem fognak innen bekerülni találatok a keresésbe.

Visszatenni is ugyanitt lehet: Mark Directory As –> Cancel Exclusion

webstorm-exclude-folder-from-search-cancel

 

Technorati-címkék: ,
Kategóriák:Webfejlesztés Címke: ,
Követem

Értesítést küldünk minden új bejegyzésről a megadott e-mail címre.

Csatlakozz a 91 követőhöz

%d blogger ezt szereti: