Seznßmenφ se sφ¥ovou datbßzφ NetInfo z minulΘho Φφsla Chipu dnes dokonΦujeme popisem n∞kter²ch standardnφch klφΦ∙ a adresß°∙ NetInfa. Do NetInfa m∙₧eme uklßdat libovolnΘ adresß°e a v nich mohou b²t libovolnΘ klφΦe podle pot°eby. ╪adu standardnφch hodnot vÜak definuje a vyu₧φvß sßm systΘm NetInfo a n∞kterΘ standardnφ servery a aplikace Mac OS X; na n∞kterΘ z nich se podφvßme blφ₧.
KlφΦ name
Ka₧d² adresß° vyjma ko°enovΘho mß klφΦ name; jeho hodnota je chßpßna jako jmΘno adresß°e. Dob°e je to vid∞t na obr. 2. Je vhodnΘ si uv∞domit, ₧e sice ka₧d² adresß° musφ mφt jmΘno, nic vÜak nebrßnφ tomu, aby m∞l jmen vφce: mß-li hodnota name vφce hodnot, m∙₧eme prost∞ na jeden a tent²₧ adresß° odkazovat vφce r∙zn²mi jmΘny.
JmΘno adresß°e samoz°ejm∞ mß znaΦn² v²znam, proto₧e slou₧φ ke specifikaci adresß°e pomocφ cesty. V principu je mo₧nΘ pojmenovat vφce adresß°∙ (je₧ jsou pod°φzeny spoleΦnΘmu adresß°i) stejn∞, tak₧e cesta pak nebude jednoznaΦnß: samoz°ejm∞, rozhodn∞ to nelze doporuΦovat, ale databßzi NetInfo to nikterak nevadφ. Pokud bychom to vÜak ud∞lali, budeme muset pro v²b∞r takov²chto adresß°∙ pou₧φvat Φφsla ID.
KlφΦ master
Ko°enov² adresß° ka₧dΘ domΘny sice nemß klφΦ name, namφsto toho je vÜak v n∞m klφΦ master, jeho₧ hodnota odpovφdß domΘn∞, kterΘ adresß° pat°φ. Jejφ forma je <jmΘno poΦφtaΦe>/<tag domΘny>.
NetInfo tento ·daj vyu₧φvß nejen pro orientaci v hierarchickΘ struktu°e domΘn, ale takΘ pro urΦenφ hlavnφ domΘny a jejφch p°φpadn²ch klon∙: jestli₧e domΘna le₧φ na jinΘm poΦφtaΦi, ne₧ je <jmΘno poΦφtaΦe> z hodnoty master ko°enovΘho adresß°e, je pova₧ovßna za klon. Hodnoty v takovΘ domΘn∞ jsou automaticky udr₧ovßny jako kopie hodnot z hlavnφ domΘny, klon je tedy vlastn∞ jak²mi jejφm "zrcadlem".
Klony v NetInfu slou₧φ dv∞ma ·Φel∙m. Za normßlnφch okolnostφ sni₧ujφ provoz v sφti, proto₧e mohou ·daje z domΘny p°edat poΦφtaΦ∙m, je₧ jsou k nim fyzicky blφ₧ (z hlediska technickΘ struktury sφt∞), snßze, ne₧ kdyby se poΦφtaΦe musely obracet p°φmo na hlavnφ domΘnu. Klony tedy zvyÜujφ efektivitu sφt∞. (Jist∞, platφ se za to slo₧it∞jÜφmi zm∞nami, proto₧e ka₧dß zm∞na hlavnφ domΘny musφ prob∞hnout i ve vÜech jejφch klonech; databßze se vÜak m∞nφ pom∞rn∞ mßlokdy, zato ·daje se z nφ Φtou ka₧dou chvilku.)
Krom∞ toho m∙₧e klon p°i v²padku poΦφtaΦe obsluhujφcφho hlavnφ domΘnu okam₧it∞ p°ebrat jeho roli. Klony tak zßrove≥ slou₧φ jako automaticky udr₧ovanΘ zßlo₧nφ kopie domΘn, a tak zvyÜujφ spolehlivost sφt∞.
Adresß° /machines a jeho podadresß°e
Podadresß°e v adresß°i machines specifikujφ vÜechny poΦφtaΦe v sφti; zde prßv∞ vznikß vazba mezi jmΘnem poΦφtaΦe a jeho IP adresou (a dalÜφmi atributy). Obvykle (ale ne nutn∞) obsahuje adresß° machines zßznamy pro vÜechny pod°φzenΘ poΦφtaΦe û informace o nad°φzen²ch jsou ulo₧eny v nad°φzenΘ domΘn∞.
Zßznamy navφc urΦujφ jmΘna pod°φzen²ch poΦφtaΦ∙ a domΘn. Adresß° machines obvykle nem∞nφme p°φmo v NetInfu, proto₧e b²vß pohodln∞jÜφ pou₧φt slu₧by specializovanΘ aplikace NetworkManager. Ty samoz°ejm∞ takΘ ned∞lajφ nic jinΘho ne₧ zm∞ny ·daj∙ v adresß°φ machines, ale jsou pohodln∞jÜφ a jsou lΘpe zabezpeΦeny proti chyb∞ administrßtora, ne₧ kdybychom p°φmo ruΦn∞ nastavovali jednotlivΘ hodnoty.
Ka₧d² podadresß° odpovφdß poΦφtaΦi, kter² je pod°φzen danΘ domΘn∞. JmΘno adresß°e je jmΘnem poΦφtaΦe; mß-li mφt poΦφtaΦ vφce jmen, je prost∞ u klφΦe name ulo₧eno vφc hodnot û takov² p°φpad zrovna ilustruje obr. 3. PoΦφtaΦ next zßrove≥ slou₧φ jako mail server; proto je ÜikovnΘ mu p°id∞lit alias mailhost. VÜechny obslu₧nΘ scripty na vÜech poΦφtaΦφch v celΘ sφti pak snadno mohou pou₧φvat prßv∞ jmΘno mailhost a nebude zapot°ebφ je nijak m∞nit v p°φpad∞, ₧e konfiguaci sφt∞ zm∞nφme a slu₧by mail serveru p°ebere jin² poΦφtaΦ.
Zatφmco klφΦ name urΦuje jmΘno poΦφtaΦe, klφΦ serves urΦuje jmΘno domΘny. Pro ka₧dou domΘnu, ji₧ dan² poΦφtaΦ spravuje, je zde zßznam ve formßtu <jmΘno domΘny>/<tag domΘny> (je z°ejmΘ, ₧e pro urΦenφ domΘny staΦφ uvΘst tag û identifikace poΦφtaΦe je zbyteΦnß, proto₧e cel² adresß° prßv∞ identifikuje n∞kter² poΦφtaΦ). JmΘna domΘn se mohou liÜit od jmen odpovφdajφcφch poΦφtaΦ∙; pokud se vÜak administrßtor chce ve svΘ sφti vyznat, v°ele mu to nedoporuΦuji.
Na prvnφ pohled m∙₧e vypadat divn∞, ₧e jmΘno domΘny (a poΦφtaΦe) nenφ ulo₧eno v nφ, ale je urΦeno nad°φzenou domΘnou. P°ipomeneme-li si vÜak hierarchickou strukturu NetInfa a jejφ vztah ke struktu°e sφt∞, stane se to samoz°ejm²m: jmΘna vÜech poΦφtaΦ∙ pod°φzen²ch danΘ domΘn∞ musejφ b²t k dispozici vÜem ostatnφm poΦφtaΦ∙m tΘ₧e domΘny û prßv∞ v nφ tedy musφ b²t definovßna. Nap°φklad jmΘno poΦφtaΦe /praha/centrum/management/g4 musφ b²t definovßno v domΘn∞ management (nebo v n∞kterΘ z domΘn nad°φzen²ch); pokud by bylo urΦeno a₧ v listovΘ domΘn∞ local poΦφtaΦe g4, znal by toto jmΘno jen on sßm (jak hned uvidφme, je tato mo₧nost vyu₧ita pro skuteΦn∞ lokßlnφ jmΘna localhost a broadcasthost).
Na mφst∞ jmΘna domΘny m∙₧e stßt i "." nebo ".." û tφm odkazujeme na aktußlnφ nebo nad°φzenou domΘnu (vzhledem k domΘn∞, ve kterΘ je dan² zßznam /machines/xxx). JmΘna takov²ch domΘn pak budou urΦena z domΘn nad°φzen²ch nebo implicitn∞ jako "/" pro ko°enovou domΘnu. KonkrΘtn∞ tedy jmΘno domΘny s tagem network na poΦφtaΦi next nenφ urΦeno: pokud by existovala nad°φzenß domΘna (na libovolnΘm poΦφtaΦi), byl by v nφ pro poΦφtaΦ next zßznam serves s hodnotou <jmΘno>/network; tak by bylo tΘto domΘn∞ p°i°azeno jmΘno. Pokud nad°φzenß domΘna neexistuje, je tato domΘna ko°enovß a mß standardnφ jmΘno "/". Podobn∞ domΘna next s tagem local je pod°φzenß domΘna domΘny na obrßzku; v nφ bude zßznam serves obsahujφcφ ./local. Pokud by domΘna local na poΦφtaΦi next obsahovala i adresß° reprezentujφcφ nad°φzen² poΦφtaΦ, byl by v n∞m zßznam serves obsahujφcφ ../network.
DalÜφ klφΦe urΦujφ atributy danΘho poΦφtaΦe: klφΦ ip_address obsahuje internetovou adresu, je₧ je poΦφtaΦi p°id∞lena, en_address obsahuje adresu ethernetovΘ karty poΦφtaΦe a umo₧≥uje tak identifikaci poΦφtaΦe po jeho p°ipojenφ k sφti (ethernetovΘ adresy vÜech karet jsou unikßtnφ).
ListovΘ domΘny s tagy local, reprezentujφcφ konkrΘtnφ poΦφtaΦe, by teoreticky nemusely obsahovat adresß° /machines v∙bec. Z technick²ch p°φΦin vÜak v nich tyto adresß°e jsou a v₧dy obsahujφ dva standardnφ zßznamy:
- localhost je alias danΘho poΦφtaΦe (proto₧e je hodnotou serves="./local" p°ipojen k tΘ₧e domΘn∞, v nφ₧ je zßznam). UrΦuje v₧dy pro poΦφtaΦ alternativnφ IP adresu 127.0.0.1. Je vhodnΘ si uv∞domit, ₧e jeliko₧ domΘna local je listovou domΘnou, jejφ₧ ·daje jsou p°i vyhledßvßnφ k dispozici jen tomu kterΘmu poΦφtaΦi, bude pro ka₧d² poΦφtaΦ jmΘno localhost a adresa 127.0.0.1 znamenat n∞co jinΘho û toti₧ sebe samΘ. To je samoz°ejm∞ p°esn∞ to, co jsme pot°ebovali;
- broadcasthost je dφky hodnot∞ serves="../network" aliasem nad°φzenΘho poΦφtaΦe. Krom∞ jmΘna je mu p°id∞lena alternativnφ IP adresa 255.255.255.255; je tedy z°ejmΘ, ₧e jeho ·Φelem je umo₧nit rozesφlßnφ paket∙ po celΘ subsφti.
Adresß°e /users, /groups a jejich podadresß°e
V adresß°i users jsou ulo₧eny zßznamy o u₧ivatelsk²ch kontech. Ka₧d² z jeho podadresß°∙ reprezentuje jedno konto; jeho klφΦe a jejich hodnoty urΦujφ konkrΘtnφ atributy toho kterΘho u₧ivatele. P°φklad vidφme na obr. 4, kter² ukazuje obsah adresß°e /users/ocs.
Snad prßv∞ na u₧ivatelsk²ch kontech v adresß°φch users je nejlΘpe vid∞t v²hoda hierarchickΘ organizace databßze NetInfo: v praxi je zcela b∞₧nΘ, ₧e pot°ebujeme °adu u₧ivatelsk²ch kont s r∙zn²m rozsahem: n∞kterß konta musφ b²t k dispozici prost°ednictvφm kterΘhokoli poΦφtaΦe v sφti, jinß by m∞la b²t dosa₧itelnß p°es kter²koli poΦφtaΦ v rßmci n∞jakΘ subsφt∞ (t°eba management), ale u₧ ne ze subsφtφ ostatnφch. Jindy naopak pro n∞kterΘ specifickΘ ·Φely pot°ebujeme u₧ivatelskß konta vßzanß na jedin² konkrΘtnφ poΦφtaΦ.
V rßmci hierarchie domΘn NetInfa nenφ nic jednoduÜÜφho: u₧ivatelskΘ konto definovanΘ v ko°enovΘ domΘn∞ bude samoz°ejm∞ p°φstupnΘ kdekoli v celΘ sφti. Konta urΦenß pro subsφt∞ definujeme v odpovφdajφcφch mezilehl²ch domΘnßch. Cheme-li konto lokßlnφ na tom kterΘm poΦφtaΦi, prost∞ jej definujeme v adresß°i users jeho lokßlnφ domΘny. TakovΘ konto pak nebude viditelnΘ nikde jinde (nebo m∙₧e mφt t°eba ka₧d² poΦφtaΦ stejn∞ pojmenovanΘ lokßlnφ konto s odliÜn²mi atributy, pokud bychom n∞co takovΘho pot°ebovali û stejn∞ jako ka₧d² poΦφtaΦ znß stroj localhost, ale poka₧dΘ to je n∞kdo jin²).
Vyu₧φvßme-li sφ¥ovΘ u₧ivatele, je t°eba se takΘ postarat o to, aby jejich domovsk² adresß° byl k dispozici vÜude, kde je p°φstupnΘ samo konto. K tomu slou₧φ systΘm sdφlenφ soubor∙ NFS (pro Mac OS X je p°φznaΦnΘ, ₧e jde o standard, ne o proprietßrnφ °eÜenφ) a adresß°e exports a mounts, na kterΘ se podφvßme za chvilku.
Analogicky jako u₧ivatelskß konta v adresß°φch users jsou definovßny skupiny v adresß°φch groups; souΦßstφ definice skupiny je takΘ seznam vÜech u₧ivatel∙, kte°φ do nφ pat°φ (naopak polo₧ka gid v adresß°i reprezentujφcφm u₧ivatelskΘ konto urΦuje defaultnφ skupinu, p°id∞lovanou nov∞ vytvo°en²m slo₧kßm a soubor∙m, nevy₧ßdß-li si u₧ivatel zm∞nu).
Podobn∞ jako u adresß°e machines i pro prßci s adresß°i users a groups b²vß pohodln∞jÜφ pou₧φt slu₧by specializovanΘ aplikace NetworkManager.
Adresß°e /exports a /mounts a jejich podadresß°e
Poslednφ ze standardnφch adresß°∙, o nich₧ se zmφnφm, jsou adresß°e exports a mounts. Ty jsou oba vyu₧φvßny systΘmem NFS pro sdφlenφ soubor∙; zatφmco adresß° exports obsahuje zßznamy o adresß°φch, je₧ majφ b²t k dispozici ostatnφm poΦφtaΦ∙m, v adresß°i mounts naopak nalezneme ·daje o tom, kter² z adresß°∙ dostupn²ch v sφti se mß zp°φstupnit a na kterΘ mφsto v systΘmu soubor∙ se mß "namontovat" (Mac OS X a jeho NFS samoz°ejm∞ umo₧≥ujφ umφstit vzdßlen² adresß° kamkoli v systΘmu soubor∙, nejen na specißlnφ mφsto, jako je tomu v systΘmech typu Windows).
PozornΘmu Φtenß°i ji₧ bude z°ejmΘ, ₧e zßznamy exports b²vajφ v lokßlnφch domΘnßch konkrΘtnφch poΦφtaΦ∙: samoz°ejm∞, obvykle chceme exportovat konkrΘtnφ adresß° z konkrΘtnφho stroje, a ne "adresß° /xyz ze vÜech poΦφtaΦ∙ v subsφti". Naopak, zßznamy mounts b²vajφ spφÜe v domΘnßch na vyÜÜφ ·rovni: adresß°e obvykle chceme zp°φstupnit vÜem poΦφtaΦ∙m v subsφti, nejen jednomu konkrΘtnφmu.
Adresß°e mounts a exports um∞jφ op∞t s vysok²m u₧ivatelsk²m luxusem editovat aplikace NetworkManager; je proto Üikovn∞jÜφ vyu₧φt jejich slu₧eb, a ne ·daje v t∞chto adresß°φch m∞nit p°φmo.
Prßce s databßzφ NetInfo
Implicitn∞ pracuje s databßzφ NetInfo spousta aplikacφ a program∙: m∞nφme-li nap°φklad atributy sφt∞ prost°ednictvφm odpovφdajφcφho °φdicφho panelu, uklßdßme data do NetInfa; °ada slu₧eb a program∙ Φte z NetInfa ·daje (nap°. ovladaΦe NFS prßv∞ v n∞m vyhledajφ seznamy importovan²ch a exportovan²ch adresß°∙). Navφc je k dispozici n∞kolik prost°edk∙ prßv∞ pro editaci NetInfa.
SpecializovanΘ aplikace
SouΦßstφ Mac OS X je n∞kolik specializovan²ch aplikacφ, je₧ sice jsou de facto editory databßze NetInfo, ale jejich u₧ivatelskΘ rozhranφ je formovßno pro pohodlnΘ °eÜenφ konkrΘtnφho problΘmu. Typick²m p°φkladem je ji₧ zmφn∞n² NetworkManager, kter² nabφzφ velmi pohodlnΘ rozhranφ mj. pro
- definovßnφ u₧ivatelsk²ch kont a skupin;
- p°idßvßnφ a odebφrßnφ poΦφtaΦ∙;
- specifikaci sdφlenφ soubor∙.
Administrßtor p°itom nepot°ebuje v∞d∞t prakticky nic o n∞jak²ch adresß°φch users, groups, machines Φi exports nebo mounts ani o jejich hodnotßch. StaΦφ mu zßkladnφ pov∞domφ o domΘnßch NetInfa (proto₧e NetworkManager umo₧≥uje specifikovat domΘnu, v jejφm₧ rßmci zm∞ny provede), a vÜe ostatnφ je ji₧ zcela intuitivnφ.
Jinou podobnou aplikacφ je Assistant, kter² provede administrßtora kompletnφm nastavenφm systΘmu, nebo PrintManager, kter² se specializuje na editaci dat NetInfa popisujφcφch sdφlenΘ tiskßrny.
Pokud je pro dan² ·kol k dispozici specializovanß aplikace, v₧dy se ji vyplatφ vyu₧φt: je to pohodln∞jÜφ, Üet°φ to Φas, a navφc je to bezpeΦn∞jÜφ û specializovanΘ aplikace automaticky brßnφ tomu, aby v NetInfu vznikla v²znamnß nekonzistence.
NetInfoManager
Samoz°ejm∞ ₧e n∞kdy skuteΦn∞ pot°ebujeme NetInfo editovat p°φmo. K tomu slou₧φ aplikace NetInfoManager, ji₧ nalezneme ve standardnφ slo₧ce /System/Administration nebo v Apple menu ve skupin∞ Server Administration. V tΘto aplikaci si m∙₧eme vy₧ßdat otev°enφ kterΘkoli domΘny v okn∞, obdobnΘm t∞m, je₧ jsme vid∞li na minul²ch obrßzcφch; domΘnu p°itom m∙₧eme urΦit kter²mkoli zp∙sobem (pomocφ cesty nebo adresy poΦφtaΦe a tagu). Uvnit° oken je k dispozici hierarchick² pohled na vÜechny adresß°e v domΘn∞, a zvolφme-li kter²koli z nich, m∙₧eme v dolnφ Φßsti okna editovat jeho klφΦe a hodnoty.
Pro b∞₧nΘ prßce s databßzφ NetInfo si NetInfoManager sßm vy₧ßdß vlo₧enφ hesel podle pot°eby. Pokud jej vÜak rovnou spustφme v rßmci administrßtorskΘho konta, nabφdne navφc silnou (a potencißln∞, samoz°ejm∞, nebezpeΦnou) sadu slu₧eb pro ·pravy samotnΘ hiearchie domΘn NetInfa. Vyu₧itφ t∞chto slu₧eb je pochopiteln∞ op∞t mnohem pohodln∞jÜφ a bezpeΦn∞jÜφ ne₧ p°φmß editace ·daj∙ serves v adresß°φch /machines jednotliv²ch domΘn.
╪ßdkovΘ programy
Cheme-li NetInfo upravovat ruΦn∞, je ideßlnφ vyu₧φt bu∩ specializovanΘ aplikace, nebo NetInfoManager. Administrßtor vÜak m∙₧e obΦas pot°ebovat n∞kterΘ prßce s databßzφ automatizovat; k tomu se ideßln∞ hodφ skripty. Abychom z nich mohli pracovat s NetInfem, pot°ebujeme °ßdkovΘ programy, je₧ nabφzejφ obdobnΘ slu₧by jako NetInfoManager.
Mac OS X je rozumn∞ navr₧en² systΘm, a proto zcela samoz°ejm∞ takovΘ programy nabφzφ. Jejich podrobn² popis by p°esßhl mo₧nosti tohoto Φlßnku, alespo≥ struΦn∞ se s nimi ale seznßmφme:
- nifind dokß₧e vyhledat v hiearachii domΘn po₧adovan² adresß°;
- nigrep umφ hledat dokonce regulßrnφ v²razy v libovolnΘm textu v NetInfu;
- nireport vypisuje obsah tabulek;
- nidump a niload vypφÜe/zm∞nφ obsah NetInfa; oba jsou urΦeny nap°φklad pro spoluprßci s jin²mi adresß°ov²mi slu₧bami, kdy je zapot°ebφ automaticky p°enßÜet ·daje mezi NetInfem a t°eba Novellem;
