A blogban leírtak a szerzők saját véleménye, és nem a munkáltatójuké.
|
Ez sajnos egy elég hosszúra nyúlt folyamat volt, részben frissítettünk próbaképp egy vCenter 5.1-et, aztán közben kijött az 5.1 Update 1, akkor még egy frissítés, aztán ESXi frissítés, aztán pedig átállás a vSphere Data Protection (VDP) mentési megoldásra a korábbi VMware Data Recovery-ről (VDR).
Tapasztalatok és hasznos leírások egyes problémákról:
- A kezdeti 5.1 kiadásnál kb. minden komponens után újabb és újabb hibaüzenetek jöttek. Nem véletlenül nagyon gyorsan kijött egy 5.1a, aztán egy 5.1b. De érdemesebb inkább egyből az 5.1 Update1-et nézni, sőt, annak is van 5.1 Update 1b verziója:)
- Jó az új linux-os appliance verzió, de az Update Manager-ből még csak windowsos verzió van, úgyhogy aki azt is szeretne használni, annak kell mindenképp egy windowsos szerver is. Sőt, az új webes kliensben csak Scan-t (frissítések keresése) lehet nyomni, a Remediate (frissítések telepítése) csak a klasszikus vastagkliensből érhető el:). Gondolom majd a következő verzióra sikerült mindent átállítani az új platformra.
- Az új Single Sign-On (SSO) komponens telepítője nem tud alapból nevesített SQL-szerver példányokhoz csatlakozni, holott az eddig vCenter verziók kapásból olyat raktak fel. Így frissítésnél az marad, hogy ha használni akarjuk a meglévő SQL Server Express példányt, akkor ki kell tölteni a szerver adatait (IP-cím, port…), majd utána bepipálni, hogy a JDBC URL-t is meg akarom adni, és ott lehet a példány nevét megadni:
- Az SSO telepítés után mi belefutottunk egy nagyon aljas hibába: Error 29102.Could not contact Lookup Service.
- Van egy kapcsolódó KB (Installing or upgrading vCenter Server 5.1 fails with the error: Could not contact Lookup Service (2035965)), ami egy nagyon banális programozói hibát sejtet [ha a ‘port’ szó benne van a szerver FQDN-ben, akkor azt nem kezeli:], de nálunk nem ez volt a gond.
- A lookupservice.log fájlban ‘JDBC URL value should not be empty’ már segített, a ‘C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes\config.properties‘ beállításoknál tényleg üres volt. Beírva a telepítőben működő JDBC URL-t természetesen nem ment, java.sql.SQLException: No suitable driver found volt a hiba, pedig a JDBC jar ott volt a tomcat könyvtárában. Mindenféle log átnézése, trace üzemmódok bekapcsolása után jött a megvilágosodás: a telepítő és az SSO maga nem ugyanazt a JDBC könyvtárat használj, az SSO a http://jtds.sourceforge.net könyvtárat tartalmazza, abban pedig ez a formátum:
- jdbc:jtds:sqlserver:<server>[:<port>]<database>[;<property>=<value>
- Elment vele némi idő, szeretjük az ilyen sok komponensből integrált termékeket:)
- Az SSO-nál még annyit, hogy aljas módon van egy admin felhasználó, akinek jelszót kell adni a telepítéskor, de azt nem írja ki, hogy ez a jelszó lesz az SSO master password, amivel később pl. ki lehet ütni az admin jelszavát, ha nem tudunk vele belépni. Az admin jelszavának változtatásakor viszont a master password nem változik. Az admin jelszót később még ki lehet ütni az adatbázisban tárolt hash átírásával (lásd: vCenter Single Sign On master password, alul), de ha a master passwordöt nem tudjuk, akkor csak az újratelepítés segít (lásd pl. Upgrading vCentre 5.1 SSO – Password Confusion).
- Gondoltam a sikeres telepítést még megkoronázzuk azzal, hogy lecseréljük szokásos módon az alap tanúsítványokat, erre most már van egy segédeszköz is: Deploying and using the SSL Certificate Automation Tool (2041600). Azonban minden komponensnek (SSO, Inventory Service, vCenter Server, Web Client, Update Manager) különböző tanúsítvány kell, mert az alapján azonosítják egymást, ezért mindet külön kell kiállítani, majd lecserélni, majd a kölcsönös bizalmi kapcsolatokat újrakonfigurálni, úgyhogy ez most már nem egy 10 perces munka:( [a korábbi verziókban csak 1-1 fájlt kellett lecserélni és újraindítani az egészet].
- Az Update Manager esetén meglepő módon nem volt gond.
- Az ESXi-k frissítése is lement, egy vicces mozzanat azért van. Update Managerrel frissítve szépen látszik, hogy berakja Maintenance mode-ba, elkezdődik a telepítés, újraindítja, majd vár, vár, vár még mindig vár, és nem jön fel az ESXi. Még szerencse, hogy volt remote console beállítva, így látszik, hogy a szerver ezt csinálta épp. Azaz szépen még egy Enter-re vár, ahelyett, hogy újraindulna:)
- Az eddigiek azonban eltörpülnek a vSphere Data Protection telepítése és beüzemelése mellett. Szerencsére nem csak nekem volt ilyen érzésem (vDP – Sick of being a beta tester, itt kicsit elszabadultak az indulatok:). Nálam a fő probléma az volt, hogy a telepítés után az első kézzel indított mentés sikeres volt, majd az esti automatikus mentés már leállt ilyen hibával: ‘VDP: Miscellaneous error‘. Erre is van KB (Backup job fails for all virtual machines after vSphere Data Protection 5.1 deployment (2038597)), de nem ez volt nálunk a gond. Van egy régi Avamar-os hiba is (https://community.emc.com/thread/101335?start=15&tstart=0), de az sem segített. Log bundle átnézése, Wiresharkkal forgalom figyelése, sokszori próbálkozás után végül megfogadtam az itt található tanácsot: “if all else fails, reboot (the VDP appliance)”! Az első újraindítás órákig tartott, teljesen reménytelen volt, hogy egyáltalán elindul újra, de aztán jobbára talpraállt. Ekkor már másik hibát dobott (VDP: Failed to initiate a backup or restore for a virtual machine. Probable cause is the datastore for the virtual machine is not accessible.), holott látta minden host az összes datastore-t, így kapott végül másnap is egy újraindítást, és most nem akarom elkiabálni, de lefutott az automatikus mentés is:)
Hát egyelőre ezek a tapasztalatok az 5.1-es kiadással. Jó funkciók kerültek bele, meg messzire mutató az architektúra- és platformváltás, de azért nem volt egy végleges release érzésem:)
Az egyik laborunkban feladatátvételi fürtöket próbálnak ki a hallgatók a gyakorlatban, ehhez a megvalósítást a Windows Serverben elérhető Failover Clustering funkció adja. Idén Windows Server 2012-t használunk már, de ehhez a teljes virtuális gépekből álló környezetet újra össze kellett építeni. Ha már úgyis az új szervert használjuk, akkor gondoltam kipróbálom a Server Core opciót: tehát nincs GUI, csak PowerShell segítségével végezzük el a beállításokat. Elvileg most már a feladatok nagy részét meg lehet így is oldani, lássuk milyen lett az új Server Core. Tehát a kihívás a következő: a fürt létrehozása előtti alap beállításokat csak PowerShell parancsok segítségével lehet elvégezni.
Öt darab virtuális gépre volt szükség: egy tartományvezérlő (DC), egy közös tárhelyet biztosító iSCSI kiszolgáló és három darab csomópont a fürthöz.
Pár lépést elvégeztem a közös ősként szolgáló virtuális gépen:
# Remove unnecessary features, features can be completly removed with Features on Demand
Uninstall-WindowsFeature -Remove -IncludeManagementTools -Name AD-Certificate, ADLDS, ADRMS, Hyper-V, Print-Services, RemoteAccess, Remote-Desktop-Services, VolumeActivation, Web-Server, UpdateServices, BitLocker, BranchCache, NFS-Client, Data-Center-Bridging, GPMC, ManagementOdata, Server-Media-Foundation, MSMQ, qWave, RSAT, SNMP-Service, Subsystem-UNIX-Apps, Telnet-Client, WFF, Windows-Server-Backup, Migration
# run windows update
wuauclt /detectnow
#set date & time
Control timedate.cpl
# download PowerShell help
Update-Help
# set administrator password: no expiration
Get-CimInstance -ClassName Win32_UserAccount -Filter "name = 'Administrator'" | Set-CimInstance -Property @{PasswordExpires="False"}
#disable automatic activation
cd "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform"
Set-ItemProperty .\Activation -Name Manual -Value 1
# allow incoming IPv4 echo request (ping)
Set-NetFirewallRule -Name FPS-ICMP4-ERQ-In -Enabled True
A következő lépés a tartományvezérlő beállítása:
# NOTE: if using linked clone virtual machines, the SID of the machine used as the DC should be changed,
# because the domain will get that SID for the domain SID, and hence the other machines would not be
# able to join the domain throwing an ERROR_DOMAIN_SID_SAME_AS_LOCAL_WORKSTATION error
Rename-Computer -NewName DC1
Restart-Computer
# rename network adapter
Get-NetAdapter | Rename-NetAdapter -NewName lan
# disable IPv6
Set-NetAdapterBinding -Name "lan" -ComponentID ms_tcpip6 -Enabled $False
# add new static IP address
New-NetIPAddress -InterfaceAlias lan -AddressFamily IPv4 -PrefixLength 24 -IPAddress 192.168.170.11
# set local server for DNS server for LAN adapter
Set-DnsClientServerAddress -InterfaceAlias lan -ServerAddresses "127.0.0.1"
# get the index of the install image of the Standard/Datacenter version in the wim
# use this index with feature install, in this example the index is 1
Get-WindowsImage -ImagePath D:\sources\install.wim
# install the binaries for AD DS
Install-WindowsFeature -Name AD-Domain-Services -Source wim:D:\sources\install.wim:1
# install the DNS feature as it will be used
Install-WindowsFeature -Name DNS -Source wim:D:\sources\install.wim:1
# install a new AD forest and a domain in it, this will prompt for AD restore password
Install-ADDSForest -DomainName clusterdemo.local -ForestMode Win2012 -InstallDns:$True –NoRebootOnCompletion:$True -CreateDnsDelegation:$false
Restart-Server
# after restart, test that DNS install was successfull
Get-DnsServerZone clusterdemo.local | Get-DnsServerResourceRecord
# create an AD integrated reverse lookup zone
Add-DnsServerPrimaryZone -ReplicationScope Domain -NetworkId "192.168.170/24" -DynamicUpdate Secure
# add a new PTR record in the zone
Add-DnsServerResourceRecordPtr -ZoneName "170.168.192.in-addr.arpa" -Name 10 -PtrDomainName "dc1.clusterdemo.local"
Ezután jöhetnek a fürt csomópontjai (ezeknek három darab hálózati kártyájuk van, egy a DC felé, egy a közös tárhely felé és egy belső kapcsolat a fürttagok között):
# the nodes are called FC-NODE1, FC-NODE2, FC-NODE3, substitute X with the actual number
Rename-Computer FC-NODEX
Restart-Computer
# set networking
# create a net.csv file with the network settings
Write-Output "oldname,newname,ip" > net.csv
Write-Output "Ethernet,lan,192.168.170.2X" >> net.csv
Write-Output "Ethernet 3,private,192.168.100.2X" >> net.csv
Write-Output "Ethernet 2,storage,192.168.50.2X" >> net.csv
# set names and addresses
Import-Csv .\net.csv | % {Rename-NetAdapter -NewName $_.newname -Name $_.oldname; New-NetIPAddress -InterfaceAlias $_.newname -IPAddress $_.ip -AddressFamily IPv4 -PrefixLength 24; Set-NetAdapterBinding -Name $_.newname -ComponentID ms_tcpip6 -Enabled $False}
# Set DC1 as the DNS server
Set-DnsClientServerAddress -InterfaceAlias lan -ServerAddresses "192.168.170.11"
# disable Teredo tunneling pseudo-interface
Get-NetAdapter –InterfaceAlias "Teredo Tunneling Pseudo-Interface" -IncludeHidden | Disable-NetAdapter
# add failover clustering feature
Install-WindowsFeature -Name Failover-Clustering -Source wim:D:\sources\install.wim:1
# Add file server role, which will be later needed
Install-WindowsFeature FS-FileServer -Source wim:D:\sources\install.wim:1
# start the iSCSI Initiator service
Set-Service -Name msiscsi -StartupType Automatic
Start-Service msiscsi
# enable firewall rules for iSCSI Initiator
Get-NetFirewallRule -DisplayGroup "iSCSI Service" | Set-NetFirewallRule -Enabled True
# join to domain
Add-Computer -DomainCredential clusterdemo\administrator -DomainName clusterdemo.local
És már készen is áll a rendszerünk a fürt telepítésére:). Most már csak legközelebb az egészet automatizálni kéne PowerShell workflow formájában…
A CIM/WMI témák lezárásaként idén még egy kérdés került elő. Jó-jó, hogy a CIM szabvány dokumentumai között vannak grafikus modellek az egyes osztályok tulajdonságainak és kapcsolatainak ábrázolásáról, de mi a helyzet, ha én a WMI-specifikus osztályokat szeretném megnézni. Az MSDN oldalán (WMI Classes) van egy hierarchikus, szöveges összefoglaló arról, hogy milyen Win32 kezdetű osztályok vannak, de ebben pont az összefüggéseket nem lehet jól látni. Meglepő módon nem találtam erről semmi ábrát, de szerencsére ezt nem olyan nehéz elkészíteni.
A feladat tulajdonképpen a kapcsolóosztályok (association classes) adatainak lekérdezése, majd ezek grafikus megjelenítése. Tulajdonképpen egyszerű, irányítatlan gráfok felrajzolásáról van szó. Erre egy könnyen használható eszköz a Grapviz. Ennek rengeteg paraméterezése meg felhasználási módja van, de legegyszerűbb esetben valami hasonlót kell megírni:
graph WMIAssociations {
Win32_Class1;
Win32_Class2;
Win32_Class1 -- Win32_Class2 [label = "Win32_Association1" ];
}
Tehát fel kell sorolni a gráf csomópontjait (= WMI osztályok) és a gráf éleit (= kapcsolóosztályok). A kapcsolóosztályokról általában ilyen adatokat tárol a WMI:
> Get-CimClass Win32_SystemProcesses | fl
CimClassName : Win32_SystemProcesses
CimSuperClass : ROOT/cimv2:CIM_SystemComponent
CimClassProperties : {GroupComponent, PartComponent}
CimClassQualifiers : {Aggregation, Association, Locale, UUID...}
...
(Megjegyzés: a lekérdezésekhez már a PowerShell 3.0-ban megjelent új CIM cmdleteket használom.)
Egy adott tulajdonságnál a Reference típus jelzi, hogy ez egy hivatkozás egy másik osztályra:
> (Get-CimClass Win32_SystemProcesses).CimClassProperties
Name : GroupComponent
Value :
CimType : Reference
Flags : Property, Key, ReadOnly, NullValue
Qualifiers : {Aggregate, read, key, MappingStrings...}
ReferenceClassName : Win32_ComputerSystem
...
Ezek alapján tehát azokat az osztályokat keressük, amik meg vannak jelölve az Association minősítővel, majd ezeknek a Reference típusú tulajdonságait kell összegyűjteni. Ezt például a következő PowerShell lekérdezéssel lehet megtenni:
Get-CimClass | ? {($_.CimClassName -like "Win32_*") -and !($_.CimClassName -like "Win32_Perf*") -and (($_.CimClassQualifiers | ? {$_.Name -eq "Association"}) -ne $null) } |
Sort-Object | % {$s = $_.CimClassName; $_.CimClassProperties | ? {$_.CimType -eq "Reference"} | % { $s += ",$($_.ReferenceClassName)" }; Write-Output "$s" } > association_classes.csv
Megjegyzés: nem kerültek bele a listába a teljesítményszámlálóknak megfelelő Win32_Perf* osztályok.
Az így kapott listából már könnyű összeállítani a Grapviznek szükséges szöveges fájlt. Ha utána ebből képet generálunk, akkor valami hasonló gráfot fogunk kapni:
 Kapcsolatok WMI osztályok között (részlet) Az egész ábra elég nagy lett, de arra jó, hogy ha valaki egy adott osztály kapcsolatait akarja gyorsan megkeresni, vagy pedig szeretné megnézni, hogy mik a nagyobb összekapcsolódó csoportok.
Egy Windows 8.1 + PowerShell 4.0 gépen lefuttatva így néz ki az egész gráf:
 Kapcsolatok WMI osztályok között (root/cimv2 névtér) Jó böngészést!
Summary: The above figure was generated with a few lines of PowerShell and Graphviz. It shows the associations between WMI classes, and visualizes the connections between the different Win32_* classes. Click on the above figure for a more detailed view!
Csak gyorsan: még egy példa hiányzott az IRF segédletünkből, mégpedig az, amikor Linux platformon az openwsman+sfcb programoktól kapcsolódó osztályokat kérdezünk le WS-Management segítségével. PowerShellben ez ment, sőt a linuxos wsman kliens is le tudott kérdezni távoli Windows gépet.
Viszont amikor wsman klienssel kérdeztem le az openwsman szervert, nem akart összejönni:
wsman -d 6 -R -h localhost -u meres -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter=http://schemas.dmtf.org/wbem/wscim/1/CIM_ComputerSystem
Segmentation fault (core dumped)
Itt nem voltak kiválasztók (selector) megadva, és az epr_from_string metódusban, ami ezt feldolgozza, nincs hibakezelés. Ezért lett segmentation fault.
Próbáljuk megadni konkrét példányt:
wsman -R -h localhost -u root -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter='http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem?CreationClassName="CIM_ComputerSystem",Name="irfserver.irf.local"'
Ekkor meg a következő hibát dobta:
<s:Value>wsa:DestinationUnreachable</s:Value>
<s:Text xml:lang="en">Provider not found or not loadable</s:Text>
Gondoltam az elnevezéssel lesz gond. WinRM esetén ez a helyes:
Get-WSManInstance -ComputerName 192.168.21.151 -ResourceURI wmicimv2/* -Dialect Association -Filter "{object=Win32_LogicalDisk?deviceid=C:}" -Enumerate -Credential meres -Associations
Viszont, hogy wsmancli+openwsman esetén mi a jó, azt nem olyan egyszerű megtudni. Egy régi levél van ilyen témában (How to get association instance using wsmancli), viszont az ott leírtak nekem nem működtek most a wsman 2.2.7.1 és openwsman 2.3 esetén.
Ilyen kor jön akkor, hogy a DMTF és SBLIM névterek tetszőleges kombinációját végigpróbálja az ember. Elég frusztráló volt, mert a wsman get művelet ment egy adott kombinációval, viszont az associators meg nem:(
Volt a végén ilyen elkeseredett próbálkozás is:
wsman -R -h localhost -u root -p LaborImage associators 'http://sblim.sf.net/wbem/wscim/1/*' --filter='http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem?CreationClassName="Linux_ComputerSystem",Name="irfserver.irf.local"'
Connection failed. response code = 503
Ez nyilván nem jó, mert sblim-es all class URI nincs (a /* az all class).
A wsman által összeállított XML látszólag jó volt, a WS-Management CIM Binding specifikációban leírtaknak megfelelt. Az openwsman ezt írta ki (ez már egy megint másik próbálkozás, kerestem olyan osztályt, ahol nem kulcs a CreationClassName):
Apr 2 22:13:03 [7436] ObjectPath: root/cimv2:Linux_RpmPackage.SoftwareElementState="2",Name="matahari-broker",TargetOperatingSystem="36",Version="0.4.4",SoftwareElementID="matahari-broker"
Apr 2 22:13:03 [7436] enumInstances() rc=6, msg=Provider not found or not loadable
Apr 2 22:13:03 [7436] *** CMCIClient enumInstances() failed
Irány a gdb, meddig jut el. A gond az volt, hogy szépen végigment a cim_enum_instances metóduson (ahol korábban probléma volt), és el is küldte az sfcc segítségével a CIMOM-nak az üzenetet.
Nézzük akkor a CIMOM-ot. Előtérben elindítva az sfcbd-t végre volt egy értelmes hibaüzenet:
--- Caching ClassProvider for /var/lib/sfcb/registration/repository/root/cimv2/classSchemas (1.0-3) using 7756 bytes
--- Caching ClassProvider for /var/lib/sfcb/registration/repository/root/interop/classSchemas (1.0-3) using 1204 bytes
loading libcimrpmv4.so
*** dlopen: /usr/lib/cmpi/libcmpiLinux_SambaAdminUsersForGlobal.so error: /usr/lib/cmpi/libcmpiLinux_SambaUser.so: undefined symbol: _ZN12CmpiInstance16getPropertyCountEv
*** Failed to load libcmpiLinux_SambaAdminUsersForGlobal.so for CmpiLinux_SambaAdminUsersForGlobalProvider
--- closeProviderContext not touching sem 53; already zero
Tehát nem a wsman-ban, nem az openwsman-ban van a hiba, hanem maga a CIMOM a rossz! De miért zavar minket a Samba provider, és ez eddig miért nem jött elő? Jobban belegondolva jogos, hisz eddig nem kérdeztem le a SambaAdminUsersForGlobal osztály példányait, viszont a kapcsolatok lekérdezésekor az összes kapcsolóosztályt be kell járni, többek között ezt is. A rendszerben viszont voltak hibás kapcsolóosztályok, így a CIMOM hibát jelzett.
Megoldás: nem volt kedvem már sblim-cmpi providereket debuggolni, úgyhogy kiszedtem a CIMOM-ból ezeket (az sfcb repository-ból kell kitörölni a kapcsolódó MOF fájlokat és provider regisztrációs állományokat, majd újraépíteni a repositoryt). Ezután már az Rpm provider volt a hibás. Kitöröltem. Utána a Dhcp. Kitöröltem. Utána a DNS. Kitöröltem. Ezután végre ment a lekérdezés. A fura az, hogy ezek a providereket a hivatalos yum repositoryból raktuk fel, ez van elvileg CentOS 6.2-höz. Jó lenne megnézni, hogy mi volt a gond velük, de már így is sokkal több idő elment ezzel, mint kellett volna.
Akkor a helyes lekérdezés:
# this is working and it should be
wsman -h localhost -u meres -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter 'http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem?Name="irfserver.irf.local",CreationClassName=Linux_ComputerSystem'
Jó lenne csak DMTF névtereket használni, mint a fenti levélben is van, viszont az nem ment nekem:
# this should work, but it returns actually an empty sequence of items
wsman -R -h localhost -u root -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter='http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem?CreationClassName="Linux_ComputerSystem",Name="irfserver.irf.local"'
Ez lefut, viszont üres eredményhalmazzal tér vissza. Pedig a get megy erre a ResourceURI-ra.
Ami viszont még meglepőbb:
# this works currently, altough it should not be, because there is a namespace mismatch in it
wsman -R -h localhost -u root -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter='http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem?CreationClassName="Linux_ComputerSystem",Name="irfserver.irf.local"'
Ennek viszont nem kéne menni, mert DMTF névtérben hivatkozunk Linux sémájú osztályra. Nem is megy a get ezzel az URI-val (eredmény: InvalidResourceURI).
Viszont legalább annyival zárhatom a napot, hogy most már volt sikeresen lefutó associators lekérdezés.
SUMMARY: If you get the ‘Provider not found or not loadable‘ error with an associators query, then check your CIMOM, maybe the error is there and not in openwsman (as in my case: some association classes and providers were not working in sfcbd).
Az IRF második házi feladatára készülve szokás szerint megnéztem a kapcsolódó eszközök aktuális verzióját, bővítgettem a segédletet különböző lekérdezésekkel. Közben sikerült azért sajnos jó pár hibába belefutnom. Ezek között voltak kisebbek (nem implementált kapcsoló, jelszó kiírása a log fájlba), de volt három érdekes is.
Enumeration with selector filter returning only one instance: Selector dialektust használó szűrés esetén csak egy példányt adott vissza a lekérdezés, közben pedig volt több is, ami megfelelt a feltételnek. Kikeresve a kódban a megfelelő részt viszonylag gyorsan megtalálható a probléma: az eredményeket tároló tömb feltöltésekor az indexet elfelejtették növelni.
Segmentation fault when the selector filter contains comma: a következő már trükkösebb volt. Ha Selector dialektust használó szűrőfeltételben vessző volt, akkor segmentation fault lett az eredmény. Kicsit hosszabb volt végigkövetni a hívási láncot, itt már a gdb segített. A probléma az, hogy nem ellenőrzi a kód az URI feldolgozásának eredményét, és null visszatérési érték esetén is simán továbbmegy.
Core dump when using XPath filter with SfcbLocal frontend: a szűrőfeltételt lehet elvileg XPath lekérdezéssel is megfogalmazni, de erre sajnos nincs túl sok példa. Már nagyjából az első próbálkozásom is segmentation faultot okozott:). Irány a gdb, stack trace, lekérdezés adatait tároló struktúra kiíratása, eszerint a lekérdezést WQL dialektusban adtuk meg. Fejvakarás, elküldött wsman XML nézegetése, forrás vizsgálata. Kiderült, hogy rosszul állítja be az alapesetet a kód, ráadásul az XPath lekérdezés nincs is implementálva.
Küldtem módosításokat, remélhetőleg a következő verzióban már ezek javítva lesznek.
A hibáknál sokat segít, ha van debug információ is az adott programokhoz. Ha a hivatalos csomagokat raktuk fel, akkor a CentOS-hez tartozó debuginfo csomagokat is szedjük le. Ehhez létre kell hozni egy debuginfo.repo nevű fájlt a /etc/yum.repo.d/ könyvtárban a következő tartalommal:
[debuginfo]
name=CentOS-$releasever - DebugInfo
baseurl=http://debuginfo.centos.org/$releasever/$basearch/
gpgcheck=0
enabled=1
Ha az opensuse build szerveréről raktunk fel frissebb verziót a programokból, akkor pedig onnan a debug szót tartalmazó verziókat kell felrakni.
Az előzőekben leírtak alapján sikerült egy Active Directoryt feltölteni tesztadatokkal. A házi feladatok egy része viszont Linux alatt, bash szkriptekkel openLDAP szerver használatáról szól, így szükségünk volt ehhez is tesztadatokra.
Az elképzelt munkafolyamat úgy nézett ki, hogy elkészítjük a felhasználókat CSV-ben, azt importáljuk csvde-vel az Active Directoryba, majd ldifde-vel az adatokat exportáljuk, végül ezt betöltjük ldapadd-dal. A máskülönben csodás tervbe ott csúszott hiba, hogy az AD-ból kiexportált adatok kissé zajosak, rengeteg olyan adat került bele, amit az ldapadd nem hajlandó kezelni.
Sebaj, nem véletlen tanulnak a hallgatók IRF keretében szkriptelést: egy kis bash-mágia és máris kész lesz a megtisztított, ldapadd által emészthető bemenet. Néhány óra próbálkozás után kiderült, hogy annyira talán mégsem egyszerű.
Azért a szkriptekbe vetett hitünket nem veszítettük el, végül ez vezetett megoldásra, csak nem bash szkriptet írtunk, hanem PowerShellt és nem az ldifde kimenetét alakítottuk át, hanem közvetlen a generált adatokat, CSV-ben.
Ehhez először azt kellett megoldani, hogy az LDIF kimenetben a sorok hossza maximálva van. Amennyiben egy sor túl hosszú (márpedig a DN-ek gyakran hosszúak), akkor a sorba sortörés kerül, majd az új sor eleje egy szóközzel kezdődik és folytatódik a megtört sor. Például:
dn: cn=Beijingstaff,ou=Beijing,ou=China,ou=Asia,ou=Hotels,dc
=irf,dc=local
Erre írtam egy külön függvényt PowerShellben, ami egy változóban megadott hosszúságúra tördelve írja ki a paraméterül kapott sztringet:
function WriteLdifFormat {
param ([string]$str)
$ROWMAXLEN = 60;
$first = $true;
while ($str.Length -gt 0) {
$out = $str.Substring(0,[Math]::Min($ROWMAXLEN,$str.Length))
if ($str.Length -gt $ROWMAXLEN)
{ $str = $str.Substring($ROWMAXLEN, $str.Length-$ROWMAXLEN) }
else { $str = [string]::Empty }
#write to output
if ($first)
{ write "$out"; $first=$false; $ROWMAXLEN--;}
else { write " $out" }
}
}
A konvertálás többi része már egyszerűen megoldható volt. Az Import-Csv cmdlettel könnyű CSV-fájlokon dolgozni. A fájl sorain iterálva minden sorban megvizsgáltam a leírt objektum típusát (objectClass), majd ennek megfelelő kimenetet gyártottam, például:
WriteLdifFormat "dn: $($_.dn)"
WriteLdifFormat "objectClass: top"
if ($_.objectClass -eq "organizationalUnit") {
WriteLdifFormat "objectClass: organizationalUnit"
WriteLdifFormat "ou: $($_.ou)"
WriteLdifFormat "description: $($_.name) Organizational Unit"
}
Utána ezt testre lehet szabni, volt néhány plusz igényünk (például a domainneveket le kellett cserélni, uidNumbert kellett generálni a felhasználóknak, meg kellett oldani, hogy olyan csoportok is létezhessenek, amelyeknek nincs valódi tagja, az OU-khoz létrehozott csoportokra sem használhattuk Linuxon az eddigi PowerShell szkriptet stb.).
Az elkészült szkriptek és az LDIF kimenet itt letölthetőek.
Az IRF tárgy virtuális gépeinek elkészítése kapcsán felmerült, hogy célszerű lenne az Active Directory-t feltölteni nagyobb mennyiségű tesztadattal. Így a címtárakról szóló házi feladatnál már látszana, hogy egy tisztességes címtárban nem tíz darab felhasználó van. Mivel senkinek nem volt kedve párezer felhasználót felvenni, ezért valamilyen más megoldást próbáltunk keresni.
A neten akadnak azért tesztadatok AD-hez, viszont ezek vagy nem voltak megfelelők nekünk (például nem volt benne hierarchikus tárolás), vagy pedig jogilag nem voltak teljesen tiszták. Így maradt az a megoldás, hogy mi magunk készítjük el a felhasználókat, csoportokat, OU-kat. Ennek a folyamatát írtam le ebben a posztban.
- Először ki kellett találni, hogy mi legyen a kerettörténet. Egy néhányezer fős vállalatot kellett kitalálni, aminek sok külön szervezeti egysége van. Így létrejött a SuperHotels cég, amely jelentős méretű vezetőséggel és számos hotellel rendelkezik szerte a világon.
- Ez után megterveztem az OU-k hierarchiáját. A tervezésnél az volt a cél, hogy átlátható legyen a hierarchia, úgyhogy egy mindmapként rajzoltam meg FreeMindban.
- A generálást (részben személyes perverzióknál fogva) Excelben akartam megcsinálni. Szerencsére nem kellett újra begépelni az OU-kat: a FreeMindból HTML-ben kiexportált mindmap Excelbe beillesztve egészen könnyen használhatóvá alakítható volt.
- Ebből előállítottam az OU-k DN-jét, beállítottam, hogy melyik tartalmaz majd ténylegesen felhasználókat és melyik nem, illetve azt is, hogy melyikhez hány felhasználót kell generálni.
- Készítettem egy rakás felhasználót is. Ehhez a kiindulópont egy-egy lista volt az európai leggyakoribb vezeték- és keresztnevekről. Ebből véletlenszerűen válogattam, illetve ez alapján legeneráltam a loginneveket is. (Figyelni kellett arra, hogy loginnevek közt bőven lehet ütközés, ezért az azonos neveket számokkal megkülönböztettem.) Minden felhasználóhoz rendeltem 1-1 OU-t is a számossági kényszerek alapján.
Mindezt úgy, hogy tetszőlegesen sok véletlen tesztadatsor legyen előállítható, úgyhogy mindent Excel-függvények, különösen a VÉL() használatával oldottam meg. (Mivel így elég számításigényes minden frissítés, célszerű a cellák értékének automatikus újraszámítását kikapcsolni.)
- Innen már csak össze kellett válogatni úgy az oszlopokat, hogy azokból CSV-fájlt lehessen generálni, majd utána azt az csvde eszköz be tudja importálni.
A CSV-be mentéshez makrókat használtam, több ok miatt is. Egyrészt így automatikusan generálhatók a fájlok (külön csv-be kerültek az OU-k, a felhasználók és a különböző típusú csoportok), illetve az ezek feltöltését összefogó batch fájl is. Másrészt magyar nyelvű Office-t használtam, amiből GUI-n csak pontosvesszővel elválasztott CSV-fájl készíthető, a csvde viszont ragaszkodik a vesszőkhöz. Szerencsére ha VBA-ból az ActiveWorkbook.SaveAs FileFormat:=xlCSV eljárással mentünk, akkor nyelvfüggetlenül vesszőket fog elválasztóként használni.
- Ezután már (viszonylag) egyenes az út. Persze az első pártucat batch feltöltés CSV-ből nem volt sikeres, ráadásul a csvde sem túl készséges a hibák okának feltárásában (bár a naplózás egy kicsit segít), de sikerült elérni egy működő változathoz.
- Példaként álljon itt egy kimenete a generálásnak. A fentiekhez képest még néhány random csoport is van benne, illetve minden OU-hoz készül 1-1 olyan csoport, ami a benne szereplő felhasználókat fogja össze. Ezek tagságai nem Excelből kerülnek beállításra, hanem egy külön PowerShell szkript gondoskodik róla.
Így már minden adott, hogy lehessen rossz megoldásokat is írni az IRF házi feladatok során: ha valaki ezer lekérdezés helyett egymilliót fog csinálni, az fel fog tűnni a futásidőben.
Készülve az IRF első házi feladatára elővettem újra a PowerShell ActiveDirectory modulját. Mindig lehet új dolgokat találni a súgó témákban, most például az about_ActiveDirectory_ObjectModel oldalon szúrt szemet, hogy le van írva a modulban szereplő osztályok öröklési lánca. Mivel ez egy szöveges súgó, ezért így van megadva:
ADEntity
ADRootDSE
ADObject
ADFineGrainedPasswordPolicy
ADOptionalFeature
ADOrganizationalUnit
ADPartition
ADDomain
ADPrincipal
ADAccount
ADComputer
ADServiceAccount
ADUser
ADGroup
ADDefaultDomainPasswordPolicy
ADForest
ADDirectoryServer
ADDomainController
Ez szép így is, de azért grafikus formában kicsit beszédesebb lenne:) Nem találtam meg sehol, úgyhogy gyorsan rajzoltam a főbb elemekből egy UML diagramot. Így már talán könnyebben átlátható.
 PowerShell ActiveDirectory module object model
(Note: UML class diagram for the objects in the ActiveDirectory PowerShell module based on about_ActiveDirectory_ObjectModel)
Találtam most egy érdekes, a korábbi témákhoz kapcsolódó előadást:
Jeffrey Snover , Refaat Issa: “Make your product manageable“, SAC-644T, BUILD 2011.
Ez az új Windows Server vonalhoz kapcsolódó előadások egyike, és amiért nekünk különösen érdekes itt, az az, hogy azzal kezdi, hogy a menedzselhetőség lesz az egyik legfontosabb megkülönböztetője az alkalmazásoknak; a virtualizáció meg a cloud elterjedésével alapvető szükséglet, hogy az alkalmazásokat lehessen távolról konfigurálni és felügyelni, továbbá, hogy mindent lehessen automatizálni benne. Jeffrey Snoverre pedig ezért érdemes odafigyelni: Jeffrey Snover, Lead Architect for Windows Server Division, inventor of Windows Powershell. Szóval van rálátása a dolgokra:)
Az előadás a Windows Management Framework (WMF) keretrendszer új verzióját mutatja be (ez tulajdonképpen: WMI + PowerShell + Workflow + WSMAN) [IRF-ből ismerősük ezek ugye?:]. Az új architektúra ilyesmi lesz:
Az előadásban sok minden elhangzik, én ezeket írtam fel magamnak. A demo-kat érdemes megnézni.
CIM provider modell v2
- CIM sablon az új Visual Studio-ban: hogy könnyebb legyen CIM providert készíteni, lesz két új sablon.
- CIM Authoring: a modell elkészítéséhez és a MOF fájl legyártásához, lesz grafikus szerkesztő és syntax highlight MOF-hoz.
- CIM Provider: a fenti modellből generál C++ kódvázat.
- Lesznek új PowerShell cmdletek vagy aliasok legalábbis: Get-CimClass, Get-CimInstance…
- “cmdletization”: egy XML segítségével, amiben a leképezést definiáljuk (melyik WMI metódus, tulajdonság milyen PowerShell metódusra, tulajdonságra van leképezve), típusos cmdleteket gyárt egy adott providerhez. Így aztán pl. a példában szereplő MSFT_WinServerice providerhez lesz Get-WinService, Set-WinService, stb. cmdlet. Ezekhez a cmdletekhez van rendes súgó is, sőt, a provider lehet egy távoli CIMOM-ban is, így p. cmdletekkel lehet egy távoli Linux/ESXi/storage gépet lekérdezni.
- A fentiekről szóló DEMO kb. 0:08:00 körül kezdődik.
Munkafolyamatok (workflow)
- A PowerShell 3 egyik komolyabb újdonsága, a segítségével lehet hosszan futó, megszakítható és újraindítható folyamatokat készíteni (pl. virtuális gép létrehozása, AD telepítése).
- XAML leíró kell a munkafolyamatnak, ehhez van Visual Studio IDE, amiben PowerShell cmdletek is lehetnek elemi lépések.
- (show-command cmdlet: GUI űrlapot jelenít meg a paraméterek beviteléhez, hogy az is tudjon ezentúl PowerShellt használni, aki nem tud 3 parancssori kapcsolót megadni;))
- DEMO: 0:37:00
PowerShell Web API
- Hogy el lehessen érni webes API-ról is a menedzsment felületeket, lesz egy szolgáltatás, ami REST és OData alapú API-t ad. Egy-két leíró elkészítése után (amik megszabják, hogy ki és mit érhet el HTTP felületen keresztül) lehet böngészőből is CIM objektumokat lekérdezni majd:)
- DEMO: 0:57:30
Még a végén volt egy “apró” érdekesség: írt az MS állítólag egy új kis erőforrás-igényű CIMOM-ot Linuxra:-). Ezt már valahol olvastam korábban, de most nem találom sehol. A lényeg, hogy nagyon nyomják a CIM/WSMAN alapú menedzsmentet, és szeretnék, ha miden eszközt és alkalmazást el lehetne így érni.
Az új dolgok egy részét ki is lehet próbálni: Windows Management Framework 3.0 Community Technology Preview (CTP) #1 Available for Download
Múlt héten megjelent a VMware platformjának az újabb verziója. Frissítették az összes leírást, rengeteg blogbejegyzés van már róla, itt van pl. egy hosszú lista az új vagy javított képességekről.
Ezt a verziót is könnyen lehet Workstation virtuális gépbe telepíteni, úgyhogy gyorsan ki is próbáltam:
A telepítő nem sokat változott, egy-két finomhangolás volt rajta. Az indítás utáni felület is ismerős, nagyobb változásnak egyelőre csak annyit láttam, hogy a logokat könnyebben elérhetővé tették, és a konzolos felületet átdolgozták (ESXi Shell lett a neve, és a funkciók nagy részét kezdték bemozgatni az esxcli parancsba).
Ami nekünk viszont sokkal érdekesebb volt az az, hogy
- hogyan lehet PXE-n keresztül állapotmentes példányt indítani belőle,
- megy-e majd a laborban lévő gépeinken, lehet-e ezt a verziót használni majd az órákon.
A PXE segítségével történő indításhoz a “vSphere Installation and Setup Guide” a kiindulópont (most már akár epub vagy mobi formában is lehet e-olvasóra tölteni:). Jó hosszú lett ez a leírás, ezt a részt is eléggé kibővítették. Maradt a CD-ről/USB-ről/hálózatról indítom a telepítőt vagy a szkriptelt telepítést (kickstart szkript, csak a benne lévő parancsok változtak sokat). Az állapotmentes példány indítására és későbbi bekonfigurálására viszont bekerült az eddig csak VMware Labs kiegészítésként elérhető Auto Deploy, valamint készült egy Image Builder nevű komponens (PowerCLI felülettel:), amivel ki lehet szedni vagy be lehet rakni komponenseket a hálózatról letöltendő image-be. A telepítési leírásban van részletes leírás róla, továbbá itt van egy gyors áttekintés is. Viszont az Auto Deploy és a Host Profiles továbbra is csak az Enterprise Plus változatban érhető el.
Nekünk valami egyszerűbb kellett, csak tényleg annyi, hogy elinduljon egy teljesen alapállapotban lévő ESXi hálózatról. A 4.1-es verzió esetén ezt így kellett megoldani. 5.0-hoz még nem találtam leírást, így meg kellett először nézni, hogy mi van a telepítő ISO-n.
A fájlneveket és a szerkezetet megint megváltoztatták, gondolom az Image Builder miatt, hogy könnyebben lehessen modulokat hozzáadni vagy elvenni, meg most már támogatja az EFI bootot is. A szokásos kérdés, hogy miket kell ezekből a PXE szerverre felmásolni. Nézzünk meg ehhez egy frissen feltelepített ESXi 5.0-t! Így néz ki a partíciós táblája:
A korábbi verziókból ismerős a felosztás:
- sda1: boot partíció
- sda5: primary bootbank, itt van maga a hypervisor mindenféle fájlja, amit majd betölt a memóriába
- sda6: alternate bootbank, frissítés esetén ide kerül az új verzió, hogy vissza lehessen állni a régire gond esetén
- sda7: passz
- sda8: store. itt vannak a VMware Tools telepítők, meg ide kerültek az Image Builderhez tartozó VIB-ek.
- sda2: scratch, ide kerülnek a logok és a core dumpok többek között
- sda3: ez pedig már a VMFS, ide jönnének a virtuális gépek
Ebből nekünk az kell, hogy mi van jelenleg a primary bootbank partíción:
Első körben tehát ezeket érdemes felmásolni a PXE szerverre (lehet, hogy kevesebb fájllal is megy, de így biztos elindul).
Kell még nekünk a PXE boot menübe egy bejegyzés, hogy mit kell indítani:
LABEL ESXi-5.0.0-live
menu label VMware ESXi 5.0.0-469512 Live
kernel images/esxi-5.0.0/mboot.c32
append -c images/esxi-5.0.0/boot.cfg
Értelemszerűen az elérési utat módosítani kell, nálunk a TFTP szerveren egy images/esxi-5.0.0 könyvtárba kerültek a fenti fájlok. Ezen kívül érdemes még a boot.cfg-t megnézni:
bootstate=0
title=Booting ESXi 5.0.0 (FTSRG IT)
kernel=tboot.b00
kernelopt=no-auto-partition
modules=b.b00 --- useropts.gz --- k.b00 --- a.b00 --- ata-pata.v00 --- ata-pata.v01 --- ata-pata.v02 --- ata-pata.v03 --- ata-pata.v04 --- ata-pata.v05 --- ata-pata.v06 --- ata-pata.v07 --- block-cc.v00 --- ehci-ehc.v00 --- s.v00 --- ima-qla4.v00 --- ipmi-ipm.v00 --- ipmi-ipm.v01 --- ipmi-ipm.v02 --- misc-cni.v00 --- misc-dri.v00 --- net-be2n.v00 --- net-bnx2.v00 --- net-bnx2.v01 --- net-cnic.v00 --- net-e100.v00 --- net-e100.v01 --- net-enic.v00 --- net-forc.v00 --- net-igb.v00 --- net-ixgb.v00 --- net-nx-n.v00 --- net-r816.v00 --- net-r816.v01 --- net-s2io.v00 --- net-sky2.v00 --- net-tg3.v00 --- ohci-usb.v00 --- sata-ahc.v00 --- sata-ata.v00 --- sata-sat.v00 --- sata-sat.v01 --- sata-sat.v02 --- sata-sat.v03 --- scsi-aac.v00 --- scsi-adp.v00 --- scsi-aic.v00 --- scsi-bnx.v00 --- scsi-fni.v00 --- scsi-hps.v00 --- scsi-ips.v00 --- scsi-lpf.v00 --- scsi-meg.v00 --- scsi-meg.v01 --- scsi-meg.v02 --- scsi-mpt.v00 --- scsi-mpt.v01 --- scsi-mpt.v02 --- scsi-qla.v00 --- scsi-qla.v01 --- uhci-usb.v00 --- imgdb.tgz
build=5.0.0-469512
updated=0
Itt arra figyeljünk, hogy
- Az ISO-ban nagy betűk vannak a fájlnevekben, azt érdemes végig kisbetűsre megváltoztatni a PXE szerveren, mert a kis- és nagybetű különbségre érzékeny.
- Az ISO-n a kernelopt-nál runweasel szerepel, az jelzi azt, hogy a telepítőt kell indítani, természetesen az most itt nem kell.
- Itt már lehet relatív elérési utakat használni, nem kell az images/esxi-5.0.0 prefix.
Ha felmásoljuk a fájlokat, megfelelő a boot.cfg és hozzáadtuk jól a menühöz, akkor pedig szépen el is indul a hálózatról az ESXi:
Ennyi kell már csak a hálózatról történő indításhoz:) Ez volt az első kérdésünk, ez kipipálva.
A másik kérdésre is meglett a válasz, a laborban lévő gépeken elindul az 5.0.0-s verzió is, így ősszel a Virtualizációs technológiák tantárgyunk megfelelő gyakorlatán valószínűleg ez megy már majd.
|
