vSphere 5.1 – vCenter Server Appliance

Már jó ideje megjelent a vSphere termékcsalád 5.1-es verziója, ami nem kevés új szolgáltatást is ígér az 5.0-hoz képest. A legtöbb változás azonban mindenképp a vCenter Server egyes szolgáltatásaiban és működésében található.

Miután átfutottuk a szemkápzáztató és remek új fícsörökről szóló hivatalos kiadványt, felocsúdásképp nem árt tüzetesen végigolvasni a koránt sem annyira bíztató, és lényegesen hosszabb ismert hibák listáját is!

Ahogy az látható, a legtöbb dolog a vCenter Server újdonságairól szól – azonban az ezzel kapcsolatos hibák ismert problémák sokasága több mint szánalmas. Első olvasás után azt hittem, hogy véletlenül a béta programba tévedtem… de nem, ez bizony a hivatalos ‘stabil’ kiadás… ráadásul a verziószám alapján is csak kisebb változásokra számítottam.

Ettől függetlenül, igen nagy bizalommal álltam neki a tesztelésnek, ugyanis olyan változtatásokat eszközöltek, amik jelentősen növelték a vSphere 5.0 verziójában megjelent vCenter Server Appliance megoldás életképességét.

Megfigyelhető, hogy a ‘normál’ windows alapú vCenter Serverről egyáltalán nem írok. Ennek az az oka, hogy valójában ugyan az a java alkalmazáshalmaz mindkét megoldás,  csak MS Windows és MS SQL szerver kell alá. Mivel számunkra mindkettő csak felesleges kínokat jelent, így örömmel szabadultunk meg tőlük véglegesen.

Lássuk tehát a vCenter Server Appliance újdonságait:

Adatbázis

Gyorsan rájöttek hogy a DB2 ezen termék esetében zsákutca, és végre belátták hogy egy nyílt forrású termékre kell cserélni, így az appliance saját belső adatbázisa az 5.0.1 verziótól már PostgreSQL alapú. Hurrá! :)

vCenter Single Sign-On

A komponens neve – köszönhetően az erős marketing nyomásnak – sajnos eléggé megtévesztő. Valójában ez egy authentikációs szerver, ami a következő forrásokból képes authentikálni a felhasználókat:

  • Operációs Rendszer

Tehát az őt kiszolgáló operációs rendszerben létező felhasználók és csoportok alapján. Ez a funkció már eddig is létezett, ám ennek használata éles üzemben biztonsági okok miatt nem javasolt.

  • Saját, belső felhasználói adatbázis

Ha minden egyéb rendszertől függetleníteni szeretnénk a vCenter felhasználók kezelését, akkor ez nagyon hasznos lehetőség. Fontos továbbá, hogy csak ebben az esetben van lehetőség a felhasználóknak a saját jelszavuk megváltoztatására a vSphere Web Client-en keresztül.

  • OpenLDAP

A felhasználókat és a csoportokat tudja standard LDAP adatbázisból is venni, azonban arról nem szól egyetlen (általam ismert) dokumentáció sem, hogy milyen objektumokat kellene ebben létrehoznunk, hogy ez sikerüljön is :(

  • Active Directory

Ez a leggyakrabban használt megoldás, ugyanis legtöbb helyen már létezik AD, amiben a felhasználókat nyilvántartják, így alapvető igény hogy a vCenter is része lehessen ennek jónak. A megvalósítása kétféleképpen lehetséges:

Az AD-t, csak LDAP forrásként használja

Az AD ugyanis valójában – bármennyire is szeretik ezt elmisztifikálni – egy egyszerű LDAP adatbázisra épül. Ez esetben a vCenter (vagy annak bármilyen komponense) nincs beléptetve a domain-ba, ‘csak’ egy ‘service account’-ra van szüksége, hogy le tudja kérdezni a felhasználók adatait. (ez a gyakorlatban sajnos domain adminisztrátori jogokat jelent)

vCenter-auth-source

Belép az AD által nyújtott domain-be

Ilyenkor az SSO szerver belép a domain-be, mint egy normál munkaállomás. KIZÁRÓLAG ilyenkor beszélhetünk SSO-ról, ugyanis ez esetben a domain-be beléptetett kliensek kerberos ticketek segítségével authentikálna a vCenter szolgáltatásokhoz, így nincs szükség a felhasználónév/jelszó páros ismételt bevitelére.

vCenter-AD-domain

Persze ha elvonatkoztatunk a hagyományos felhasználóktól, akkor valóban beszélhetünk SSO-ról, hiszen az egyéb ‘service accountok’ is az SSO szerverbe authentikálnak, és ennek segítségével érik el az összes egyéb vSphere alkalmazást..

Szóval összességében ez előrelépés, hiszen egy nagyon fontos dolgot – az auhtentikációt – egy külön szolgáltatásként oldották meg, levéve ezt a feladatot az amúgy is kaotikus alkalmazáshalmazról, amit eddig együttesen vCenter Servernek neveztek. Persze, a ‘vCenter Server’ mint olyan, továbbra is alkalmazások összességét jelenti, a különbség csak annyi, hogy az egyes feladatok jobban elkülöníthetőek egymástól mint eddig.

A gyakorlatban viszont még(?) egy csomó probléma van vele, ami nem is meglepő hiszen valami teljesen új dologról van szó, amit egyszer csak ‘upgrade’ néven belecsaptak a vCenter Server szolgáltatáskupacba. Éppen ezért, éles üzembe csak úgy érdemes állítani, ha minden használni kívánt esetet előtte kipróbáltál, vagy fel vagy készülve az esetleges üzem közbeni meglepetésekre!

vSphere Web Client

Ahhoz képest, hogy az 5.0-ban megjelent webes kliens nem lett az igazi, az 5.1-ben elkerülhetetlen a használata, mert sok új dolog – köztük az SSO szerver – CSAK ezen a felületeten keresztül konfigurálható.

vCenter-WbClient-01

Ehhez mérten sokat javult, már-már használható is lett, de azért kicsit túlzás hogy van amit csak ebből lehet megoldani. Amik hiányoznak és/vagy problémásak:

  • Flash

Úgy tűnik, nem vicceltek, totálisan komolyan gondolják hogy egy böngészőben futó flash izén keresztül kattintgassuk az egész cégünk – vagy sok esetben több cég TELJES virtuális környezetét. Mivel ezen változtatni nem nagyon tudunk, így bele kell törődni, hogy ez van.

Amit tehetünk, hogy kizárólag egy megbízható kliens gépről (ami semmi egyebet nem tud elérni) engedjük csak adminisztrálni a rendszert, és/vagy az adminisztrátorok kliens gépein igyekszünk csökkenteni az ebből adódó igen súlyos biztonsági problémákat: Qubes-OS.

  • Maps

Ez az egyébként igen hasznos fícsör úgy néz ki hiányzik a webes kliensről :(

  • VM konzol

Az eddig megszokott java-s cucc sem volt tökéletes, de már megszoktuk. A webes kliens esetében egy újabb (magát böngésző plugin-nek nevező) izére van szükségünk. Ám ennek a valaminek valójában semmi köze a böngészőhöz, ami egy csomó probléma forrása: nem küld tanúsítványt, nem oda kapcsolódik ahová a böngésző (emiatt NAT mögé tenni lehetetlen), rendszergazda jogokkal lehet csak telepíteni, és mind emellé még lassú is.

De legalább Linux-on is fut, tehát tulajdonképpen innentől nincs szükség többé windows operációs rendszerrel rendelkező adminisztrátor gépre!

  • Biztonság

Ugyan biztonság szempontjából eddig sem volt a csúcson, most hogy böngészőn keresztül érhető el, csak még tovább romlott a helyzet. Tehát, még mindig az a javasolt üzemeltetési megoldás, hogy a vCenter (és az ESX-ek) bármilyen felületét csak és kizárólag az arra feljogosítottak érhessék el…

vCenter-WbClient-02

A webes kliens teljes dokumentációja megtalálható a VMware hivatalos dokumentációi között.

Management felület

Már a 5.0 esetében is probléma volt vele, miszerint csak bizonyos verziószámú böngészőkből hajlandó működni. Ezt sajnálatos módon az 5.1-es verzióban sem javították, de cserébe született róla egy KB bejegyzés.

 

Összességében tehát rengeteg új és hasznos változtatás került az 5.1 verzióba, csak én ezt még nem merném stabil – és éles környezetben bátran használható –  kiadásnak nevezni.

Természetesen mivel mi már kitapasztaltuk az újdonságok miatt keletkezett legtöbb buktatót, így már meglévő – és leendő ügyfeleinknek ezen problémákkal már nem kell egyedül megküzdeniük.

EnterNE!t

Sajnálatos módon ismét egy fikázós posztot kell írnom. Ezúttal a problémák okozója az  EnterNet 2001 Kft.  remek szolgáltatásai, a készséges ügyfélszolgálata, és a mindezt vezénylő – ám sajnos elérhetetlen – vezetőség hozzáállása…

Valamikor nagyon régen regisztráltam néhány privát használatú domain-t (köztük a zrubi.hu is), és mindezt valahogy/valamiért az EnterNet Kft-nél tettem… Egészen mostanáig semmi probléma nem is volt ezzel. De milyen probléma lehetne egyáltalán??? Hiszen ez a „szolgáltatás” nem áll másból, mint hogy az ISZT-nek fizetendő éves domain fenntartási díjakat tovább kell számlázni az ügyfél felé. Tehát évente 1 (azaz egy) alkalommal készíteni kell egy darab számlát, és a fizetés esedékességéről értesíteni az ügyfelet.

Ez a feladat már eddig sem ment nagyon az EnterNet-nek, de mindeddig vagy saját kárukra bénáztak, vagy ez rám, mint ügyfélre nem volt különösebb hatással… Egyszer aztán kaptam egy számlát, amit nem is értem, hogyan jutott el hozzám, mert egy olyan címre küldték, ahol több mint 8 éve nem lakom… A számla tartalma is érdekes volt, ugyanis a viszonylag egyszerű, előre fizetendő 2000 HUF/domain/év helyett valami egészen más volt a számlán:

enternet-2012-crop

Ahogy a számlán megfigyelhető, 2012.07.20-a a kiállítás dátuma, és utólagosan a 2011.09.20. – 2012.09.19. időszakra vonatkozik. Fel is hívtam egyből az ügyfélszolgálatot, hogy meséljék el, mi is ez, és miért most jött. Az ügyfélszolgálatos kedvesen elmagyarázta, hogy az év közben bevezetett ÁFA változások miatt lett ilyen, és elismerte, hogy problémáik voltak a számlázással, ezért csak utólag tudták kiszámlázni az igénybe vett szolgáltatást – mindezért persze a megértésemet is kérte… Megemlítette azt is, hogy kaptam/kapok egy másikat is, a következő időszakra immáron helyesen előre számlázva. Ekkor kértem, hogy mivel ez is csak véletlenül – és pár hónap késéssel – jutott el hozzám, javítsuk már ki azt a számlázási/értesítési címet, és küldje el újra a meg nem kapott számlákat. A telefonban azt ígérte, hogy a címet javította, és a számlák másolatát újra kiküldi.

Ezzel a dolgot elintézettnek tekintettem, és simán betettem a csekket a kifizetendő tételek közé.

Időközben – a kiállítás dátuma alapján úgy 20 napos átfutással – megkaptam a következő számlát is:

enternet-2013-crop

Persze, nem rohantam ezekkel egyből a postára, hiszen ha ők ráérnek fél évvel később számlázni, attól emiatt nekem most egyben a két éves díjat nehogy már pár napon belül kelljen kifizetnem…

Mindezek után, 2012.11.24-én döbbenten tapasztalom, hogy az oldalaim nem elérhetőek :O

Gyors hibafelderítés után világossá vált, hogy az ns.nic.hu szerver szerint a kérdéses domain(ek) nem is léteznek! Felhívtam egyből az EnterNet ügyfélszolgálatát, ahol (hétvégéről lévén szó) az elvárásoknak megfelelően egy korlátozott beavatkozási jogokkal rendelkező egyed vette fel a telefont. Ő közölte, hogy számlatartozás miatt felfüggesztették a domain-jeimet.

Azok számára, akik ennek jelentőségével nincsenek tisztában: ha egy domain-t felfüggesztenek, az azt jelenti, hogy a .hu domainekért felelős DNS szerver nem fogja ezeket tartalmazni, ezek a külvilág számára úgy fognak tűnni, mintha nem is léteznének! Ennek a következményei a következők együttese lehet:

  • a weboldalaimat senki nem tudja elérni,
  • az erre a címre érkező összes levél permanens hibaüzenettel visszapattan a feladónak, mondván hogy nincs is ilyen domain. Ez az én domainjeim esetén esetén ez akár több 100 levelet is jelenthet naponta,
  • a fenti okok miatt az ÖSSZES levelezőlistáról ledobnak,
  • az általam küldött levelek miatt (mivel azok feladója immár ismeretlen domain) SPAM és egyéb feketelistákra kerülhet a domain.

Ez a szegény jómunkásember, az én teljes felháborodásom és értetlenségem ellenére semmit nem tudott tenni az ügyben, de még csak tovább sem tudta adni az ügyet az illetékeseknek, ők ugyanis hétvégén nem dolgoznak. Ez rendben is lenne, ha nem pénteken tették volna meg ezt  sajnálatos lépést, mert így az a lehetetlen helyzet állt elő, hogy tisztázni sem tudtam a nemfizetés okait, és vissza sem tudták csinálni, amit elszúrtak. Ennek következtében több napon keresztül fennállt volna a probléma, ami igen durva, tekintve hogy:

  • A számlázást első körben az EnterNet Kft rontotta el.
  • Miután ezt jeleztem feléjük, ismét hibáztak azzal, hogy ennek ellenére felfüggesztették a kérdéses domaineket.
  • A domainek ez én tulajdonomban vannak, az EnterNet csak és kizárólag adminisztrációs feladatot láthat el ez ügyben. A valós szolgáltatást ugyanis az ISZT végzi!
  • A domaineket bármiféle figyelmeztetés nélkül függesztették fel!
  • Ezzel ők semmit nem nyertek, hiszen az ISZT-nek már kifizették a nekem továbbszámlázott díjakat.
  • Nekem, mint ügyfélnek ezzel a húzással jelentős károkat okoztak.

Mivel az ügyfélszolgálat egyértelműen kijelentette, hogy (azon kívül, hogy felvette a panaszomat) SEMMIT nem tud tenni annak érdekében, hogy a domaineket visszaállítsák, én azonnal másik regisztrátor céget kerestem…

Ezúton is köszönet a Zuriel Kft.-nek, és az ISZT-nek, hogy belátva a probléma súlyosságát, hétvégén is pár óra alatt elintézte a domainjeim átregisztrálását, ezzel minimalizálva az EnterNet Kft. által okozott károkat.

Eljött a hétfő (2012.11.26) reggel, ismét EnterNet ügyfélszolgálat. Bediktálom az ügyfél azonosítót, elhangzik a nem várt kérdés:

– És mi a probléma?

Na itt vesztettem el végképp a türelmemet: hogy-hogy nem látja/tudja hogy mi a probléma?!? Ezek szerint a hétvégi ügyeletes NEM vette fel a panaszomat…  Neki is elmeséltem a történetet, ám ennek az egyednek is csak 1 bites gondolkodása volt, mert a mondókám után is csak azt kérdezte:

– Miért, már be lett fizetve a ‘tartozás’?

Miután főnököt, vagy egyéb hivatalos véleményre feljogosított kollégát ő sem tudott adni, így felvilágosítottam a tényről, hogy a problémás domainekhez innentől semmi közük, majd annyiban maradtunk, hogy várjuk a fejleményeket.

Itt akár már vége is lehetne a történetnek, de az EnterNet 2001 Kft. ezt még tovább tudta fokozni:

Immáron a helyes címemre kaptam egy levelet, amiben 2012.11.26 dátummal!!!  számlatartozásra hivatkozva felmondják a szerződésemet, és a hátralévő fiktív tartozásomról és annak behajtásáról hadoválnak – az ügyvezető aláírásával:

enternet-felmondas-crop

Na ez megint arra ösztönzött, hogy ismét beszélgessünk kicsit… Persze sok értelme nem volt, csak tovább görgették az eddigi hibáikat, és még jobban felidegesítettek a „leszarjuk az ügyfelet” hozzáállásukkal. Közben persze elismerték, hogy a levélben szereplő összeg is téves, mert a rendszerük szerint másnap (2012.11.27-i dátummal) stornózták a 2013-as díjakat.

Mivel ismét nem sikerült döntéshozásra jogosult vezetővel beszélnem, így maradt a panaszlevél, amiben vázoltam a fent leírtakat, és azokkal kapcsolatos panaszaimat. Természetesen erre válaszoltak, azonban panaszaimat érdemben figyelembe sem vették.

Innentől kezdve – mivel egyelőre sem időm, sem kedvem nincs ezzel tovább szarakodni – annyit tudok tenni, hogy az Enternet 2001 Kft. szolgáltatásait senkinek nem ajánlom!

Persze ha akad egy ügyvéd, aki kedvét (vagy akár hasznát) leli abban, hogy mindenzt a fogyasztóvédelem elé tárja, azzal szívesen közreműködök ezügyben :)

Lifebook S751 (vPro)

Munkáltatómnak köszönhetően, először csak tesztelés céljából,  majd a tesztek sikerén felbuzdulva végül munkaeszközként hozzájutottam egy remek laptophoz: Fujitsu Lifebook S751

A technikai paraméterei – némi marketingömlennyel megfűszerezve – megtalálhatóak a fenti linket követve, így én leginkább a munkám során való használhatóságáról igyekszem megosztani néhány hasznos információt:

Hardver

  • Burkolat

 A gép burkolata teljes egészében műanyag, de a jobbik fajtából, így már első fogásra is érezhetően masszív keretet ad a masinának. Fedőlapja erős és bordázott, ami  praktikus és egyben stílusos is :)

  • Kijelző

Kétféle 14″ matt kijelzővel kapható: a normál 1366 x 768 felbontású, illetve 1600 x 900. Mindkettőhöz volt szerencsém, a különbség közöttük eléggé jelentős, ami viszont az árán is megmutatkozik.

  • Billentyűzet

A billentyűzete igen kényelmes, és nincs túlzsúfolva numerikus kiegészítőkkel.

  • Egyéb perifériák

Jól elhelyezett csatlakozók, kivehető optikai meghajtó, aminek helyére 2. akkumulátor vagy  HDD/SSD meghajtó pakolható. A meleg levegőt – általában igen halkan – hátrafelé fújja.

  • Akkumulátor

Az eddigi tapasztalatok alapján bőven az elvárásokon felül teljesít, hogy meddig az persze csak később derül ki, amikorra valószínűleg már az elavult modellek közé kell hogy soroljuk.

Munkánk során alapvetően Linux-on futó rendszereket üzemeltetünk/fejlesztünk, így a munkaállomásokon és a laptopjainkon is Linux az elsődleges operációs rendszer, tehát alapvető, hogy minden szükséges eszköz megfelelően működjön Linux alatt.

Ubuntu 12.04

Mivel ez az egyik legelterjedtebb disztribúció, ami várhatóan támogatja a legújabb hardvereket is, így ezzel tettem egy első próbát:

A telepítő CD (valójában pendrive) gond nélkül bootolt, a telepítés gyorsan és zökkenőmentesen zajlott, miközben a gép alapvető eszközei egyből – bármiféle izélgetés nélkül – használhatóak voltak. Meg is lepődtem rendesen, amikor a telepítés végén a felhasználóhoz rendelhető szokásos avatarok mellett ott láttam magamat is: a beépített kamerával azonnal készíthettem volna képet magamról, hogy saját avatarom lehessen :)

Mivel nem a telepítés és az Ubuntu testreszabásának ismertetése a cél, így inkább lássuk mi van a dobozban, és azt hogyan látja az Ubuntu:

$ uname -a
Linux LIFEBOOK-S751 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 6 Series/C200 Series Chipset Family KT Controller (rev 04) (prog-if 02 [16550])
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) (prog-if 00 [Normal decode])
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b4) (prog-if 00 [Normal decode])
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) (prog-if 00 [Normal decode])
00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b4) (prog-if 00 [Normal decode])
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) (prog-if 01 [AHCI 1.0])
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
0a:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)
0b:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI])
0c:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5116 PCI Express Card Reader (rev 01)
0c:00.1 SD Host controller: Realtek Semiconductor Co., Ltd. RTS5116 PCI Express Card Reader (rev 01)

A PCI eszközökkel semmi gond nem akadt, mindegyikhez volt megfelelő driver a disztribúcióban. Bővebben lásd: dmidecode, lspci, lsusb, lsmod, dmesg és Xorg.log

$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 003: ID 08ff:2683 AuthenTec, Inc. 
Bus 002 Device 004: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
Bus 002 Device 006: ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader
Bus 002 Device 007: ID 0489:e031 Foxconn / Hon Hai 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 004: ID 04f2:b240 Chicony Electronics Co., Ltd

AZ USB-s eszközökkel már más a helyzet, a legtöbbre ugyan nem is lesz szükség, azokat majd a BIOS-ból fogom letiltani, itt most csak a teljesség kedvéért van engedélyezve minden vacak:

  • ID 08ff:2683 AuthenTec, Inc.

Ujjlenyomat olvasó: Vicces dolog, és semmiképp sem nevezhető komoly authentikációnak. Jelszó helyett használni igen nagy merészség (hiszen az egész laptop tele van az ujjlenyomatainkkal), kiegészítőnek lehet vele próbálkozni… Én biztosan nem használom, így nem tudom mennyire működőképes, és hogyan lehet integrálni a rendszerbe.

  • ID 0489:e031 Foxconn / Hon Hai

Bluetooth: Az alap telepítés után nem volt használható. Mivel én ki fogom kapcsolni, így nem is nagyon érdekelt, hogy használható-e egyáltalán Linux alatt.

  • ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader

Elvileg létezik hozzá driver, a gyakorlatban nincs semmilyen kártyám, amivel használni lehetne, így ez is kikapcsolásra kerül.

  • ID 04f2:b240 Chicony Electronics Co., Ltd

Kamera: Ahogy említettem már, Ubuntu alatt egyből használható. Hasznos lehet videó konferenciákra :)

 

$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 50:26:90:xx:xx:xx  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:17 Memory:e2700000-e2720000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:122 errors:0 dropped:0 overruns:0 frame:0
          TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:9990 (9.9 KB)  TX bytes:9990 (9.9 KB)

wlan0     Link encap:Ethernet  HWaddr 10:0b:a9:xx:xx:xx  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 MB)  TX bytes:0 (0.0 KB)

Ahogy látható, a legtöbb integrált cumó simán használható Linux alatt. A fenti információk alapján működésre bírhatóak a megfelelő driverekkel bármilyen egyéb disztribúció esetén is. Egyedül a külön kihelyezett gyorsbillentyűk nem működtek – ezekkel majd futok még pár kört.

Qubes OS 1.0

Ahogy az már ismert lehet olvasóim számára, a célom hogy Qubes OS alatt is használható gépet találjak. Ez a speciális operációs rendszer extra igényeket támaszt a hardverekkel kapcsolatban, hogy valóban hardveresen támogatott szeparációt tudjon biztosítani a felhasználóknak. Ez a gép tökéletes hardver a Qubes OS használatához is.

Az alapvető hardver eszközök használhatóságában annak ellenére sincs nagy különbség, hogy ez esetben fedora 17-re épülő rendszerekről beszélünk. Így ezeket nem is igazán részletezném, jöjjön inkább a Qubes specifikus rész.

Mivel Qubes alatt a PCI eszközöket a VM-hez rendelhetjük, így fontos, hogy melyik eszközök függenek egymástól. Az alapvető hálózati interfészek esetében nincs is különösebb probléma, könnyedén megvalósítható, hogy pl: külön Ethernet, és külön WiFi netVM-eket hozzuk létre.

Az izgalmas rész az USB eszközöknél kezdődik, hiszen itt egy-egy USB HUB az, amit egy adott VM-hez tudunk rendelni, így nagyon nem mindegy, hogy melyik eszköz melyik HUB-ra csatlakozik:

00:1a.0    Bus 001
    ID 04f2:b240 Chicony Electronics Co., Ltd

00:1d.0    Bus 002
    ID 0489:e031 Foxconn / Hon Hai 
    ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader
    ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
    ID 08ff:2683 AuthenTec, Inc.

0b:00.0    Bus 003

Ebből látszik, hogy ha pl. a kamerát szeretném odaadni valamelyik VM-nek, akkor pontosan melyik PCI eszközt kell az adott VM-hez rendelnünk. Rögtön kiderül ezen működési elv limitációja is: ha pl. a Bluetooth és a SmartCard readert akarnám különbözö VM-ek számára odaadni, akkor azokat egyszerre nem fogom tudni használni…

Erre jön még egy érdekes dolog, a külső USB csatlakozók. Ugyanis ezek is valamelyik HUB-on lógnak, így a HUB-bal együtt ezek is az adott VM alá kerülnek – ami nem feltétlenül cél. Hogy ezzel tisztában legyünk végigpróbálgattam, hogy melyik kivezetés melyik HUB-ra csatlakozik:

Bal oldali csatlakozók:

  • eSATA: Bus 001
  • USB:    Bus 003

Jobb oldali csatlakozók:

  • USB:    Bus 001
  • USB:    Bus 001

Így viszont máris sokkal macerásabb a helyzet, de azért elfogadható kompromisszumok árán pl.: oda lehet adni egyetlen USB külső csatlakozót mondjuk egy mobilnet VM számára, így azt is külön tudjuk kezelni. Ehhez a fenti információk alapján a 003-as USB HUB-ot kell PCI szinten az adott VM-hez rendelni.

Firefox, fészbúk és a sütik

Amióta aktívan használom a facebook-ot, folyamatos de nem konzekvensen jelentkező problémákkal találtam szembe magam az oldal elérésével kapcsolatban:

  • nem töltődött be a teljes TimeLine a főoldalon,
  • a legördülő menük nem mindenhol jelentek meg,
  • a képek nézegetésekor nem ugrott fel az ajax-os képnézegető,
  • a chat ablakok és az üzenetek nem minden esetben jelentek meg,
  • nem tudtam ‘lájkolni’ sem az egyéb oldalakat..

Mivel igyekszem magamat (és a böngészőmet, ami jelenleg: Firefox 14.0.1 ) távoltartani a manapság már szinte minden egyes oldal látogatásakor az arcomba nyomuló reklámhalomtól, a kéretlen sütiktől, és a gonosz célokra használt script izéktől egyaránt, ezért szigorú beállításokat, Adblock Plus és NoScript kiegészítőket is használok a mindennapi böngészés során is. Éppen ezért, eleinte ezek együttes hatásának tudtam be a problémákat, de nem volt időm hogy a végére járjak mi is a probléma valójában – Egészen mostanáig:

Mivel Qubes OS van a gépemen ezért viszonylag könnyen és gyorsan sikerült ezt megoldani, úgy hogy teljesen szűz, alapbeállításokkal rendelkező – de ugyan azon verziójú – böngészővel próbálkozhattam, amivel természetesen a fenti problémák nélkül tudtam használni az oldalt.

Aztán persze elszórakoztam vele egy darabig: Adblock kikapcsolás, NoScript kikapcsolás, böngésző beállítások kapcsolgatása – és ezek permutációjával.. mire aztán rájöttem hogy bizonyos sütik el nem fogadása okozza a problémákat:

A fenti kép az egyéb oldalak látogatása esetén probléma nélkül használt beállításaimat mutatja, amiből a lényeg, hogy a „third-party” sütiket nem fogadom szívesen…

Mindemellett ott van az „ask me every time” beállítás is, ami azt eredményezi, hogy minden egyes süti esetén egy felugróablaknak jelenik meg, amiben dönthetek a gépemen elhelyezni kívánt süti sorsáról…

A facebook esetében az az érdekes helyzet áll fent, hogy hiába engedélyezem a „third party” sütiket, az oldal első látogatásakor a www.facebook.com-ról kapok néhány sütit, de a helyzet nem változik: a fent említett problémák ugyan úgy fennállnak, és  látszólag nem is akar máshonnan sütit adni az oldal…

De csak látszólag, ugyanis ha kézzel hozzáadom a ‘www.facebook.com’ URL mellett a ‘facebook.com’ URL-t is a sütik elhelyezését engedélyező listára, akkor egycsapásra megjavul az összes eddig felmerült probléma!

Ha megnézzük pontosan miket kaptunk, akkor is látszik hogy valójában minden süti a facebook.com-ról jön:

Hogy ez a böngésző hibája vagy a facebook küldi rosszul a sütiket? – ezt sajnos egyelőre nem tudom.

Mivel a tapasztalt problémákkal várhatóan csak azon paranoid egyedek találkoznak, akik hozzám hasonlóan eléggé szigorúra állított böngészővel próbálnak netezni, így ez várhatóan nem globális probléma, de ha mégis: a fentiek alkalmazásával gyorsan kiküszöbölhető.

Qubes – 1.0

Kiadásra került a Qubes OS 1.0 RC1 verziója. A Telepítő DVD, és a használatához szükséges információk megtalálhatóak a projekt wiki oldalán.

Ez a verzió a Beta3 kiadáshoz képest rengeteg újdonságot tartalmaz:

  • Továbbfejlesztett Qubes VM Manager, aminek segítségével szinte minden (virtuális gépeket érintő) beállítást elvégezhetünk egy könnyen és egyszerűen használható grafikus felületről.
  • Az összes VM egy frissített, Fedora 17 template-en alapul.
  • Továbbfejlesztett és egységesített Dom0 és VM kezelő CLI parancsok.
  • Frissült a Dom0 és a VM-ek kernele is, ami immár a 3.2.7-pvops verzión alapul. Ennek köszönhetően javult a különböző hardver elemek, és az energiatakarékos üzemmódok támogatása.
  • Praktikus újítás, hogy a menüből egyszerűen indíthatunk eldobható (Disposable) VM-eket.
  • Opcionálisan engedélyezhető lett az egyes VM-ek számára a fullscreen üzemmód.
  • Ezeken kívül rengeteg hibát is javítottak az új verzióban…

Mindezen újítások közül a legszembetűnőbb, és talán az egyik legpraktikusabb az új:

VM Manager

Ezen a felületen szinte minden VM műveletet elvégezhetünk:

vm-manager-01

Az általa megjelenített VM tulajdonságokat is a saját igényeinkhez igazíthatjuk:

vm-manager_view

Az összes VM-re vonatkozó globális beállítások:

vm-manager_globalsettings

Egy adott VM-re vonatkozó alapbeállítások:

vm-manager_vm-settings-basic

Egy adott VM-re vonatkozó extra beállítások és információk:

vm-manager_vm-settings-advanced

Ha az adott AppVM egy ProxyVM-en keresztül csatlakozik a fizikai hálózatba, akkor lehetőségünk van tűzfalszabályok definiálására is:

vm-manager_vm-settings-firewall

Egy VM-hez könnyedén hozzárendelhetünk PCI eszközöket is:

vm-manager_vm-settings-devices

Beállíthatjuk, hogy az adott VM-en belül milyen alkalmazások jelenjenek meg a menüben:

vm-manager_vm-settings-apps

Akár szolgáltatásokat is indíthatunk, amik a VM indításakor automatikusan elindulnak majd:

vm-manager_vm-settings-services

Az adott virtuális géphez kapcsolódó beállításokat egy külön menüből is elérhetjük:

vm-manager_vm-settings-vm

Ezek közül igen hasznos a virtuális géphez tartozó naplóállományok megtekintésének lehetősége:

vm-manager_vm-settings-vm-logs

A tervek szerint ez a verzió már a végleges 1.0 lesz – persze a tesztelések során esetlegesen előkerülő hibák javítása után…

A hivatalos bejelentés a fejlesztők blogján olvasható.

VMware OSPs

VMware Operating System Specific Packages

Kevesen tudják, hogy a VMware létrehozott egy repository-t a különböző operációs rendszerekhez előre csomagolt hivatalos VMware Tools csomagok számára. Ez a megoldás alternatív telepítési lehetőséget nyújt, az eddig használt vSphere Client-ből kezdeményezett telepítés mellett.

Miért is jó ez nekünk?

  • Szabványos telepítést tesz lehetővé

Tehát, nem kell többé forrásból, vagy – az operációs rendszerünk csomagkezelőjébe nem illő – bináris telepítőkészlettel bajlódni, használhatjuk az operációs rendszer által biztosított szabványos csomagkezelőt a vmware-tools csomagok telepítésére is.

  • Kezelhetőbb

Azaz, a vmware-tools csomagok telepítése ezesetben pont olyan egyszerűvé válik, mint egy normál szoftvercsomag telepítése. Mindemellett, a csomagok közül lehetőség van csak a számunkra szükségeseket feltelepíteni, és ezekből is kiválaszthatjuk a számunkra legmegfelelőbb verziót.

  • ESX-től függetlenül frissítheő

Vagyis, az adott VMware környezettől függetlenül frissíthető, azaz a vmwate-tools csomagok telepítése nem függ többé az ESXi verzióktól. Ezt a megoldást használva, az adott operációs rendszer csomagkezelőjére bízhatjuk a frissítéseket – ahogyan a többi egyszerű szoftvercsomag esetében is tesszük.

  • Támogatott

 A VMware hivatalos támogatást nyújt hozzá, ami produktív környezetben fontos követelmény lehet…

Támogatott operációs rendszerek

  • Community ENTerprise Operating System (CentOS)
    • 4.0 vagy újabb
  • Red Hat Enterprise Linux
    • 3.0 vagy újabb
  • SUSE Linux Enterprise Server
    • 9 vagy újabb
  • SUSE Linux Enterprise Desktop
    • 10 vagy újabb
  • Ubuntu Linux
    • 8.04 vagy újabb

Telepítés

RedHat, CentOS

  • Aláíró kulcs telepítése

Ahhoz hogy a csomagkezelőnk ellenőrizni tudja a csomagok hitelességét először is telepíteni kell a VMware aláíró kulcsát:

rpm --import http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub
  • Repository felvétele

Ezek után, fel kell vennünk magát a repository-t, amihez hozzunk létre  /etc/yum.repos.d/vmware-tools.repo néven egy állományt, a következő tartalommal:

[vmware-tools]
name=VMware Tools
baseurl=http://packages.vmware.com/tools/esx/<esx-version>/<dist>/<arch>
enabled=1
gpgcheck=1

Amiben a következő mezőket kell értelem szerűen lecserélni:

  • vmware-tools csomag telepítése

A fentiek elvégzése után, a szokott módon telepíthetjük is a vmware-tool csomagokat:

yum install vmware-tools

...

Dependencies Resolved

=============================================================================================================================================
 Package                                            Arch                Version                              Repository                 Size
=============================================================================================================================================
Installing:
 vmware-tools                                       x86_64              8.3.12-559003.el6                    vmware-tools              2.7 k
Installing for dependencies:
 vmware-open-vm-tools                               x86_64              8.3.12-559003.el6                    vmware-tools              2.8 k
 vmware-open-vm-tools-common                        x86_64              8.3.12-559003.el6                    vmware-tools              5.0 M
 vmware-open-vm-tools-kmod                          x86_64              8.3.12-559003.el6                    vmware-tools               93 k
 vmware-open-vm-tools-nox                           x86_64              8.3.12-559003.el6                    vmware-tools              2.6 k
 vmware-open-vm-tools-xorg-drv-display              x86_64              11.0.1.0-0.559003.el6                vmware-tools               33 k
 vmware-open-vm-tools-xorg-drv-mouse                x86_64              12.6.7.0-0.559003.el6                vmware-tools               18 k
 vmware-open-vm-tools-xorg-utilities                x86_64              8.3.12-559003.el6                    vmware-tools              7.5 M
 vmware-tools-common                                x86_64              8.3.12-559003.el6                    vmware-tools               39 k
 vmware-tools-nox                                   x86_64              8.3.12-559003.el6                    vmware-tools              2.6 k

Transaction Summary
=============================================================================================================================================
Install      10 Package(s)
Upgrade       0 Package(s)

Ubuntu

  •  Aláíró kulcs telepítése

Ahhoz hogy a csomagkezelőnk ellenőrizni tudja a csomagok hitelességét először is telepíteni kell a VMware aláíró kulcsát:

wget http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub
apt-key add VMWARE-PACKAGING-GPG-KEY.pub
  • Repository felvétele

Ezek után, fel kell vennünk magát a repository-t, amihez hozzunk létre  /etc/apt/sources.list.d/vmware-tools.list néven egy állományt, a következő tartalommal:

deb http://packages.vmware.com/tools/esx/<esx-version>/ubuntu <dist> main restricted

Amiben a következő mezőket kell értelem szerűen lecserélni:

  • vmware-tools csomag telepítése

A fentiek elvégzése után, a szokott módon telepíthetjük is a vmware-tool csomagokat:

apt-get install vmware-open-vm-tools-kmod-`uname -r |cut -d - -f3`
apt-get instal vmware-tools

Qubes – Beta3

Egy korábbi cikkben írtam arról az elvetemült igényemről, hogy egy biztonságos desktop operációs rendszert szeretnék használni, ahol nem keverednek a céges adataim/alkalmazásaim a priváttal, és legfőképp nem a szórakozásra használtakkal…

Úgy tűnik, az egyetlen projekt, ami pontosan ezt tűzte ki célul: a Qubes OS.

A projekt fejlődését régóta nyomon követem, tartottam is már erről egy rövid előadást az az egyik Budapest New Tech Meetup rendezvény keretében, íme az akkori előadásom anyaga, amiből egy gyors, de átfogó képet kaphatunk az alap problémáról, és annak lehetséges megoldásairól.

Most, hogy a projekt az utolsó tesztelési fázisában tart, nézzük milyen lehetőségeket biztosít mindez számunkra a gyakorlatban…

A megoldás

Ahogy a bevezető cikkből, és a rövid előadásomból is kiderülhetett az egyetlen – a gyakorlatban is működő – megoldás: a szeparáció.

A szeparáció alapját ezen projekt esetében is a Xen hypervisor jelenti, ami egy Type1 típusú – azaz közvetlenül a hardveren futó – virtualizációs megoldást biztosít számunkra.

Szemben a Citrix hasonló megoldásával, itt valóban a biztonság a legfontosabb szempont, amihez alapvető elvárás, hogy a Dom0-ban egyáltalán ne legyen hálózatkezelés. Ez ugyanis a rendszer ‘lelke’ – azaz aki ehhez hozzáfér, az teljes jogokkal rendelkezhet az operációs rendszerünk felett, a rajta lévő összes virtuális géppel együtt!

Használatba vétel

Az elmélet szép és jó, át mit sem ér mindez, ha csak beszélünk róla ;) Vegyük hát használatba, és nézzük mit is kapunk valójában:

Tervezés

Igen, ez fontos!

Létezik ugyanis ‘nex-next-finish’ jellegű telepítés is, de így az egésznek semmi értelme nem lesz. Ez ugyanis nem egy windows, hogy sikeresen feltelepítjük, aztán nézzünk körül mi hol van, és irány a fészbúk…

De mégis mit is kellene tervezni??

Ha erre a kérdésre még nem tudod a választ, akkor biztosan nem olvastad el a bevezető cikket, és a  Qubes-ról szóló rövid előadás anyagomat ;)

Tehát, azt szeretnénk, hogy a különböző biztonsági szinten lévő alkalmazásainkat külön-külön, egymástól független környezetben futtathassuk. Persze ne essünk túlzásba – mert a jelenlegi hardverünk azt biztosan nem fogja tolerálni. Jelenleg túlzás (azon felül, hogy egyelőre technikailag sem megoldható) az az igény, hogy minden alkalmazás külön VM-ben fusson… Az pedig kevés, amit egy jelenlegi átlagos operációs rendszer biztosíthat számunkra…

Akkor hol is az arany középút??

Hát, valahol a kettő között ;)

App VM-ek

Ezek az általunk valójában használt virtuális gépek, és ezekben fognak futni a böngészőink, a levelező klienseink, a szövegszerkesztő, és bármi egyéb alkalmazás amit csak használni szeretnénk…

Tehát, ezekből annyi kell, ahány féle dologra használjuk őket. A lényeg a biztonság, tehát  a céges oldalainkhoz a böngészőben ‘megjegyzett’ jelszavaink semmiképp se kerüljenek ki egyéb (nem céges) oldalakra. Így biztosan kell egy céges VM…

A privát adataink (gmail, facebook, blogok, fórumok) már nem olyan kritikusak (vagyis inkább más okból kritikusak) de ezeket sem szeretnénk az átlagos – egyszer látogatott – ismeretlen oldalak számára hozzáférhetővé tenni. Ezért praktikus egy privát célra fenntartott VM-is…

Egyéb, kevésbé fontos weboldalakat lehet hogy egészen más böngésző, (levelező vagy akármi) beállításokkal szeretnénk használni… ezek számára szintén praktikus egy külön VM…

Vannak ezen kívül a teljesen ‘megbízhatatlan’ oldalak – nem is hoznék példákat, biztosan mindenki látott már ilyen-olyan jellegű oldalt, amiről nem tudta (vagy nem is érdekelte) hogy ki üzemelteti ;) De ha ilyet nem is, gyanús levél csatolmányokat biztosan mindenki látott már… Az ilyen ügyeket egy speciális, eldobható (azaz egyszer használatos) úgynevezett ‘Disposable’ VM-ben végezzük…

Ezzel szöges ellentétben, lehet olyan igényünk is, hogy az adott VM semmilyen hálózati eléréssel ne rendelkezzen. Ilyen elszeparált helyen biztonságosan tárolhatjuk jelszavainkat, titkos kulcsainkat, stb…

Service VM-ek

Net VM (ek)

Egyre mindenképp szükségünk lesz, enélkül ugyanis nem fogunk tudni hálózatra csatlakozni.

Egyetlen NetVM használata esetén, az összes hálózati csatolót (ethernet, WiFi, 3G) PCI szinten ehhez a VM-hez rendeljük, és az AppVM-ek ezen keresztül jutnak hálózati eléréshez…

Több NetVM használata akkor indokolt, ha külön szeretnénk választani a különböző hálózati interface-eket – és így akár egyik AppVM etherneten, míg a másik WiFin-keresztül kommunikálhat a külvilággal, anélkül hogy a hálózati adataik bármilyen közös ponton áthaladnának!

Proxy (firewall) VM (ek)

A NetVM-(ek), és az AppVM-ek közé ékelődő, speciális (a NetVM számára AppVM, az AppVM számára pedig NetVM) hálózati tulajdonságokkal megáldott VM-ek, amik biztonságos, és könnyen áttekinthető tűzfal/proxy megoldást nyújthatnak alkalmazásainknak.

A gyakorlatban leginkább VPN kapcsolatok, és/vagy TOR proxy használata esetén van jelentőségük.

Mindebből jól látszik, hogy leginkább tőlünk (és a rendelkezésünkre álló hardver teljesítményétől) függ, hogy miből mennyit hozunk létre, és ezeket pontosan mire használjuk. Így nem lehet látatlanban, mindenki számára megfelelő megoldásokat előre kitalálni…

Hogy mindez érthetőbb legyen, íme a ‘default’ hálózati struktúra:

És íme, egy bonyolultabb (több NetVM-es felállás), amiben még olyan VM is szerepel, aminek egyáltalán nincs internet elérése:

A fenti topológia nem csak példa, nagyjából ez lett megvalósítva a saját laptopomon is…

Telepítés

Maga a telepítés nem egy agyműtét, bárki – aki telepített már valaha valamilyen operációs rendszert – könnyedén elboldogul vele. Aki esetleg közelebbi ismeretségben van a redhat, fedora – vagy ezek leszármazottjaival – annak pedig kifejezetten ismerős lesz az Anaconda telepítő felület.

A sikeres telepítéshez a legfontosabb információkat a projekt wiki oldalán találjuk.

Az izgalmas rész az első boot után következik, ekkor hozhatjuk létre ugyanis a rendszerünk alapvető építőkockáit – a virtuális gépeket. Ezzel kapcsolatban 3 lehetőségünk van:

  • default Service és AppVM-ek létrehozása

Ilyenkor a telepítő elkészíti a (szerinte) szükséges összes virtuális gépet, beleértve a majdan használni kívánt AppVM-eket is – amikben az általunk használni kívánt alkalmazások fognak majd futni. Ez az opció azoknak való, akik szeretnének egyből egy használható rendszert a kezükbe kapni. Azonban én ezt maximum kiindulási alapnak ajánlom, ugyanis biztosan nem a saját igényeinket fogja tükrözni… így pedig valós felhasználásra nem lesz alkalmas a kapott rendszer.

  • csak a Service VM-ek létrehozása

Köztes megoldás, AppVM-eket nem hoz létre, csak a (szerinte) lényeges Service VM-eket. Ezek ugyan sok helyzetben megfelelőek lehetnek, azonban ez sem azt fogja tükrözni amit valóban szeretnénk…

  • semmilyen egyéb VM-et nem kérünk.

Ilyenkor semmi egyéb VM-et nem hoz létre, megkapjuk az üres dom0-át. Ez kell nekünk, hiszen innentől úgy alakítjuk a rendszert, ahogy az nekünk valóban megfelel majd a gyakorlatban is…

VM-ek létrehozása

Ha az előzetes terveinknek megfelelően, saját magunk szeretnénk minden VM-et létrehozni, akkor ezt  (parancssorból) a következőképp tehetjük meg:

[dom0]$ qvm-create Ethernet --net --label orange
[dom0]$ qvm-create Wifi --net --label purple

Majd, hozzáadjuk  a kívánt PCI eszközöket a megfelelő NetVM-hez:

Ezt a qvm-pci paranccsal tehetjük meg, pl:

[dom0]$ qvm-pci -a WiFi `lspci |grep -i Wireless |cut -d ' ' -f1`
[dom0]$ qvm-pci -a Ethernet `lspci |grep -i Ether |cut -d ' ' -f1`

Ezek után, létre kell hoznunk a proxy VM-eket is:

[dom0]$ qvm-create Andrews-VPN --proxy --label gray
[dom0]$ qvm-create Firewall --proxy --label gray
Majd, csatlakoztatni őket a megfelelő NetVM-hez:
[dom0]$ qvm-prefs -s Andrews-VPN netvm Ethernet
[dom0]$ qvm-prefs -s Firewall netvm WiFi

Végül beállítjuk, hogy melyik AppVM melyik proxy VM-hez csatlakozzon :

[dom0]$ qvm-prefs -s Banking netvm Firewall
[dom0]$ qvm-prefs -s Andrews netvm Andrews-VPN
[dom0]$ qvm-prefs -s Vault netvm none
...
Természetesen, a hálózati összerendeléseket később bármikor – akár menet közben is – megváltoztathatjuk, ezzel könnyedén elérve hogy az aktuális helyi adottságokhoz igazítsuk a hálózati kapcsolatainkat…

Finomhangolás

Természetesen, akár melyik telepítési módot is választjuk, szinte minden esetben utólag is módosíthatjuk a VM-ek paramétereit, és egymással való kapcsolatukat. Erre a már használt qvm-prefs parancs használatos… De minderről bővebben később…

Alkalmazások telepítése

Az eddigiekből láthattuk, hogy egy-egy VM létrehozása, és használatba vétele igen egyszerű és gyors. Mindez azért lehetséges, mert a VM-ek egy közös template-re épülnek.

A projekt jelenlegi fázisában egyetlen ilyen template létezik, ami pedig egy Fedora 15 alapú linux operációs rendszer. Ebből az következik, hogy ha valamilyen új alkalmazást szeretnénk telepíteni (vagy a meglévőket frissíteni) azt csak a használt template-ben kell megtenni, és utána az összes VM-ben rendelkezésünkre áll…

Használat

Ha mindezzel megvagyunk, máris használhatjuk a rendszert… Ehhez persze azt minden esetben el kell döntenünk, hogy milyen alkalmazást, melyik VM-ben szeretnénk elindítani. Ebben nagy segítség a speciálisan erre a feladatra módosított KDE menü:

Miután elindítottunk egy-egy alkalmazást, az a VM-re jellemző színű keretben fog megjelenni, ezzel reprezentálva, hogy éppen mi melyik VM-ben fut:

Így könnyen megkülönböztethetjük a céges böngészőt a privát célra használttól, vagy az ideiglenesen megnyitott ismeretlen oldat tartalmazóktól…

További dokumentációk, és felhasználási esetek a projekt wiki oldalán…

A témáról hamarosan egy ingyenes előadást is tartok, ahol élőben fogom bemutatni a rendszer működését. Eerre jelentkezni itt lehet.

Összegzés

A fentiekből láthatjuk, hogy a Qubes egy olyan, eddig elképzelhetetlen biztonsági megoldást nyújt számunkra, aminek segítségével remekül elkülöníthetjük egymástól alkalmazásainkat – és a bennük tárolt érzékeny adatainkat…

Természetesen, az is látszik, hogy ez esetben is nagyon sok múlik a felhasználótól. Neki kell ugyanis eldönteni, hogy milyen oldalt melyik VM-ben nyitja meg, vagy épp melyik VM-et milyen hálózatba csatlakoztatja… Tehát, a Qubes ‘csak’ egy eszköz ahhoz, hogy végül egy biztonságos desktop gépen dolgozhassunk, tesztelhessünk vagy épp szórakozhassunk.

A projekt jövőbeli tervei között elsőkét szerepel további operációs rendszer (többek között windows!) alapú AppVM-ek támogatása is, ami még szélesebb felhasználói körnek biztosít majd egy rendkívül jó, és biztonságos, virtualizált desktop környezetet…

Az eredeti, sokkal bővebb cikk itt olvasható.

 

Az exponálástól a kiállításig

Azaz, egy digitális fotó életútja az exponáló gomb lenyomásától a kiállításig.

Manapság már bárki készíthet digitális képeket, szinte bármilyen eszközzel – okostelefonnal, webkamerával, kompakt géppel, vagy akár egy komoly DSLR géppel. Az eszköz jelen esetben szinte lényegtelen, a végcél minden esetben az, hogy megmutassuk a célközösségnek. Ezt elérhetjük azzal, hogy kitesszük a fészbúkra, vagy saját weboldalunkon megtekinthető galériánkba, de akár kiállítás is rendezünk belőlük valamelyik plázában ;)

A kép, születésétől kezdve, minden esetben  sok-sok folyamaton megy keresztül a végleges fotó bemutatásáig – sőt még utána is! A különbség a következőkben rejlik:

  • bele akarunk-e egyáltalán szólni ezekbe a folyamatokba?
  • van-e rá egyáltalán lehetőségünk?
  • hogyan és hol avatkozhatunk bele?
  • érdekel-e minket a képünk sorsa a bemutatás után?

Optikai képalkotás

Ez a fotókészítés első, és egyben legfontosabb lépése, ilyenkor a szemünk – és a fényképező eszközünk – elé táruló látvány bekerül egy ‘dobozba’, ahol majd valamilyen módon rögzítésre kerül maga a fénykép.  Hogy ez pontosan hogyan történik, az külön téma,  és  szerte az interneten is rengeteg cikk található a témában:

A fényképezés alapjai

Ezen cikk megértéséhez ez nem feltétlenül szükséges, ám ha nem csak kattintgatni szeretnénk, akkor mindenképp hasznos előtanulmány…

Digitális képalkotás

Miután a fény bejutott a ‘dobozunkba’, azt valahogyan tárolni is kell, manapság legtöbb esetben ez egy digitális érzékelő, majd egy memóriakártya segítségével történik. Ezek fajtái és működésük is érdekes téma, de ezen cikk szempontjából most nem annyira lényeges :)

Képformátumok

  • RAW

Az érzékelőre jutó fényből egy digitális adathalmaz keletkezik, amit RAW (nyers) formátumnak nevezünk. Minden digitális képalkotásra alkalmas készülék ilyen, a gyártója által kitalált, ám legkevésbé sem szabványos formátumban (.NEF,.CRW, .DCR, stb) készíti el a felvételt. Emiatt, az ilyen nyers formátumokat csak az arra felkészített szoftverekkel lehet megnyitni/megnézni/szerkeszteni. Mindemellett, az ilyen formátumban tárolt képek igen nagy helyet foglalnak el.  Éppen ezért, a legtöbb digitális fényképező ebből a nyers formátumból egyből egy szabványos, ám veszteséges tömörítést használó formátumba tudja alakítani, ami általában a .jpg. Ezzel az azonnali konverzióval viszont rengeteg olyan módosítási lehetőséget veszítünk, amiket a nyers formátum használata esetén minőségromlás nélkül megtehetnénk. Ez a formátum tulajdonképpen a ‘digitális negatív’ szerepét tölti be, tehát ebből még ‘elő kell hívni’ a végleges fotót. A komolyabb fényképezőgépek képesek ilyen formában (is) elmenteni a készített képeket, amiknek az előhívásához viszont speciális szoftverekre lesz szükségünk.

  • bitmap (.bmp)

A bitmap (.bmp) egy szabványos, tömörítetlen képformátum, amiben (többek között) minden képpont és annak színinformációja is tárolva van, így a keletkezett fájl mérete egyenesen arányos a képpontok számával. Ha ilyen formátumban tárolnánk egy 6 Mpixeles (3000×2000) képet, akkor az ~18Mb-ot foglalna el. Emiatt, ezt a formátumot ma már szinte sehol nem használják közvetlenül.

  • jpeg (.jpg)

A jpeg egy szabványos, de veszteséges tömörítést alkalmazó képformátum. Ez azt jelenti, hogy a kép megjelenítéséhez nem szükséges információkat egyszerűen eldobja, így természetesen sokkal (10 ~ 100x) kisebb állományokat eredményezhet. Az eldobott információkat később azonban már nem tudjuk pótolni, így ebben a formátumban csak a kész végeredmény érdemes tárolni, min már további módosításokat nem szeretnénk végezni.

A jpeg formátummal kapcsolatos további mítoszok és tények

A Digitális sötétszoba

Ez az a “hely” ahol a legtöbb módosítást végezhetjük a nyers formátumú képen, úgy hogy ezzel a legkisebb mértékű minőségromlást okozzuk. A fontosabb paraméterek, amiket ilyenkor ‘büntetlenül’ módosíthatunk:

  • Levels
  • White balance
  • Exposure
  • Contrast
  • Saturation
  • Color Space

Ha mindezt (és még rengeteg egyebet) mi magunk szeretnénk – akár képenként egyesével – beállítgatani, akkor egy erre alkalmas szoftverre lesz szükségünk. Ezek jelentőségének megértéséhez sokkal mélyebben el kellene merülni a digitális fotókidolgozás világába, de nem is kell mindenkinek ehhez érteni, hiszen a fényképezőgép gyártók ezen beállításokat elvégzik helyettünk, amikor a gép egyből .jpg formátumba menti le a képeinket. Az már gyártótól és géptípustól függ, hogy ezeket milyen mértékben tudjuk módosítani. Ilyenkor tehát, a módosításokat végző szoftver a fényképezőgépbe van beleépítve. Ebből viszont világosan következik, hogy ezek a beállítások az összes képre vonatkozni fognak amit az adott géppel .jpg formátumba készítünk.

A kép tulajdonságainak módosítása után, egy kritikus művelet következik, ami pedig a kép jpeg (vagy egyéb szabványos) formátumba való konvertálása. Kritikus, mivel általában .jpg lesz a végeredmény, ami pedig veszteséges tömörítési algoritmust használ. Tehát, nem mindegy hogyan végzi az adott szoftver ezt a konverziót! Igen, minden szoftver máshogy, más-más beállítási lehetőségekkel, és ennek megfelelően más más fájlmérettel és minőséggel fogja létrehozni a végleges képet ugyan abból a nyers képből! Márpedig, ha a neten tesszük közzé képeinket, akkor a közönség csak a végeredményben feltöltött jpeg képet fogja látni! Több – fotósoknak szánt – képfeltöltögetős/véleményezős oldalon is tapasztaltam már, hogy a képméret limitek miatt a fotósok a rossz minőséget a kicsi megengedett feltöltési méretre fogják, pedig ez csak rajtuk és az általuk használt szoftveren múlik.

Ebben a cikkben nem célom konkrét szoftverek bemutatása, de egy megfelelően részletes leírást mégis linkelek a jpeg konverzió beállítási lehetőségeiről.

Szintén nagyon fontos, hogy csak megfelelően kalibrált monitoron végezzünk ilyen szintű módosításokat, ellenkező esetben a közönség nem ugyan azt fogja látni, ami mi szerettünk volna mutatni. Természetesen, a gyakorlatban sajnos minden igyekezetünk ellenére is mindenki a saját monitora által mutatott képet jeleníti meg, ami a kijelző minőségétől, típusától és kalibráltságától erősen függ. Éppen ezért, a monitor kalibráció a képeket nézegető közönség számára is alapvető.

Digitális képek tárolása és rendszerezése

Sokan az összes fotójukat a digitális fényképezőgépük memóriakártyáján tárolják – hiszen manapság simán elfér rajtuk több ezer kép is, minek lementeni… Egészen addig nem is aggódnak, amíg az adott kártya a birtokunkban van, üzemképes, és még van rajta hely… Amikor ezek egyike már nem áll fenn, és ez – lehet hogy  évek múlva – de biztosan eljön egyszer…. Így a vele járó kisebb-nagyobb  problémák is…

Hogy ezeket megelőzzük, jó előre kitalált, kipróbált, és működő képkezelési  rendszert KELL alkalmaznunk. Ami így elsőre túllövésnek hangzik, de biztosan nem az! Még akkor sem, ha csak a családi fotóinkról van szó! Ha nem így teszünk, egészen biztosan rengeteg összevissza elnevezett, ki tudja melyik kártyán, CD-n, vagy laptopon megtalálható képhalmazunk lesz. Ebből az összevisszaságból aztán ha meg szeretnénk mutatni egyet-egyet valakinek, biztosan órákba telik hogy megtaláljuk – ha megvan még egyáltalán valahol….

Állománynevek, és EXIF adatok

A fényképezőgépben keletkező képeink már egyből rendelkeznek egy névvel, aminek összetételét géptípustól függően ugyan – de általában nem tudunk hatékonyan befolyásolni. Ezzel addig nincs is baj, amíg a kártyán vannak, mert a gépek általában gondoskodnak arról hogy ezek egyediek legyenek – még akkor is ha az expo számláló általában 4 jegyű száma átvált. Amint lementjük egy számítógépre, ott máris problémákba ütközünk ugyanis ahány szoftver annyiféleképpen szeretne segíteni nekünk és jól átnevezi a képeinket valami olyanra, ami alapján soha nem fogjuk tudni, hogy a kép miről szól, mikor, hol és melyik gépünkkel készült.

Ezt a kezdődő káoszt úgy tudjuk megelőzni, hogy tudatosan előre kitalált módszer szerint nevezzük el az állományokat, már a memóriakártyáról való első letöltéskor. Ez esetben sem szeretnék konkrét szoftvereket és azok beállításait mutogatni (majd lesz olyan cikk is, és akkor lehet rám csodálkozni, hogy van élet a photoshop-on kívül is :)

Fontos, hogy ezek az állományok sokkal több mindent tartalmaznak, mint magát a képet. Ezek közül az egyik legfontosabb az EXIF. Ezek olyan adatok, amikből többek között kiderülhet mikor, hol milyen eszközök – és azok milyen beállításaival készült az eredeti képkocka.

A megfelelő állománynevek megértéséhez, álljon itt egy példa:

DSC_8877.JPG -> 20110529-D70_038877.jpg

Hogyan is jött ez össze:

  • ’20110529′

Ezt gondolom mindenki kitalálta, hogy ez a kép készítésének dátuma. (EXIF: ‘Date/Time Original’) Ezt az információt a fényképezőgép teszi bele, szóval fontos hogy az órája mindig megfelelően legyen beállítva, különben csak növeljük a káoszt a képeink között…

  • ‘-’

Ez egy sima kötőjel – hogy ne follyon össze a dátum a többi mindennel ;)

  • ‘D70_03′

A ‘D70‘ a fényképező típusa, amivel készült. Ezt is a gép teszi bele (EXIF ‘Camera Model Name’) majd a ‘_03‘ egy manuálisan odabiggyesztett karaktersorozat, ami egy elválasztókarakter (_) után azt jelzi, hogy a gépemben már 3x körbefordult a számláló. Ezzel tulajdonképpen kibővítettem az expószámláló 4 számjegyét, így a sorszámok folyamatosak maradnak, és azt mutatják, hogy ténylegesen hányadik kép ami az adott géppel készült.

  • ’8877′

Ez az eredeti állománynévben szereplő számláló  – ami ugye gyorsan átfordulhat, ezzel elveszítve a lényegét. Az EXIF adatok közül általában elérhető egyébként a valódi számadat is: ‘Shutter Count’

  • .jpg

Ez pedig az eredeti állomány kiterjesztése, ami nem feltétlenül mindig .jpg, lehet a gyártó saját RAW (D70 esetében .NEF) formátuma is – vagy akár mindkettő, természetesen két külön kép formájában.

Ilyen – vagy ehhez hasonló – elnevezési sémákat minden valamire való szoftvernek tudnia kellene kezelni, amivel már a letöltés során megfelelőre nevezhetjük képeinket. Az általam használt szoftver importálási funkciójánál például így kell mindezt megadni: “[YEAR][MONTH][DAY]-[model3]_03[onum][oext]” Amiből látszik, hogy az egyetlen kézi karaktersorozat a ‘_03′ erre kell csak figyelnem, hogy átváltáskor ezt is megváltoztassam, a többi minden benne van a fényképezőből kiköpött állományokban.

Válogatás és címkézés

Mindegy milyen szinten műveljük a fotózást, előbb vagy utóbb rengeteg fotónk lesz. Annyira, hogy az hamar kezelhetetlenné válik, még akkor is ha konzekvensen és megfelelően nevezzük el őket. Az első és kulcsfontosságú megoldás erre a TÖRLÉS. Igen, úgy értem hogy a rossz/béna/homályos/nemtetsző/félresikerült képeket azonnal töröljük! Ezzel megmentve magunkat egy csomó későbbi felesleges munkától, tárterület igénytől, és az őrülettől ;)

Ha csak a valóban értékelhető képeket tartjuk meg, akkor sokkal könnyebb lesz azokat kordában tartani, és katalogizálni. – Ez ugyanis a következő lépés, hogy valamilyen szoftver segítségével logikai rendbe állítsuk a sok-sok képet. Erre a feladatra megint csak rengeteg szoftver alkalmas lehet, a válasszuk a nekünk megfelelőt. Szerintem, a következőket kell(ene) tudni egy ilyen szoftvernek:

  • importáláskor automatikus átnevezés és könyvtárstruktúrába helyezés lehetősége EXIF adatok alapján.
  • hierarchikus katalógusok/csoportok létrehozásának lehetősége, az eredeti képek módosítása nélkül, lehetőleg saját magunk által szerkeszthető ‘tag’-ekkel.
  • egy kép több kategóriába is kerülhessen
  • timeline – azaz a képeket rendezhessünk időrendbe
  • verzió kezelés – azaz ha módosítani szeretnénk valamelyik képet, azt úgy tegye, hogy az eredetit NEM módosítja, hanem egy új verziót hoz létre – betartva az általunk meghatározott nevezéktant!
  • exportálás – azaz a kívánt képeket (automatikus átméretezési lehetőséggel) egyből összepakolhassuk a nekünk fontos formában (webalbum, .zip fájl, külön könyvtár, CD/DVD, stb)

Természetesen, ezek csak az én alapvető igényeim egy ilyen szoftverrel kapcsolatban. Mivel ezekből tényleg rengeteg van -így mindenki megtalálhatja a neki megfelelőt, egy kis guglizással ;)

Archiválás és mentés

Idáig nagyon kevesen jutnak – azok is általában csak egy adatvesztés után. Nem is próbálom túlmagyarázni ennek szükségességét, inkább csak leírom én hogyan teszem ezt:

  • minden fotózást (nyaralást/kirándulást/összejövetelt) a memória kártyák (igen, viszek tartalékot is) formázásával kezdek.
  • a komolyabb fotózásokat esetén RAW (+jpeg) , nyaralást egyebet csak jpeg-ben fotózóm.
  • az esemény (nyaralás/kirándulás/bármi) után egyből lementem a kártya tartalmát egy kártyaolvasóval ellátott mobil tárolóegységre.
  • importálom a képeket a gépemre, (amiben tükrözött és titkosított tárolóegységeket használok) majd kiválogatom, katalogizálom, szerkesztem, retusálom őket.
  • a gépemen lévő fotókat és a katalogizáláshoz szükséges adatbázisokat rendszeresen lementem egy 3. külső (titkosított) tárolóegységre.

Így – mérettől függően – de legalább egy évnyi nyers fotó megvan a mobil kártyaolvasós egységen, minden válogatott/módosított/katalogizált kép megvan a gépemen, és egy 3. tárolóegységen is. Ez – az egyre növekvő tárolók megjelenésével – tartható megoldásnak tűnik…

Digitális képek publikálása

Ezt viszont mindenki megteszi valahogy. Legtöbben persze szándékosan teszik közzé fotóit: levélben, MMS-ben, közösségi oldalon, fotós portálokon, privátnak hitt ‘zugokban’ – ám nem tisztában ennek következményeivel.

Nézzük, mit tehetünk a képeink megfelelő publikálása érdekében:

  • Megvan nálunk az eredeti kép.

Jogi dolgokba nem szeretnék mélyebben belefolyni, ám ez alapvető dolog. Van ugyanis olyan helyzet, hogy be kell tudni bizonyítani hogy a képet mi csináltuk…

  • Vízjelet pakolunk a fotóinkra.

Ez akár jó dolog is lehet, mert reklám a fotósnak – ha nem viszi túlzásba. Én személy szerint nem szeretem őket, de lehet csak azért mert túl sok a rossz példa, vagy még nem találtam meg a képeimhez és a stílusomhoz illőt ;)

  • ‘Kis méretben’ tesszük csak közzé képeinket.

Ez szinte természetes is,  minek egy böngészőben/telefono/tableten 10 Mp-es kép, amikor nagyon jó esetben is a kijelzőnk full HD felbontást (1920×1080) tud ‘csak’, ami valójában ~2Mpixelt jelent! Ez a felbontás – tapasztalataim szerint – a kifejezetten nagy panoráma képeimhez is elegendőnek bizonyult. Ezen kívül, az állományok mérete sem mindegy, hiszen azt mindenkinek le kell tölteni a böngészőjével. Arról nem is beszélve, hogy sok oldalon van feltöltési méretkorlát… na, ilyen esetekben jó ha tudjuk hogyan lehet kis állományméretű, de jó minőségű képeket létrehozni…

Képeink publikálása esetén azonban soha ne feledjük:

Ami egyszer az internetre került, azt szinte bárki megnézheti, megszerezheti, lemásolhatja, ellophatja. És onnan teljesen eltüntetni sok esetben lehetetlen.

Persze, én köztudottan paranóiás vagyok – ez nálam szakmai ártalom ;)

vCenter Server Appliance – éles üzemben

Előző cikkeimben bemutatásra került a VMware új, Linux alapú vCenter Server Appliance megoldása, és a vele együtt debütáló egyik új lehetőség: az Auto Deploy. Ezekben a cikkekben megismerkedhettünk az új termékekkel és hozzájuk kapcsolódó szolgáltatásokkal, majd telepítésükkel és alapvető beállításaikkal. Ám mindez csak arra elég, hogy egy teszt rendszeren bemutatható legyen a dolog, valós üzemeltetési tapasztalatot csak éles környezetben lehet szerezni, így mi – vélhetően elsőként – éles üzembe állítottuk az új appliance megoldást.

A következőkben, az élesbe állítás lépeseit fogom bemutatni – a hozzá szükséges egyéb kiegészítésekkel és beállításokkal együtt. Majd – hozzászólások formájában – a használata és üzemeltetése közben szerzett tapasztalataimat fogom megosztani itt.

Előkészületek

Mielőtt nekiesnénk az új vCenter Server telepítésünknek, néhány fontos dolgot tisztázni kell:

Az itt leírtak megértéséhez és alkalmazásához a VCP szintű VMware ismeretek mellett a SUSE Linux rendszergazda szintű ismerete is elengedhetetlen.

Limitációk

Ami persze relatív, de mindenképp említésre érdemes különbségek a ‘megszokott’ windows alapú vCenterhez képest:

  • Nem lesz ‘Update Manager’

Ha használjuk az AutoDeploy-t, nem is lesz rá szükségünk többé!

  • Nem használhatunk ‘Linked Mode’-ot

Nem tudom ezt ki használta, és mire…. de szerintem a gyakorlatban használhatatlan. Semmi olyat nem nyújt számunkra, amire valóban szükségünk lenne. Amit elvártunk volna tőle, azt meg nem tudja…

  • Nem használhatunk ‘vCenter Hertbeat’-ot

Ezt nem tudom ki találta ki, és főleg minek? HA windows-on? Köszönjük, nem kértük eddig sem.

  • A ‘vSphere Storage Appliance’ egyelőre nem támogatott

Ez szintén a vSphere 5.0-ban jelent meg, senki nem használta még élesben, nekünk nem is hiányzik, van rendes storage-ünk :)

  • Külső adatbázisként csak Oracle használható

A Windows-tól és az MS termékektől igyekszünk szabadulni, így ez annyira nem fáj. – De véleményem szerint egy MySQL is bőven elegendő lenne a feladatra. Kis és közepes (magyarországon csak ilyen van) környezetek esetében pedig megfelelő lehet a beépített DB2 is.

  • Migrációra nincs lehetőség

Ez azonban már kicsit fájhat, hiszen újra kell telepíteni a teljes virtuális infrastruktúrát. Emiatt sokkal körültekintőbben kell eljárni, és előre megtervezni az átállás folyamatát. Teljesen új projekt esetén persze ez megint nem hátrány…

Szükséges információk

  • Topológia

Hacsak nem egy szigetet tervezünk építeni a semmi közepére, akkor szükségünk van a meglévő hálózatok konkrét topológiájának teljes ismeretére – Ennek hiányában akár  a meglévő hálózat teljes összeomlását is okozhatjuk – amiért nem fognak megdícsérni.

Egy virtuális környezet megfelelően biztonságos tervezése külön feladat, erre nem is térnék ki most, addig is, javaslom az egyik korábbi VMUG-on tartott előadásom anyagát: vSphere-Hardening

A részletes és előzetes tervezés elengedhetetlen egy sikeres projekthez! Ha nem áll rendelkezésünkre saját, megfelelő hozzáértéssel (vmware, hálózat, security) rendelkező csapat, kérje külsős szakemberek segítségét, megéri! Egy ilyen átállás/migráció könnyen kudarcba fulladhat, ha az előzetes tervezést elhanyagoljuk. A tipikus tervezési hiányosságok pedig általában csak később bukkannak elő, amikor már valóban élesben üzemel a virtuális környezetünk. Legtöbb ilyen esetben az utólagos tervezés, és az ennek megfelelő átalakítások sokkal több pénzbe, időbe, és az éles környezet leállásába kerülnek!

  • IP cím

Kelleni fog egy IP az új vCenter számára, amit az eddig megszokott elérhetőségeken felül a :22 és a :5480 portokon kell majd az adminisztrátoroknak elérni.

  • DNS

Hasznos dolog előre előkészíteni az új gép DNS bejegyzését is, főleg ha ez nem a mi hatáskörünkbe tartozik…

  • DHCP

Az Auto Deploy működéséhez szükség lesz arra, hogy az ESX-ek dhcp segítségével kapjanak IP-t, és néhány speciális beállítást. Külső dhcp szerver használata esetén, azt külön fel kell erre készíteni, az appliance saját dhcp szerverének használata esetén ügyelni arra, hogy ez ne okozzon problémát a hálózat többi gépe számára.

  • Tanúsítványok

A telepítés során minden SSL-es kapcsolat egy self-signed tanúsítványt kapott, ami miatt a hozzáféréskor ‘SSL warning’-ot kapunk. Ezt sajnálatos módon legtöbben csak ‘ignorálják’, vagy jobb esetben felveszik elfogadott tanúsítványok közé. Az igazi megoldás azonban ezek cseréje, hivatalos – de legalábbis számunkra elfogadott – kiadótól származó tanúsítványokra.

Telepítés

Az appliance telepítése egyszerű, annak alapvető lépései megtalálhatóak itt: vCenter Server Appliance így azt ott leírtakat már nem ismétlem…

Beállítások

Az következőkben azokat a beállításokat, és extra teendőket részletezem, amik éles üzemhez szerintem elengedhetetlenek.

  • adatbázis

Jelen esetben a beépített DB2 adatbázist használjuk, amit a management felületen aktiválhatunk.

A jelenlegi legfrissebb verzió még tartalmaz egy hibát, ennek javítását már most tegyük meg, még mielőtt probléma lenne belőle.

  • user accountok

Lássuk, milyen aktív felhasználóik léteznek a rendszeren:

vcenter:~ # for user in `grep -v ":(*|!):" /etc/shadow |cut -d: -f1`; do grep $user /etc/passwd ; done
root:x:0:0:root:/root:/bin/bash
dasusr1:x:1001:108::/opt/db2/home//dasusr1:/bin/false
db2inst1:x:1002:109::/opt/db2/home//db2inst1:/bin/bash
db2fenc1:x:1003:110::/opt/db2/home//db2fenc1:/bin/false
vc:x:1004:100::/opt/db2/home//vc:/bin/false

Az eredményben látható felhasználóknak – számunkra legalábbis – ismeretlen a jelszava, ezek közül is kivastagítottam azokat, akiknek shell-jük is van. A root ugye mi vagyunk, ennek a jelszavát kapásból cseréljük is le!

  • ssh

Az imént fény derült rá, hogy vannak felhasználók akik nem a mi kezelésünk alatt állnak, így vegyük elejét a default jelszavak kihasználási lehetőségeinek, és tiltsuk le a jelszavas bejelentkezés lehetőségét! Ehhez először vegyük fel az ssh kulcsunkat a következő – még nem létező – állományba:

vcenter:~ # vim .ssh/authorized_keys

Majd, kapcsoljuk ki a jelszavas bejelentkezés lehetőségét, amit a : /etc/ssh/sshd_config állományban a következő sorral tehetünk meg:

PasswordAuthentication no

És indítsuk újra az érintett szolgáltatást:

vcenter:~ # service sshd restart

Ezek után nagyon hasznos, ha egy új belépéssel teszteljük is a beállítás sikerességét, még mielőtt kilépünk a jelenlegi session-ből…

  • ipv6

A VMware hivatalosan nem támogatja az ipv6-ot, ám az appliance alapjául szolgáló linux igen, így ha nem teszünk ellene, akkor minden szolgáltatás figyelni fog ipv6-on is, és akár tudtunk és beleegyezésünk nélkül még  IP címet is felvehet a gépünk – éljen az ipv6!

Ezt, és az ebből következő esetleges problémákat megelőzendő, kikapcsoltam az ipv6 támogatást, ám ez esetben egy csomó szolgáltatás el sem indult – így ez nem jó megoldás, marad a szigorú csomagszűrő.

  • csomagszűrő

Alapból nincs csomagszűrő a gépen, ami netstat kimenetét nézve eléggé merész dolog, éles üzembe állítani csomagszűrő nélkül elég nagy hiba lenne – főleg, ha az ajánlásaink ellenére nincs külön fizikailag szeparált management zóna kialakítva a vCenter és az ESX-ek management portjai számára.

Hogy ki milyen módszerrel varázsol csomagszűrőt, az mellékes, de valami ilyesmit kellene elérni:

vcenter:~ # ip6tables -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all      lo     *       ::/0                 ::/0                
    0     0 LOG        all      *      *       ::/0                 ::/0                LOG flags 0 level 4 prefix `D:INPUT ' 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all      *      *       ::/0                 ::/0                LOG flags 0 level 4 prefix `D:FORWARD '

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
vcenter:~ # iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination         
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:113 reject-with icmp-port-unreachable
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:5480
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:514
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:514
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:902
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:6500
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:6502
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `D:LOdmz '
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `D:FORWARD '
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
  • ntp

Az alap telepítés esetén ki van kapcsolva az ntp szerviz, és a management felületről sem lehet ntp szervert felvenni, illetve a szolgáltatást elindítani, így használjuk a yast2 konfig szerkesztő izét – amit személy szerint nagyon utálok, de mivel az összes konfig ezzel készült, így mégis ezt használom, nehogy a következő rendszerfrissítésnél probléma legyen belőle.

  • log gyűjtés és forgatás

Na, itt van a legnagyobb káosz. Számomra teljesen érthetetlen módon, totálisan bénán van konfigurálva a log forgatás, aminek következtében egy éles rendszeren rengeteg log állomány keletkezik, össze vissza forgatva. Véleményem szerint, az összes logot a következők szerint érdemes forgatni:

daily
rotate 365
create
dateext
compress
delaycompress

A fentieket beállítottam a /etc/logrotate.conf-ban, majd a /etc/logrotate.d/ könyvtár alatt az összes állományból kigyomláltam azokat a sorokat amik a fentieknek ellentmondó volt…

Így, remélhetőleg egységes, és áttekinthető logokat kapunk…

  • felügyelet

Egy éles gépet felügyelni kell, hogy az adminisztrátorok időben értesüljenek az esetleges hibákról vagy rendellenességekről. Mi erre Munin-t és Nagios-t használunk, saját kibővített szenzorokkal…

Mindezektől függetlenül, mindenképp hasznos dolog a root felhasználó postaládáját egy létező, és általunk olvasott postafiókra továbbítani. Ezt legegyszerűbben az  /etc/aliases állományban tehetjük meg.

Tanúsítványok

Éles üzemben érdemes hivatalos tanúsítványokat használni, amit beszerezhetünk publikus tanúsítvány kiadóktól vagy,  ha cégünk rendelkezik belső PKI rendszerrel, akkor egy céges tanúsítvány is megfelel. Mindössze egyetlen tanúsítványra lesz szükségünk arra a névre kiállítva, amivel majd a böngészőkből és vSphere kliensből el szeretnénk érni…

Lássuk, pontosan milyen szolgáltatásokhoz is kell SSL tanúsítvány:

:443

Ez a standard https port, azonban a vcenter esetében nem csak egy egyszerű webszerver figyel itt, hiszen tulajdonképpen ide csatlakozunk a vSphere klienssel is. Az appliance esetén a következő állományokban találhatóak a tanúsítványok:

/etc/vmware-vpx/ssl/rui.crt
/etc/vmware-vpx/ssl/rui.key
/etc/vmware-vpx/ssl/rui.pfx

Ezek közül, a .crt, és a .key nem szorul különösebb magyarázatra, azonban a .pfx igen, ugyanis ezt a következő paranccsal kell létrehoznunk:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Igen, a jelszónak is PONTOSAN így kell kinézni – gondolom, valahol jól bele van drótozva az alkalmazásba…

Hogy használja is a rendszer az új tanúsítványokat, ezeket be is kell tölteni. A hivatalos dokumentáció szerint, nem is mindegy hogy hogyan!

Persze, ez a windows-os verzióról beszél, értelem szerűen kisebb módosításokkal, de követni kell a leírást, majd a végén újraindítani az érintett szolgáltatásokat:

service vmware-vpxd restart

:5480

Ezen a porton érhető el az adminisztrációs felület. Ezt egy igen egyszerű webszerver szolgálja ki, a lighthttpd. Ez alatt a tanúsítványt a következő paranccsal cserélhetjük ki:

cat rui.key rui.crt >/opt/vmware/etc/lighttpd/server.pem

Majd indítsuk újra az érintett szolgáltatást:

service vami-lighttp restart

Természetesen, jogos igény lenne, hogy tovább szigorítsuk a szolgáltatáshoz való hozzáférést, hogy csak a megfelelő kliens tanúsítvánnyal rendelkezőket engedjük kapcsolódni… Ennek beállításához a következőkre lenne szükség:

#### SSL engine
ssl.engine                 = "enable"
ssl.pemfile                = "/opt/vmware/etc/lighttpd/server.pem"
ssl.ca-file                = "/opt/vmware/etc/lighttpd/CA.pem"
ssl.verifyclient.activate  = "enable"
ssl.verifyclient.enforce   = "enable"

Ám ez a verzió – amit várhatóan a VMware saját maga fordított – ezt valamiért mégsem támogatja :(

vcenter:~ # service vami-lighttp restart
Shutting down vami-lighttpd: done.
Starting vami-lighttpd: done.
2011-12-01 12:17:03: (/build/mts/release/bora-471789/vadk/src/vami/apps/lighttpd/1.5.0-2349/src/server.c.1485) WARNING: unknown config-key: ssl.verifyclient.activate (ignored)
2011-12-01 12:17:03: (/build/mts/release/bora-471789/vadk/src/vami/apps/lighttpd/1.5.0-2349/src/server.c.1485) WARNING: unknown config-key: ssl.verifyclient.enforce (ignored)

:9443

Itt lenne elérhető a web client – ám ezt éles környezetben használni igen nagy bátorság. Az előző cikkből kiderülhetett hogy ez egy flash izé, az ígéretekhez képest nagyon kevés implementált fícsörrel. Most még jobban megvizsgálva, az egész egy nagy java-s katyvasz, gyanúsan féligkész megoldások halmazával, amiknél a tanúsítvány cserét sem sikerült végeznem egyelőre… Legjobb, ha csomagszűrőből tiltjuk ehhez a porthoz való hozzáférést!

 Mentés

Mivel ez egy virtuális gép, így mentését megoldhatjuk ugyan úgy, ahogy a többi VM-et is mentjük :)

Persze, sokkal szofisztikáltabb módszereket is alkalmazhatunk, aminek lényege hogy egy default install után a mentéstben szereplő állományokat visszatöltve ismét megkapjuk a jelenlegi, működő allapotot.

Ehhez menteni kell a következőket:

  • Adatbázis

Ez egylőre fekete bárány, mivel eddig nem üzemeltettünk DB2 adatbázist, így menteni sem nagyon tudom hogyan kellene – a cél hogy az adatbázis visszaállítható legyebn :)

  • Konfigurációs állományok, és tanúsítványok

Ezeknél egyszerűbb a dolgunk, hiszen csak azokat az állományokat kell menteni, amiken változtattunk…

Migráció

Maga a migráció – egy éles környezet estén – a legkritikusabb fázis, ugyanis általában a cél az, hogy a lehető legkisebb leállása vigyük át a virtuális gépeket az új környezetbe. Sokszor az új környezet tulajdonképpen a meglővő vCenter és ESX-ek cseréjét jelenti, így visszaállásra nnics – vagy csak rengeteg munka árán van – lehetőség. Így ehhez a műveletethez mindenképp javasolt hozzáértő szakemberek segítségét kérni.

A feladat összetettsége – és a lehetséges kiinduló állapotok sokfélesége miatt – ehhez konkrét leírást adni nem lehet. Irányadónak a hivatalos dokomentációt javaslom.

Frissítések

Ez egyelőre kényes – és ráadásul ismeretlen terület, mert jelenleg nincs elérhető frissítés. Ám, amint lesz, különösen oda kell arra figyelni, hogy mi lesz a sorsa az általunk kézzel módosított állományoknak!

Összefoglalás

Ahogy az elején is felhívtam erre a figyelmet, az itt leírtak megvalósításához komoly szakértelem kell. Könnyen előfordulhat, hogy valami mégsem úgy működik ahogy leírtam, így csak akkor áljon neki bárki ilyen szintű módosításoknak, ha probléma esetén egyedül is elboldogul. Hivatalos supportot ilyen szintű módosítások után kizárt hogy bárki is nyújtson egy ilyen rendszerre.

Tehát, bármilyen módosítást mindeki csak SAJÁT FELELŐSSÉGRE végezzen!

vSphere 5.0 – Image Builder

Egyik előző cikkemben, a vSphere 5.0-ban megjelent Auto Deploy lehetőségeit, és alapvető beállításait  mutattam be, és csak utaltam arra, hogy az Image Builder segítségével a gyakorlatban nagyon hatékonyan hozhatunk létre saját ESX profilokat.

Éppen ezért, folytatásként az Image Builder-ben rejlő hatalmas lehetőségeket fogom részletesen bemutatni.

Igen nagyon fájó pont, hogy az egész Image Builder-t egyelőre kizárólag Windows alól lehet birizgálni, ami eléggé kiábrándító egy Linux alapú appliance megoldás esetén…

Szóval, kerítsünk egy PowerCLI-vel felvértezett windows-t, és csatlakozzunk az vCenter Server-hez:

PowerCLI C:> Connect-VIServer -server 192.168.201.50

Majd, nézzük meg milyen Profile-ok állnak a rendelkezésünkre:

PowerCLI C:> Get-EsxImageProfile

Name                           Vendor          Last Modified   Acceptance Level
----                           ------          -------------   ----------------
ESXi-5.0.0-469512-no-tools     VMware, Inc.    19/08/2011 1... PartnerSupported
ESXi-5.0.0-469512-standard     VMware, Inc.    19/08/2011 1... PartnerSupported

Ha az előző cikkben leírtak alapján jártunk el, akkor a fenti kimenetet kapjuk.

Lássuk, melyik oszlop mit is jelent számunkra:

  • Name

Ez ugye nem kíván túl sok magyarázatot. Fontos azonban, hogy egyedi nevet adjunk a leendő saját profiloknak, és praktikus ha benne van a kiinduló ESX csomag pontos verziója, és a patch level is.

  • Vendor

Cégünk nevét írhatjuk ide, nem árt ha tudják a későbbi felhasználói kiket kell szidni, ha valami nem okés vele kapcsolatban ;)

  • Last Modified

Magáért beszél…

  • Acceptance Level

Ez egy igen fontos paraméter, ugyanis ezzel határozhatjuk meg, hogy kitől származó csomagokat (VIB’s) pakolhatunk bele. A lehetséges értékei megbízhatósági sorrendben: VMwareCertified, VMwareAccepted, PartnerSupported, and CommunitySupported

Saját profil létrehozása

A fentiek ismeretében, hozzunk létre egy másolatot az egyik meglévő profile-ból, amit később majd jól testre szabunk az igényeinknek megfelelően:

PowerCLI C:> New-EsxImageProfile  -CloneProfile ESXi-5.0.0-469512-standard -Name "ESXi-5.0.0-469512-v" -Vendor "Andrews Kft." -Description "Image Profile optimized for virtual ESX servers"

És Íme az eredmény:

PowerCLI C:> Get-EsxImageProfile

Name                           Vendor          Last Modified   Acceptance Level
----                           ------          -------------   ----------------
ESXi-5.0.0-469512-no-tools     VMware, Inc.    2011.08.19. ... PartnerSupported
ESXi-5.0.0-469512-standard     VMware, Inc.    2011.08.19. ... PartnerSupported
ESXi-5.0.0-469512-v            Andrews Kft.    2011.08.19. ... PartnerSupported

Innentől, neki is állhatunk „testre szabni”. Ezzel azonban csak óvatosan, ugyanis igen könnyen elérhetjük, hogy az adott profile használhatatlan legyen. Éles környezetben használt profile-et SOHA ne piszkáljunk!

De mit is értünk a ‘testreszabás’ alatt? Egy-egy ilyen profile, különböző csomagok együttese, aminek a végeredménye – jó esetben – egy bootolható ESX image.

Lássuk, milyen csomagokból áll a gyári profile:

Csomagok listázása

PowerCLI C:> Get-EsxSoftwarePackage

Name                     Version                        Vendor     Release Date
----                     -------                        ------     ------------
net-ixgbe                2.0.84.8.2-10vmw.500.0.0.46... VMware     2011.08.19. 1...
ata-pata-hpt3x2n         0.3.4-3vmw.500.0.0.469512      VMware     2011.08.19. 1...
ehci-ehci-hcd            1.0-3vmw.500.0.0.469512        VMware     2011.08.19. 1...
ata-pata-atiixp          0.4.6-3vmw.500.0.0.469512      VMware     2011.08.19. 1...
scsi-megaraid2           2.00.4-9vmw.500.0.0.469512     VMware     2011.08.19. 1...
scsi-aic79xx             3.1-5vmw.500.0.0.469512        VMware     2011.08.19. 1...
net-r8168                8.013.00-3vmw.500.0.0.469512   VMware     2011.08.19. 1...
ohci-usb-ohci            1.0-3vmw.500.0.0.469512        VMware     2011.08.19. 1...
scsi-qla4xxx             5.01.03.2-3vmw.500.0.0.469512  VMware     2011.08.19. 1...
ata-pata-sil680          0.4.8-3vmw.500.0.0.469512      VMware     2011.08.19. 1...
scsi-megaraid-sas        4.32-1vmw.500.0.0.469512       VMware     2011.08.19. 1...
uhci-usb-uhci            1.0-3vmw.500.0.0.469512        VMware     2011.08.19. 1...
ata-pata-amd             0.3.10-3vmw.500.0.0.469512     VMware     2011.08.19. 1...
net-bnx2                 2.0.15g.v50.11-5vmw.500.0.0... VMware     2011.08.19. 1...

A fenti lista (ami persze nem teljes) az összes rendelkezésre álló depot-ban található, összes csomagot (VIB) tartalmazza! – Számomra érthetetlen okokból egy konkrét profile-ban található csomagokat egyelőre nem lehet kilistázni :o

Összehasonlíani viszont lehet:

PowerCLI C:> Compare-EsxImageProfile -ReferenceProfile ESXi-5.0.0-469512-standard -ComparisonProfile ESXi-5.0.0-469512-no-tools

Equal               : False
PackagesEqual       : False
RefAcceptanceLevel  : PartnerSupported
CompAcceptanceLevel : PartnerSupported
OnlyInRef           : {VMware_locker_tools-light_5.0.0-0.0.469512}
OnlyInComp          : {}
UpgradeFromRef      : {}
DowngradeFromRef    : {}

Aki a Linux/Unix parancssorhoz szokott szokott – mint én – az kicsit meglepődik a kimenet gagyiságán ;) De persze mit vártam? Az egész PowerCLI egy vicc, néha már-már sírva fakadtam használata közben :O

Ám, ha ezen valahogy túltesszük magunkat, akkor megtalálhatjuk hogy a két profile egyetlen csomagban (VMware_locker_tools-light_5.0.0-0.0.469512) tér el egymástól – ahogy az várható is volt…

Persze, a csomag neve is zanzásítva van, a listában ezt így találjuk meg: ‘tools-light– Ezúton is csókoltatom a kedves fejlesztőket :P

Innentől viszont, már szinte minden egyértelmű, szabjuk hát saját igényeinkhez az újonnan létrehozott profile-unkat!

Csomag (VIB) hozzáadása

Ehhez persze csomag is kell, amiket általában a hardvergyártók bocsájtanak rendelkezésünkre, és tartalmuk ennek megfelelően driver vagy kiegészítő szoftver a saját hardvereikhez. Tehát, amit tőlük kapunk az egy kupac szoftver (depot) amit először hozzá kell adnunk az Image Builderhez, csak úgy mint a VMware által adott alap csomagot:

PowerCLI C:> Add-EsxSoftwareDepot <csomagnév>.zip

Majd, a benne lévő VIB-ek közül, adjuk hozzá a nekünk szükségeset a profilunkhoz:

PowerCLI C:> Add-EsxSoftwarePackage –ImageProfile ESXi-5.0.0-469512-v -SoftwarePackage <csomagnév>

Csomag (VIB) eltávolítása

Na, ilyenkor hiányzik igazán az a parancs, amiből megtudhatnánk, hogy mit is tartalmaz a profil tulajdonképp – de ha valahogy kitaláltuk, akkor törölhetünk közűlük ;)

PowerCLI C:> Remove-EsxSoftwarePackage -ImageProfile ESXi-5.0.0-469512-v -SoftwarePackage <csomagnév>

Ha jól megnézzük, egy adott hardver használata esetén rengeteg számunkra teljesen felesleges csomag törölhető! Így, sokkal kisebb lesz a végső image mérete, aminek következtében kevesebb memóriát pazarol, gyorsabban bootol, és kevesebbszer kell frissíteni – hiszen, biztosan nem lesz minden frissítésnél érintett az a maradék pár csomag, ami az adott hardverhez kell…

Profile exportálása

Az így elkészült, saját igényeinkhez igazított telepítőkészlet többféle formában használható fel

  • Auto Deploy

Vagyis a profilt Auto Deploy profilként használjuk, ehhez persze előbb hozzá kell rendelni az Auto Deploy szerverben – különböző szabályok alapján – az ESX szervereink egy részéhez.  Lásd később…

Figyelem! – A profile ezen formája csak az aktuális PowerCLI session-ben létezik. Tehát, ha kilépünk, többé már nem használhatjuk, hacsak nem exportáljuk .zip formába!

  • .zip

Ha saját profilt készítettünk, és később is szeretnénk még használni, mindenképp exportáljuk .zip formába! Persze, az is lehet cél, hogy ezt a remek új csomagot terjeszthetővé tegyük – például ügyfeleink számára. Ehhez nincs más teendőnk, mint kiexportálni .zip formátumba a következő parancs segítségével:

PowerCLI C:> Export-EsxImageProfile –ImageProfile ESXi-5.0.0-469512-v –FilePath D:VMwaredepotsAndrews-ESXi-5.0.0-469512-v.zip –ExportToBundle
  • .iso

Hasznos lehet néha, ha telepítőmédiát (CD/DVD) is tudunk készíteni a profilunkból:

PowerCLI C:> Export-EsxImageProfile –ImageProfile ESXi-5.0.0-469512-v –FilePath D:VMwaredepotsAndrews-ESXi-5.0.0-469512-v.iso –ExportToIso

 

AutoDeploy szabályok

Az elkészült ESX profilakat ezek után, különbözős szabályoka alapján rendelhetjük a megfelelő ESX csoporthoz. A legegyszerűbb szabály, ami minden ESX-re érvényes:

PowerCLI C:> New-DeployRule -Name "Initial ESXi5" -Item "ESXi-5.0.0-469512-standard" -AllHosts 

Ezt azonban lehet tovább finomítani, hiszen nem biztos, hogy minden ESX-re ugyan azt az image-et szeretnénk bootolni: Ezesetben, az ‘-AllHosts‘ paramétert a ‘-Pattern’ -re kell cserélni, és megadni az ESX-ek azonosításához szüksége paramétereket…

Igen ám, de mik is lehetnek ezek a paraméterek?

Ez sajnos egyelőre nincs túldokumentálva, a legbiztosabb, ha direkt olyan rule-t hozunk létre (vagy egyátalán nem hozunk létre) ami nem illeszkedik az érintett ESX-re, és akkor a boot során hibaüzenetet kapunk, ahol az adott hardverre érvényes összes paramétert felsorolja:

 

screenshot-tftp-error-00

Ezek valahol a logokban is meg kellene hogy jelenjenek, ám én sehol sem találtam ezeket…

Hasznos dolog még, hogy vCenter szabályokat is lehet megadni a ‘-Item‘ kapcsolóval. Ennek hatására a frissen bootolt gép, automatikusan bekerülhet a megadott vCenter objektumba, amik a következők lehetnek:

  • cluster
  • folder
  • host profile
  • image profile

Ezeket a szabályokat aztán, hozzá is kell adni az aktív szabályokhoz:

PowerCLI C:> Add-DeployRule -DeployRule "Initial ESXi5"

Mivel egy ESX-re akár több szabály is illeszkedhet, fontos hogy egyféle objektum típus hozzárendelésből csak egy lesz érvényes! – Tehát, ha ugyan azt a host-ot két különböző clusterhez is hozzáadná két rá illeszkedő szabály, csak a magasabb prioritású lesz érvényes, több különböző típusú objektumba helyezés esetén viszont mindegyik érvényesül!

A szabályok prioritását az -At <prioritás> kapcsolóval szabályozhatjuk, ahol a kisebb érték jelenti a magasabb prioritást. – Szintén kezdeti hiányosság, hogy a listázásnál ezt egyáltalán nem mutatja :o

A fenti parancsok teljes dokumentációja természetesen megtalálható a VMware oldalain. Ennek tanulmányozását ajánlom mindekinek.

Összefoglalás

Ezekkel a lehetőségekkel rendkívül rugalmas, és könnyen kezelhető virtuális környezetet hozhatunk létre. Természetesen, ezen megoldások nagy része még igencsak gyerekcipőben jár – még akkor is ha a marketingesek az érintett termékek eladásakor nem így nyilatkoztak – ezt, többek között a hiányos parancsok, a PowerCLI-hez való értelmetlen ragaszkodás, és az appliance szervizeinek debug szintű logolása is bizonyítja

Azonban, mindez agyon ígéretes, érdemes vele foglalkozni! Főleg, nagy számú ESX-et tartalmazó virtuális környezetek esetében :)