Asterix's space

 Egyik kollégám megkérdezte tőlem, hogy a DHCP esetén miért van szükség kizárásokra, mert nem teljesen világos számára – ezért írtam egy kis fogalom-összefoglalót…

A fenntartások egyértelműek, hiszen ott egy adott MAC-címhez rendelünk hozzá adott IP-címet.

De ha egy adott IP-címtartományt nem akarunk kiosztani, akkor nem vesszük fel – egyszerű, nem? Minek akkor kizárások?

Nos, nem ennyire egyszerű a helyzet. Egyrészt a címkészlet folyamatos kell legyen – tehát nem tehetjük meg, hogy felveszünk egy hatókört a 10.0.0.11-10.0.0.50 címkiosztással, majd egy másik hatókört a 10.0.0.71-10.0.0.100 címtartománnyal. S mégis miért szeretnénk így felosztani? Mert mondjuk adott gépeket a 10.0.0.51 címtől akarunk kiosztani, hogy egymás után legyenek (pl. nyomtatók, saját ip-címmel rendelkező hálózati eszközök, stb.). Ebben az esetben felvesszük a teljes címtartományt (11-100), majd kizárjuk a terjesztésből azokat a címeket, amelyekkel mi akarunk rendelkezni (51-70).

Itt jön képbe a fenntartás és a kizárás közti különbség.

Ha csak fenntartást alkalmaznánk, akkor lehet, hogy eleinte csak 2-3 fenntartott ip-címünk lesz, tehát a kiszolgáló ezeken kívül minden ip-címet megpróbál kiosztani (beleértve a féltve őrzött 51-70 tartományunkat is).

Kizárás esetén nem kerül be „más” gép az adott címtartományba – még akkor sem, ha induláskor a kérdéses, „speciális” eszközök száma kevesebb, mint ahány ip-cím ott rendelkezésre állna. Ugyanakkor fontos tudni, hogy fenntartás esetén mindenképp kiosztásra kerül a cím (tehát akkor is, ha kizárt tartományba esik).

Ha viszont az eszköznek csak kézileg tudunk ip-címet adni, akkor a DHCP-bérletek között nem fog megjelenni (azaz a szolgáltatás nem tükrözi a hálózatunk címkiosztását). Persze, ha fix ip-s a gép – és bekapcsoltuk ezen gépek felderítését ! –, a DHCP nem osztja ki azt a címet. Illetve, itt is pontosítani szeretnék: W2k vagy újabb gépek esetén, ha a kliens IP-címütközést észlel a felajánlott ip-cím kapcsán, akkor DHCPDECLINE választ küldenek a szervernek. Régebbi gépek esetén be lehet kapcsolni a szerveren, hogy ő végezze el ezt a feladatot (sima, mezei ping parancs segítségével), ehhez a ping-ek számát kell növelni (alapból 0), de nem javasolt a 2-nél nagyobb érték (bár hivatalosan 6-ig lehet).

A legutóbbi Lurdy-s előadáson nem tudtam részt venni, viszont szerencsére kiszúrtam, hogy interneten is lehet követni. Erre az RSS-olvasóm, az Omea Reader „figyelmeztetett”, Flowman cikkén keresztül. Ott szerencsére be is volt ágyazva a követési lehetőség, amihez a Silverlight-ot igényelte a gépem. Telepítettem, majd elkezdtem követni az előadást.

Mivel nem akartam az Omea-t megfosztani eredeti feladatától, ezért megpróbáltam „normális” böngészőben nézni az előadást – s ekkor akadtam ki. Ugyanis ami az Omea-ban teljesen jól látható volt, az az IE8-ban nem jelent meg, folyamatosan a Silverlight telepítését hiányolta (mintha nem lett volna telepítve). Amikor viszont telepíteni akartam, akkor meg őt akasztottam ki, hiszen akkor már felismerte, hogy már a gépen van.

Több próbálkozás után (eltávolítás, újratelepítés, stb.) a webes keresőhöz fordultam – addig azt hittem, hogy én szúrok el valamit (bár egy next-next-finish-ben nincs nagyon mit J ). Ott végül rátaláltam a megoldásra: ki kell kapcsolni egy add-ont, s akkor működni fog:

Ha létezik AG Core szervíz, akkor a Silverlight használatához az add-on-ok közül ki kell kapcsolni az agcore.AGUtils nevűt, az AG Interactive cégtől.

S hogy pontosan ez micsoda? Nos, erre is ráment egy kis időm, hiszen első körben mindenhol az agcore.dll-t a Silverlight-hoz kapcsolják. Később abba az irányba mozdultam el, hogy valószínűleg a Webshots képernyő-kímélő teszi fel – viszont amikor ezt az elméletem igazolni akartam, akkor nem sikerült. A teszt-gépekre nem került fel ez a szolgáltatás, szóval még most sem vagyok 100% meggyőződve...

Az előző cikkemnek az volt az apropója, hogy amióta W7-re váltottam, azóta nem tudtam használni a vágólapot a host (gazda-gép) és a guest (vendég-gép) között. Eleinte azt hittem, hogy a Windows Virtual PC RC kiadása a hibás, de amióta feltettem az RTM-et, sajnos azóta sem változott. Eddig nem volt időm vele foglalkozni, most szakítottam egy kicsi időt, hogy utánanézzek.

Ha engedélyezzük az „Enable integration features” opciót, akkor kér egy felhasználói fiókot, aminek a nevében fusson az integráció. Ez a vendég-gépen található fiókok közül kell legyen az egyik. Nem szükséges semmilyen extra jogosultságot adni neki, sőt, ez a fiók lehet akár letiltott állapotban is.

Majd amibe egyből belefutottam: engedélyezés után a vendégre csak és kizárólag a vendég-gép admin csoportbeli felhasználói tudnak bejelentkezni (a többiek „A rendszer helyi házirendje nem teszi lehetővé az interaktív bejelentkezést” hibaüzenetet kapnak – ennek még utána szeretnék járni). Ha nincs engedélyezve az együttműködés a gazda-géppel, akkor bárki bejelentkezhet – de értelemszerűen ekkor nincs integráció.

Elindítás után mindig az integrátor fiók nevében próbál bejelentkezni, de ha nem sikerül (ld. előző bekezdések), akkor be tudunk jelentkezni egy másik rendszergazda jogú felhasználóval – attól még működik az integráció. Ha nem pipáltuk be azt, hogy őrizze meg az integrátor jelszavát, akkor sem kér tőlünk jelszót, ha csak újraindítjuk a virtuális gépet – csak akkor, ha leállítottuk, s úgy indítottuk el ismét. Egyszerű újraindításnál viszont az utolsó bejelentkezett felhasználó nevét őrzi meg a Windows login-ablaka.

S milyen előnyünk származik engedélyezett állapotban? Finoman tudjuk szabályozni, de nagy vonalakban: működik a vágólap átadás gazda és vendég gép között, a hang átmegy a gazda kimenetére (bár ehhez jó volt a régi VM Additions is), kártyaolvasó a vendégen, megjelennek a gazda nyomtatói, illetve kötetei a vendégen. (Figyelem! Ha menet közben módosítunk, akkor valóban újra kell indítsuk a vendéget, hogy lássuk az eredményt. Sőt, nem sima újraindítás, hanem leállítás-újraindítás – ez sajnos nincs javítva az új (RTM) verzióban sem ) Indításkor nem a hagyományos boot-képernyőt látjuk, hanem a Virtual PC-nek a Starting... ablakát, valamint a tálcán is az indulás állapotát tudjuk követni.

Néhány technikai információ, ami még közben összegyűlt. Az integrációhoz használt fiókot két registry-érték tárolja, mindkettőnek UsernameHint a neve, helyük:

HKCU\Software\Microsoft\Terminal Server Client\Servers\FQDN

HKCU\Software\Microsoft\Virtual PC\Servers\FQDN:FQDN

Itt értelemszerűen az FQDN a tartományba léptetett virtuális gépek nevét jelenti, munkacsoport esetén a gép Netbios neve. A felajánlott fiók a második registry-kulcsban van.

Ja, s hogy nekem miért nem akart működni? Mert a virtuális teszt-gépemen telepítve volt a ThinStuff terméke, a Thinstuff XP/VS Terminal Server egyik próbaverziója – ami TS-t „varázsol” egy hétköznapi XP-ből is, de cserébe már a „konzol” is TS-menetnek számít, s nem tud együttműködni a VPC integrációs eszközeivel...