Maximum és minimum: Longhorn Server Core

Az alábbi cikk előzetes a Microsoft TechNet Magazin következő számából, a szerző szíves engedélyével.

A Longhorn Server család a szokásos Standard, Enterprise és egyéb verziók mellett egy különleges változatot is tartalmaz majd, amelynek neve jelenleg Server Core. A különlegessége elsősorban abból áll, hogy 95 százalékban parancssorból működik, azaz egyáltalán nincs GUI. Elsőre ez biztosan meghökkentőnek tűnik, de működik, és nem is akárhogyan.

Előnyök és hátrányok

Nézzük sorban, milyen előnyei vannak egy ilyen kiszolgáló verziónak:

• A erőforrások szempontjából lényegesen gyengébb gépen is jól működik. A tesztjeink során kiderült pl. hogy egy virtuális gépben 80 megabájt RAM-mal már egy kényelmesen felszerelt tagkiszolgáló is működtethető, 128 megabájt memóriával pedig egy full extrás tartományvezérlő is tökéletesen jól teljesít. Ha igazi vasról van szó, hasonló a helyzet, annak ellenére hogy -- szintén a tapasztalatok alapján -- ilyenkor kicsit több erő kell. De nem sokkal, az ajánlás szerint 256 MB RAM elég a teljes funkcionalitáshoz. Ide tartozik a lemezhely igény is, ami az alaptelepítés után a pagefile nélkül valóban nem több, mint 6 GB (és ebben benne van a majdnem 3 GB-nyi, kompatibilitási okokból az alkalmazások számára fenntartott WindowsWinsxs mappa tartalma is).
• Számos kiszolgáló feladatkört képes ellátni a Server Core (erről később), de lényegesen kevesebbet mint pl. egy tipikus Longhorn Server. Ezenkívül nem lehet akármit rátelepíteni, azaz léteznek a belső és a 3rd party programok területén is kemény korlátok. A "kevesebb jobb" elv alapján ez nyilván sok környezetben nagyon fontos lesz, hiszen itt szintén nem kevés üzemeltetési időt takaríthatunk meg.
• Becslések szerint körülbelül 60 százalékkal kevesebbet kell a biztonsági és egyéb javításokkal törődnünk ha nincs GUI és nincs az ehhez szorosan kötődő rengeteg alkalmazás. Ez nyilván azt is jelenti, hogy kevesebbet kell ezzel a kiszolgálóval foglalkozni a beüzemelés után ("ott lehet hagyni a sarokban"), és nincs annyi újraindítás sem.
• A telepítés utáni indító konfigurálás (pl. TCP/IP, gépnév megváltoztatása, stb.) mindenképpen a parancssorból történik, de ezután minimum három féle módszerrel vagyunk képesek távolból is felügyelni, üzemeltetni a Server Core-t. Használhatjuk az MMC-t, az RDP-t és a Vistában, W2K3 R2-ben meglévő WS-Management képességet, azaz a WinRM/WinRS párost, ami gyakorlatilag távoli parancssorként működik. Tehát nem kell halálra rémülni a szerver konzolon a fekete háttér előtt villogó fehér kurzortól, léteznek módszer is a mindennapok feladatainak elvégzésére pl. a rendszergazda gépéről.
• Minden Longhorn verzióban (Standard, Enterprise) megtalálható lesz, és egyformán használható x86/x64 környezetben is.

Itt dől el minden

A teljesség és a tisztánlátás kedvéért tekintsük át a hátrányokat is, mert azért az sejthető, hogy a felsorolt előnyök számos kompromisszummal is járnak.

• Tényleg nincs GUI. Nincs Explorer, MMC, CLR, Shell, IE, Media Player, OE, RDP kliens, stb. El kell gondolkodnunk azon, hogy hogyan lehet DNS zónát telepíteni parancssorból? Hogyan lehet szintén innen felhasználót felvenni az AD-ba? Hogy csinálunk egy kivételszabályt a tűzfalban, hogyan hitelesítünk egy DHCP szervert az AD segítségével, ha nincs GUI? Még sok ilyen kérdést fel fogunk tenni magunknak a használat során, de a válasz végül mindig az, hogy lehet, csak kicsit (ritkán nagyon) bonyolultabb.
• Ami előny, az egyben hátrány is, azaz kevesebb komponens és alkalmazás működik a Server Core kiszolgálókon. Hét fő szerepkör van amelyet ellát(hat): DHCP, DNS kiszolgáló, fájlszerver, Active Directory, Active Directory Lightweight Directory Services (AD LDS, korábban ADAM), Print Server és Media Services. Ezek mellett azért van egy tekintélyes listánk az egyéb szerepekről is: BitLocker és BitLocker Remote Admin Tool, Client for NFS, DFS Server, DFS Replication, Failover Cluster, FRS, MultipathIO, Removable Storage Management, Network Load Balancing, LPD Print Service, NFS Server, Subsystem for UNIX-based Applications, QoS (Qwave), Single Instance Storage, SNMP, Telnet Client, Windows Server Backup, WINS. Szeretném leszögezni még egyszer, hogy ez a Beta 3 körüli állapot, azaz, még változhat, például 2006 novembere óta kétszer is bővült a szolgáltatáscsomag, nem is kevés elemmel.

  Némi hátrány mutatkozik a telepítés pontosabban a frissítés és migrálás környékén is. Három fontos részletről van szó:

• Nem lehetséges egy korábbi Windows szerver verzióról frissíteni.
• Nem járható út a "nagy" Longhorn verziókról történő frissítés sem.
• A Server Core-t szintén nem lehet a "nagy" Longhornra frissíteni.

Ezekből értelemszerűen az következik, hogy a Server Core telepítés csak tiszta (clean) telepítés lehet. Hogy szépítsem a képet, jelzem, hogy egy komoly előny viszont látszik a telepítésnél, ugyanis villámgyors, 15 perc és kész vagyunk. Még egy fontos dolog: a csendes telepítés megvalósítható, a Server Core képes egy Unattend.xml alapján települni, azaz testre szabhatjuk (képernyő felbontás, RDP engedélyezése, stb.) és automatizálhatjuk a telepítést pl. a BDD 2007-tel vagy önmagában (a WAIK részeként működő) a Windows System Image Managerrel.

[oldal:Első lépések]

A telepítésben semmi extra nincs, a Vistánál és a Longhorn Servernél is tapasztalható módon alig kell hozzányúlni (a termékkulcs ugyanaz lesz, mint a nagy Longhornnál).

A Server Core-ból ennyi látszik a belépés után

Ha kész, az újfajta egész képernyős belépési képernyőt láthatjuk. Tudnunk kell, hogy egyetlen működő felhasználói fiók van csak (ez az Administrator, persze van még egy, a Guest, de szokás szerint letiltva) és ennek sincs még jelszava. Ha belépünk, a következő (néhányunk számára elsőre valószínűleg lelombozó) látvány tárul a szemünk elé. Az első teendők közé tartozik tehát az admin jelszó megadása, amelyhez a legkézenfekvőbb módszer a CTRL+ALT+DEL, és ekkor azért némi vigasz gyanánt kaphatunk némi grafikus felületet, ahol a jelszóváltoztatáson kívül ki is léphetünk vagy lezárhatjuk a gépet illetve elindíthatjuk a Task Managert is. A gép újraindításához és leállításához is ide vezet az utunk.

A mini Start menü (majdnem ugyanaz mint a Vistánál)

Egyébként csak a teljesség kedvéért a jelszóváltoztatáshoz a net user administrator * parancs is megfelelő. De vajon mi a következő lépés? Eltaláltuk: a TCP/IP bekonfigurálása. Persze ha van DHCP és megfelel nekünk, akkor nincs probléma, de kiszolgálóknál ez nem így szokás, úgyhogy jöhet a manuális beállítás, de először tájékozódjunk:

netsh interface ipv4 show interfaces

Ez azért is különösen fontos most, mert az eredményből több adatot is hasznosítani fogunk a későbbiekben, pl. az adott hálózati kapcsolat pontos nevét, és a sorszámát. Ezután jöhet a tényleges konfigurálás:

netsh interface ipv4 set address name=2 source=static
 address=x.x.x.x mask=x.x.x.x gateway=x.x.x.x

(A Name utáni sorszám a hálózati kapcsolat sorszáma az előbbi listából az Idx oszlop alól.)

Persze, vissza is állíthatjuk bármikor a DHCP-t:

netsh interface ipv4 set address name=2 source=dhcp

A DNS kiszolgáló beállítása kulcsfontosságú feladat:

netsh interface ipv4 add dnsserver name=2 address=x.x.x.x index=1

(Mivel több DNS szerver is felvehető, az index adja meg a használandó DNS szerverek sorrendjét.)

A telepítés közben a szokásos véletlenszerűen kiválasztott, hiperérthetetlen nevet kapja a gép, ebbe a folyamatba közben nem avatkozhatunk bele, utólag viszont igen, mégpedig az ismerős netdom paranccsal:

netdom renamecomputer GepMostaniNeve /newname:GepUjNeve

Felmerülhet a kérdés: hogyan derítjük ki a gép jelenlegi nevét? Nos, a legelső alkalommal utána kellett néznem nekem is, de aztán kiderült, hogy a "hostname" parancs működik itt is, sőt a "set c" és a "systeminfo" is.

Ha letöltjük a Beta 3 publikus verzióját, akkor azzal is szembesülni fogunk, hogy aktiválásra szorul. Erre mostanság nem is kapunk túlságosan sok időt, a Longhorn szervernél például 3 napunk van, szóval tartozzon ez is az első lépések közé, mert „késő bánat, eb gondolat”. A szükséges parancs:

Cscript c:windowssystem32slmgr.vbs -ato

Ha kiadjuk, kb. 1-2 percig nem történik az égvilágon semmi látható, majd ezután diszkréten közli egy apró panelen, hogy sikerült. Egyébként az aktiválás állapotának kiderítéséhez a következő parancsra lesz szükség:

Cscript c:windowssystem32slmgr.vbs -xpr

Mint szinte minden lépésnél, itt is van lehetőség távoli végrehajtásra, egy másik gépről:

Cscript c:windowssystem32slmgr.vbs gépneveadministrator jelszó -ato

Ha nem a Server Core lesz a tartományunk alapköve, hanem egy létezőbe szeretnénk beléptetni, akkor még az elején célszerű gondoskodni erről, mivel a felügyelet (pl. WinRM) is feltétele ennek vagy ha nem, akkor is sokkal egyszerűbb a megoldás (pl. MMC). Ehhez gépeljük be a következőt parancsot:

netdom join gépnév /domain:domain_név /userd:user_neve /passwordd:*

Ennyi. Nincs újraindítás, röpke pár másodperc után a gép a tartomány tagja. A user_neve természetesen egy olyan felhasználói fiók amelynek van megfelelő jogosultsága a gépet a tartományba beléptetni, a passwordd* pedig nem elírás, a csillag hatására kéri be a jelszót. Természetesen a Domain Admins csoport automatikusan tagja lesz a helyi Administrators csoportnak a tartományba léptetés után, de ha mégis szükségünk lesz egy tartományi felhasználó helyi admin csoportba helyezésére, használjuk ezt a parancsot:

Net localgroup administrators /add domain_neveuser_neve

A csoportokat tekintve nincs sok különbség a "nagy" Longhorn szerverhez képest

[oldal:Ellenőrzés és felügyelet]

Mint ahogyan már említettem, a felügyelet ellátható távolból három különböző módszerrel is, és igazából célszerű is ez, hiszen helyi eszköz viszonylag kevés van. A három módszer közül az egyik az RDP kapcsolat, amelyet először engedélyezni kell a kiszolgálón:

cscript C:WindowsSystem32Scregedit.wsf /ar 0

De van itt egy kis trükk is, mert ez az engedélyezés az RDP 6.0-ás kliensekre vonatkozik csak (Vistán alapból ez van, XPSP2-re letölthető), ha régebbi RDP kliensről óhajtjuk kezelni, akkor:

cscript C:WindowsSystem32Scregedit.wsf /cs 0

Ezután csont nélkül működik, ami azért is jó, mert pl. a vágólapon keresztül is letámadhatjuk a Server Core-t a megfelelő kötegelt vagy egyszeri parancsokkal. Egy másik módszer az MMC-n keresztüli elérés, amely azonos tartományban, megfelelő jogosultsággal semmi extra tudást nem igényel.

Így néz ki a Server Core Computer Management MMC-je egy Vistáról

A képről az is kiderül, hogy az újfajta a Vistában már megismert Event Viewer, Task Scheduler vagy Performance Monitor képességeket korlátozás nélkül használhatjuk a Server Core esetén is. Ha viszont nem azonos tartományban vagyunk a kiszolgálóval, akkor elsőként szükség lesz erre a parancsra, ahhoz, hogy ne egy Access Denied sorozatba fussunk bele:

Net use * \szerver_nevec$ /u:user_neve

A harmadik módszerhez a Windows Remote Management / Windows Remote Shell használatához viszont célszerű azonos tartományban lenni a Server Core kiszolgálóval, hiszen ekkor könnyedén használhatjuk pl. a Kerberos-t a hitelesítésre, ami egyúttal az alapértelmezés is. De mi is igazából ez a páros? A Windows RM komponens része a Windows Hardware Management szolgáltatásnak, mellyel teljes körűen irányíthatjuk helyből vagy távolból a kiszolgálót. A szolgáltatás a WS-Management protokoll használja, hardveres diagnosztikát és ellenőrzést tesz lehetővé, és emellett a kiszolgáló szoftveres távvezérlésére is alkalmas a parancssorból.

A csatlakozás tűzfalbarát módon (pl. http vagy https), biztonságos körülmények között történhet meg, és persze többféle hitelesítési módszert (Basic, Digest, Kerberos) is alkalmazhatunk. Sokan úgy gondolják, hogy ez a megoldás csak a Vistákkal és a Longhorn kiszolgálókkal működik, pedig nem, a Windows Server 2003 R2-ben is benne van ez a komponens, csak telepíteni kell. Más kérdés, hogy egy R2 WinRM listener (a szerver oldali „figyelő”) beállítása igen bonyolult lett, de azért használható. A Longhorn kiszolgálók és a Vista esetén viszont egyszerű az élet, a következő paranccsal indíthatjuk a szerver oldalon a szolgáltatás beállítását:

WinRM quickconfig

Ezzel a paranccsal elindítjuk és automatikus indításúra tesszük a WinRM szolgáltatást, beállítjuk a HTTP listener-t a WS-Management protokoll üzeneteinek fogadására és küldésére, valamint létrehozunk egy tűzfal kivétel szabályt (TCP 3190) a WinRM szolgáltatás részére. És ennyi! Ellenőrzés gyanánt győződjünk meg az alapértelmezett hitelesítés típusáról:

winrm get winrm/config/service

Példaként nézzünk meg néhány további parancsot. A Server Core rendszerpartíciója tartalmának listázásához a következő utasítást adjuk ki mondjuk egy Vista kliensről:

winrs -r:http://szerver_neve dir c:

A kiszolgáló újraindításához pedig gépeljük be ezt:

winrs -r:http:// szerver_neve shutdown -r

Visszatérve felügyelet témakör elejére, meg kell említeni még egy-két helyben is használható eszközt is. Ide tartozik két Control Panel elem, amelyek megmaradtak a Server Core-ban is. Az idő/dátum beállítására a control timedate.cpl, a területi beállításokra pedig a control intl.cpl. Ezeknél talán sokkal fontosabb viszont az az alkalmazás, amely egyaránt megtalálható minden Vistán és Longhorn kiszolgálón is, azaz a Eseménynapló parancssoros változata, a WevtUtil, amellyel láthatóan mindent el lehet érni, amit a GUI-s változattal.

A WevtUtil parancsai és paraméterei

[oldal:Szerepkörök, komponensek telepítése]

Fontos kérdés, hogy hogyan tudunk alkalmazásokat és komponenseket telepíteni, illetve hogy melyek állnak rendelkezésünkre akár rögvest a telepítés után, azaz melyeket kell gyakorlatilag csak élesíteni? A fontosságuk szerint két részre szedett listát a cikk elején már láthattuk, most viszont az is kiderül, hogy a parancs gyakorlatilag ugyanaz mindkét csoportnál, azaz a

start /w Ocsetup 

utasítás után a megfelelő szerepkör vagy komponens neve jön, a különbség maximum annyi, hogy a komolyabb szerepkörök nevei hosszabbak, pl. DNS-Server-Core-Role, vagy File-Server-Core-Role és így tovább. Nagy segítségünkre lehet viszont az "Oclist" nevezetű parancs annak eldöntésére, hogy mi a szerepkörök pontos neve, illetve hogy melyeket telepítettük már fel. A következő képen szépen látszik, hogy ez egy friss Server Core, egyedül a mentés komponenst telepítettem fel.

Az Oclist egy rendkívül hasznos parancs (a képen még nem a Beta 3 komponensei látszanak)

A szerepkörök telepítésénél figyeljünk oda a gépelésnél, mert az Ocsetup rendkívül érzékeny a kis és nagybetűk közötti különbségre. Itt és most több szó nem esik egy-egy szerepkör élesítés utáni konfigurálásáról, de például a TechNet blogon, vagy a hivatalos Server Core blogon már szó esett ezekről a lépésekről. Ehhez a részhez még annyit kell hozzátenni, hogy a "nagy" Longhorn kiszolgáló Server Managere vagy egy GUI-s távoli telepítés/eltávolítás jelenleg nem áll rendelkezésre, és a híresztelések szerint nem is lesz ilyen lehetőség a végleges termékben sem.

Van viszont egy komoly elem, amely kívül esik az Ocsetup hatókörén és egyéni törődést igényel. Az Active Directory telepítéséről van szó, amely egy nem túl egyszerű művelet, több előkészületre is szükség van hozzá. Először is, tényleg kell a fix IP, ezenkívül a séma preparálására is sort kell kerítenünk (változás nincs, maradt az adprep.exe és az ismerős kapcsolók a DVD-ről), úgyhogy csak óvatosan: ne feledjük, ez még mindig egy béta termék és a sémabővítés egy visszavonhatatlan folyamat!

Miután nem elérhető a grafikus felületű Dcpromo, muszáj az unattend módszert választani (amit egyébként a korábbi Windows kiszolgálóknál is lehetett, de kíváncsi lennék mennyien éltek/élnek ezzel a lehetőséggel? :D). Szóval össze kell kalapálnunk egy szövegfájlt, amely az ismert módon vezérelni fogja a telepítést, parancssori indítással. Egy példa egy szűkre szabott, de telepítésre tökéletesen alkalmas szövegfájlra:

[DCInstall]
AdministratorPassword = 
AllowAnonymousAccess = No
AutoConfigDNS = Yes
CreateOrJoin = Join
CriticalReplicationOnly = Yes
DisableCancelForDnsInstall = Yes
DomainNetBiosName = xxx
RebootOnSuccess = Yes
RemoveApplicationPartitions = No
ReplicaDomainDNSName = xxx.yyy
ReplicaOrNewDomain = Replica
ReplicationSourceDC = zzz.xxx.yyy
SafeModeAdminPassword = 
UserDomain = xxx.yyy
UserName = Administrator
Password =

Ezután már csak egy további teendőnk akad, az indító parancs kiadása:

Dcpromo /unattend:fájlneve.txt

A szövegfájlba felvehető paraméterekről a vonatkozó Windows Server 2003 dokumentumból tájékozódhatunk.

Egyéb alkalmazások és a meghajtóprogramok

Nem sok egyéb alkalmazásunk van az eddig említetteken kívül, de ezek közül ami fontos, az pl. a Notepad (ami csak Beta 2-ben került bele, és csak a Beta 3-ban fog működni a Save/Save As.. és az Open parancs rendesen :D), valamint pl. a Regedit.exe, ami szintén "új fiú", ugyanis eddig csak az import működött. Az Error Reporting (serverweroptin.exe) szintén rendelkezésre áll, és van egy alkalmazásunk a frissítések telepítéséhez (Wusa.exe), amely az .msu kiterjesztésű csomagokat kezeli.

Van viszont egy olyan apró, ám multifunkciós megoldásunk is, a SCRegEdit.wsf nevű szkript, amely megtalálható a WindowsSystem32-ben. A segítségével engedélyezhető az AU kliens, az RDP elérés (korábban már szó volt erről), a távoli IPSec Monitor management és pl. a DNS rekordok prioritás szabályzásához is köze van. Valamint a /cli kapcsolója az összes a Server Core-ban használható parancssori eszköz lehetőségeit kilistázza. A korábbi példákban már láthattuk is ennek a scriptnek a használatát.

Végül legyen szó egy szintén kritikus területről, azaz a driverek telepítéséről, bár a tapasztalatom szerint a hardverek felismerésével és illesztésével abszolút nincs gond. De ha mégis, akkor a következő módszer szerint járjunk el:

1. Másoljuk be a meghajtó programot egy mappába.
2. Pnputil -i -a mappa_neve.inf
3. Újraindítás (nem mindig szükséges)

A jelenlegi meghajtó programok listázásához a következő régi ismerős parancsra lesz szükség (a szóköz a "driver" előtt szándékos):

sc query type= driver

A szolgáltatások vezérléséhez szintén az sc parancs a megoldás, pl. egy szerviz indítása történhet így is:

Sc config "RemoteRegistry" start= auto

Mint látható, a Longhorn Server Core mindenképpen érdemes lesz a figyelmünkre, hiszen biztonságosságának, egyszerűségének és alacsony gépigényének köszönhetően számtalan esetben lehet, hogy ezt fogjuk választani a teljes Longhorn Server változatok telepítése helyett.

Gál Tamás
rendszermérnök
Microsoft

Véleménye van?

• szóljon hozzá a fórumban
• írjon szerkesztőségünknek!

kipróbáltuk