Sieci komputerowe – laboratorium

Transkrypt

Sieci komputerowe – laboratorium
dr inż. Marcin Markowski
Instytut Informatyki i Inżynierii Produkcji
Sieci komputerowe – laboratorium
Temat ćwiczenia: Novell Netware 4.0 – podstawy pracy w systemie
Cel ćwiczenia
Celem ćwiczenia jest zapoznanie się ze środowiskiem i podstawowymi narzędziami
użytkownika służącymi do pracy w systemie Novell Netware 4.0. Na ćwiczenie przeznaczone są
2 godziny laboratoryjne.
Wprowadzenie
Podstawową funkcją serwera jest przechowywanie i udostępnianie plików i/lub usług
uprawnionym użytkownikom. Aby zapewnić kontrolę dostępu do zasobów, system serwera musi
dysponować odpowiednią bazą danych, zawierającą informacje o:
• zasobach
• użytkownikach
• prawach użytkowników do korzystania z zasobów.
W systemach NetWare taka baza nosiła kolejno nazwy: Bindery w NetWare 3 i starszych;
NetWare Directory Services (NDS) w NetWare 4 i 5; oraz NDS w Netware 6.0 i nowszych.
NDS ma strukturę hierarchiczną i jest bazą obiektową, tzn. każdy ‘element’ sieci jest
reprezentowany jako obiekt o określonych właściwościach. Zasadniczą funkcją NDS jest
zorganizowanie dostępu do informacji o wszelkich obiektach w sieci globalnej i kontrolowanie
wzajemnych zależności tych obiektów. Budowa bazy obiektowej, którą zarządza NDS, jest
zgodna ze standardem ISO X.500 i reprezentuje zunifikowaną strukturę dla każdej sieci.
Chakterystyka NDS
Zgodność bazy obiektowej NDS ze standardem X.500 narzuca pewne wstępne wymagania na jej
strukturę i funkcjonalność:
• Wszystkie zasoby sieci definiowane są jako obiekty, które zarządzane są przez NDS w
sposób hierarchiczny, a drzewiasta struktura bazy tych obiektów na ogół odzwierciedla
schemat organizacyjny przedsiębiorstwa. Jest przez to bardziej przyjazna użytkownikowi,
który nie musi znać fizycznej struktury sieci w przedsiębiorstwie, ale powinien raczej
znać organizację samej firmy.
• Każdy obiekt, a może nim być użytkownik, jednostka organizacyjna, komputer czy
drukarka, posiadają zespół cech, którym przypisane są odpowiednie wartości, np. numery
seryjne dla komputera, a adres dla użytkownika.
• Użytkownik sieci może odwoływać się do obiektów za pomocą prostych nazw,
kojarzonych z typem i cechami obiektów, natomiast NDS przeprowadza ich
jednoznaczną identyfikację na podstawie unikalnego systemu nazewnictwa.
•
•
•
•
Użytkownik nie rejestruje się na serwerze, lecz w bazie NDS (w drzewie NDS), dzięki
czemu uzyskuje dostęp do wszystkich serwerów w całym drzewie. Nie ma to oczywiście
znaczenia przy systemach jednoserwerowych.
Użytkownik może korzystać z funkcji skorowidza typu yellow pages, czyli wyszukiwania
obiektów w bazie na podstawie określonych przez siebie kryteriów.
Baza NDS może być podzielona na logiczne fragmenty, zwane partycjami, niekoniecznie
mającymi związek z fizyczną lokalizacją obiektów. Partycje te mogą być replikowane na
wielu serwerach, co zabezpiecza bazę przed utratą integralności w przypadku zniszczenia
danych pierwotnej kopii partycji.
Baza NDS jest automatycznie synchronizowana, a globalny system synchronizacji
czasowej kontroluje spójność danych w przypadku modyfikacji bazy z wielu odległych
miejsc równocześnie.
Typy obiektów NDS
Jak już wspomniano, struktura bazy jest hierarchiczna. W związku z tym można ją zobrazować
za pomocą drzewa obiektów, podobnie jak hierarchiczną strukturę plikową w systemach DOS
lub UNIX. Od razu jednak zaznaczmy, iż struktura plików w systemie NetWare, mimo iż
podobna, nie ma związku z budową bazy obiektowej NDS . Każdy wolumin dyskowy
zainstalowany w sieci jest reprezentowany przez obiekt w NDS, natomiast sama struktura
woluminu (system plików) nie jest znana ani przechowywana w bazie.
Drzewo tworzone jest z trzech typów obiektów, charakteryzujących miejsce obiektu w
hierarchii. Są to:
•
•
•
korzeń (Root)
kontener (Container)
liść (Leaf).
Obiekt typu korzeń tworzony jest automatycznie w trakcie instalacji systemu NetWare na
szczycie drzewa i jest jedynym tego typu obiektem w całej strukturze. Rozgałęzienia struktury
zawierają kontenery i liście, przy czym kontenery mogą zawierać inne obiekty typu kontener.
Obiekty typu liść tworzą zakończenia gałęzi drzewa i nie mogą już zawierać innych obiektów.
Istnieją trzy rodzaje obiektów typu kontener:
•
•
•
kraj (Country) oznaczany literą C,
organizacja (Organization) oznaczana przez O,
jednostka organizacyjna (Organizational Unit) oznaczana symbolem OU.
W każdej strukturze drzewa obiektów musi znajdować się co najmniej jeden obiekt typu
organizacja. Jednostki organizacyjne mogą ułatwiać organizowanie bazy obiektowej, ale ich
występowanie w drzewie nie jest obowiązkowe. Przy definiowaniu obiektów typu organizacja i
jednostka organizacyjna należy dbać o to, aby ich nazwy były nazwami docelowymi, ponieważ
ich zmiana nie jest operacją prostą.
Obiekt kraj winien być stosowany jedynie w wyjątkowych przypadkach np. tworzenia bazy dla
globalnego przedsiębiorstwa), gdyż jego obecność w drzewie obiektów komplikuje
wykonywanie operacji na elementach bazy. Wykorzystanie tego obiektu umożliwia m. in.
zdefiniowanie różnych stref czasowych.
Liście to fizyczne lub logiczne obiekty sieci nie zawierające innych obiektów, np. użytkownicy,
grupy użytkowników (które wbrew intuicji nie są obiektami typu kontenerowego), serwery,
woluminy, drukarki, kolejki drukowania itd. Posiadają one zazwyczaj ogólne nazwy (Common
Name) oznaczane symbolem CN.
Obiekty umieszczane w danej jednostce organizacyjnej (OU) powinny być zgrupowane zgodnie
z przynależnością do grupy roboczej, czyli zatrudnionych pracowników i współużywanych przez
nich zasobów: drukarek, programów, plików z danymi.
Pojęcie kontekstu
Jak już wspomniano, rozmaite obiekty mogą być umiejscowione w różnych kontenerach, które z
kolei mogą się zawierać w innych kontenerach itd. Może się, rzecz jasna, zdarzyć sytuacja, w
której istnieć będą dwa obiekty zupełnie od siebie niezależne ale posiadające tę samą nazwę. Na
przykład dwóch użytkowników, pracujących w dwóch różnych działach firmy posiada
identyfikator TOMASZ. Ponieważ pracują gdzie indziej, administrator umieścił ich w różnych
kontenerach, reprezentujących działy (jednostki organizacyjne) firmy: SERWIS i BIURO. Obaj
użytkownicy, mimo iż tak samo nazwani, mają określone inne prawa dostępu do plików
zawartych w woluminach. Mają też inne prawa do wszystkich pozostałych obiektów NDS, w
tym do siebie nawzajem (przykładowo TOMASZ z BIURA może nie wiedzieć o istnieniu
drugiego TOMASZA ani nawet kontenera, w którym tamten jest zawarty).
W sytuacji takiej jak w opisanym przykładzie, mamy do czynienia z faktem, że każdy z
opisywanych użytkowników znajduje się w innym kontekście. Kontekst to inaczej pozycja
obiektu w strukturze hierarchicznej NDS, przy czym dotyczy to nie tylko użytkowników ale
także wszystkich pozostałych obiektów. Pojęcie kontekstu jest więc podobne do pojęcia ścieżki
w hierarchicznej strukturze katalogów systemu DOS. Tak jak ścieżka w DOS-ie jednoznacznie
określa, o który katalog lub plik chodzi, tak kontekst precyzuje, w którym miejscu struktury
NDS dany obiekt się znajduje. Odwołanie do obiektu jest poprawne, jeżeli polega na
wyspecyfikowaniu jego pełnego kontekstu (tj. ścieżki zawierającej listę wszystkich kontenerów
dzielących dany obiekt od [Root]).
Kontekstem bieżącym jest aktualna pozycja w NDS (na tej samej zasadzie jak bieżący katalog w
systemie plików). Z pozycji tej dostępne są bezpośrednio inne obiekty NDS (pod warunkiem
posiadania prawa dostępu do nich) zawarte w tym samym kontenerze i aby się do nich odwołać
nie trzeba podawać pełnej ścieżki; wystarczy podanie nazwy obiektu (czyli adresu względnego).
Konwencje syntaktyczne w NDS
Wszelkie obiekty istniejące w strukturze NDS muszą mieć swoją nazwę, albo inaczej mówiąc
własność Name. Musi być ona obowiązkowo wypełniona wartością już przy tworzeniu obiektu.
Zasady nazywania obiektów są dosyć proste. Ich nazwy nie mogą być dłuższe niż 64 znaki
(oprócz dwuznakowych nazw kontenera typu Country, które są międzynarodowym skrótem
nazwy kraju), w jednym kontenerze nie może wystąpić więcej niż jeden obiekt o tej samej
nazwie, a do tworzenia nazwy można użyć dowolnego znaku specjalnego. Małe i duże litery nie
są rozróżniane, a znak spacji jest utożsamiany ze znakiem podkreślenia. Dopuszczalne (ale nie
zalecane) jest także używanie znaków narodowych.
Nieco bardziej skomplikowana jest zasada odwoływania się do obiektu przez podanie ścieżki do
niego. Tutaj analogie z systemem DOS przestają obowiązywać. O ile bowiem w systemie DOS
pełna ścieżka zaczyna się od podania "korzenia" czyli szczytu struktury hierarchicznej i dalej
katalogów "w dół" tej struktury, tak w NDS specyfikacja kontekstu zaczyna się od nazwy
obiektu i dalej wymieniane są kolejne nazwy kontenerów w kierunku szczytu struktury (obiektu
[Root] jako ostatniego zazwyczaj nie wymienia się). Dodatkowo przyjęto założenia, że każdy
obiekt może być poprzedzony kwalifikatorem typu właściwego dla niego (czyli C, O, OU albo
CN) ze znakiem '=', a kolejne nazwy odpowiadające kolejnym poziomom oddziela się znakiem
kropki. Jeżeli specyfikacja kontekstu jest pełna, czyli zawiera całą ścieżkę w NDS, to całą
specyfikację poprzedza znak kropki. Kropka wiodąca ma zatem znaczenie specjalne i informuje,
że ciąg znaków następujący po niej to pełna nazwa. Brak kropki wiodącej niesie zaś ważną
informację, że ciąg znaków w nazwie to nie pełna nazwa, lecz odwołanie względne w stosunku
do bieżącego kontekstu (jest to tzw. nazwa częściowa lub adres względny). Wtedy system
dokleja podaną nazwę względną do nazwy specyfikującej kontekst bieżący do jego lewej strony i
całą powstałą w ten sposób nazwę traktuje jako pełną nazwę obiektu.
Specyfikacje:
.CN=TOMASZ.OU=SERWIS.O=FIRMA oraz .CN=TOMASZ.OU=BIURO.O=FIRMA
są pełnymi nazwami dlatego, że zaczynają się od znaku kropki. Obie te nazwy w sposób
jednoznaczny określają, o jakie obiekty chodzi. Obie są poprawne dlatego, że zawierają
wszystkie elementy struktury NDS od obiektu wskazywanego TOMASZ do obiektu FIRMA
włącznie, a tak właśnie powinno być, gdyż obie specyfikacje zaczynają się od kropki. Nazwa
pełna może być podana niezależnie od bieżącego kontekstu i zawsze jednoznacznie określa jeden
i ten sam obiekt. Z inną sytuacją mamy do czynienia, gdy nazwa nie jest pełna. Załóżmy, że
kontekstem bieżącym jest .OU=SERWIS.O=FIRMA. Wtedy podanie nazwy w postaci:
CN=TOMASZ jest poprawne, gdyż jest to nazwa częściowa - odwołanie względne - które będzie
przez system doklejone do nazwy specyfikującej kontekst bieżący od strony lewej i to co
powstanie będzie traktowane jako nazwa pełna: .CN=TOMASZ.OU=SERWIS.O=FIRMA.
Pozostał do omówienia jeszcze jeden element konwencji nazewniczych - możliwość pomijania
kwalifikatora typu obiektów w jego nazwie. Jest to dosyć wygodny mechanizm, pozwala
bowiem na uniknięcie wypisywania dodatkowych znaków w odwołaniu do obiektu:
.TOMASZ.SERWIS.FIRMA
Niestety, w wielu przypadkach stosowanie tej techniki prowadzi do niejednoznaczności i
pomyłek, bowiem system sam próbuje uzupełnić nazwę bez typów o kwalifikatory typów.
System plików
Jedną z najważniejszych cech każdego systemu operacyjnego jest stosowany w nim system
plików. System NetWare zajmuje się wyłącznie dyskami sieciowymi - znajdującymi się w
serwerach. Zasoby lokalne - zarówno napędy dyskietek, jak i dysków twardych - nie są
zarządzane przez system sieciowy i ich obsługa zależy od systemu operacyjnego stacji roboczej.
Pliki i katalogi dysku sieciowego są w systemie NetWare udostępniane tak, żeby program
uruchomiony na stanowisku roboczym mógł korzystać z nich, jak z zasobów dysku lokalnego.
Mimo to, dane przechowywane na dysku sieciowym mają specyficzne cechy, nadane im w
systemie NetWare. Wynika to z wielodostępu i konieczności ochrony zasobów. Dane sieciowe
są zorganizowane hierarchicznie. Jednostkami nadrzędnymi w tej hierarchii są serwery plików komputery, do których dostęp chroniony hasłami mają tylko zarejestrowani użytkownicy.
Serwery są identyfikowane przez nazwę (co najmniej dwa znaki).
Na każdym serwerze dane są przechowywane w woluminach. Wolumin to przestrzeń dyskowa o
ustalonej wielkości, w której przechowuje się jedno drzewo katalogów. Wolumin jest logicznym
odpowiednikiem dysku DOS-owego (jedynie odpowiednikiem, ponieważ wolumin sieciowy
może składać się nawet z 32 fizycznych obszarów pamięci dyskowej). Obszary te mogą
znajdować się na różnych dyskach fizycznych przyłączonych do serwera plików. Ciekawą cechą
woluminu Novellowego jest możliwość powiększenia go bez konieczności ponownej instalacji
systemu. Każdy serwer posiada na swoich dyskach co najmniej jeden wolumin (a maks.64).
Każdy wolumin posiada swoją nazwę, unikalną w ramach danego serwera. Nazwa każdego
woluminu kończy się dwukropkiem. Jeden wolumin musi nazywać się SYS:, pozostałe zaś mogą
się nazywać dowolnie (nazwy te nadaje osoba instalująca serwer). Różne serwery NetWare
mogą mieć woluminy o tych samych nazwach (np. każdy serwer musi mieć wolumin SYS: ).
Nazwa woluminu może zawierać od dwóch do piętnastu znaków spośród znaków alfabetu,
znaków cyfr i następujących znaków specjalnych: ~, !, #, $, %, ^, &, (, ), -, _, {, }.
Pełne odwołanie do woluminu fizycznego powinno być poprzedzone nazwą serwera, na którym
został on zainstalowany, a separatorem dzielącym nazwę serwera od nazwy woluminu jest znak
'/' lub '\'. Tak więc poprawne odwołanie do fizycznego woluminu VOL1: ma postać:
SERWER_N/VOL1:
Tak podawane nazwy woluminów w serwerach NetWare są często określane jako tzw. nazwy
fizyczne woluminów, gdyż określają one gdzie fizycznie, tj. na dyskach którego serwera te
woluminy się znajdują i jak się nazywają. Takie nazewnictwo było zupełnie wystarczające w
starszych wersjach systemu NetWare (poniżej 4.0), gdzie dostęp do woluminów był zawsze
możliwy tylko poprzez dostęp do konkretnego fizycznego serwera, który zawierał dane
woluminy. Jednak koncepcja sieci bazującej na NetWare w wersji 4.0 i wyższych jest zupełnie
inna - mianowicie dostęp do systemu uzyskuje się przez dostęp do całej sieci (drzewa), a nie do
poszczególnych serwerów. Idąc dalej za tym rozumowaniem, dla przeprowadzanie operacji na
danych wcale nie jest potrzebny dostęp do serwera, który ma na swoich dyskach zainstalowany
dany wolumin, lecz tylko dostęp do woluminu jako takiego. Stąd też wyodrębniono w systemie
NetWare dwa obiekty logiczne. Jeden to serwer wraz z jego własnościami, a drugi to wolumin,
który oprócz własności opisujących go, posiada interesujący nas system plikowy. W tej sytuacji
dla dostępu do woluminu w NDS nie należy posługiwać się nazwami fizycznymi (bo te wiążą
serwer z woluminem) lecz nazwami logicznymi (które określają tylko wolumin). Zasada
budowania nazw logicznych jest nieskomplikowana - nazwę woluminu pozbawia się dwukropka
i dla jednoznaczności nazw poprzedza nazwą serwera ze znakiem podkreślenia. Jest to domyślny
sposób nazywania woluminów, aczkolwiek mogą być nazwane zupełnie inaczej.
Jak wspomniano, w trakcie instalacji serwera wraz z woluminami, zawsze jeden z nich musi
nazywać się SYS:. Nie jest to przypadek, gdyż w tym właśnie woluminie zakładane są specjalne
katalogi z plikami obsługującymi system. Zanim zostanie omówiona rola poszczególnych
katalogów, trzeba wyjaśnić dwie istotne sprawy. Po pierwsze pełna ścieżka w sensie struktury
katalogów,
określająca
przykładowy
podkatalog
o
nazwie
'DOS'
brzmi:
.CN=SSERWER_SYS.OU=SERWIS.O=FIRMA:\PUBLIC\DOS
Po drugie, struktura NDS kończy się na obiekcie SSERWER_SYS (kolor czerwony oznacza
adres w NDS), a dalej w głąb struktury mamy do czynienia z systemem plikowym (kolor zielony
oznacza ścieżkę w systemie plików), również uporządkowanym hierarchicznie. Ten wszakże
system plikowy nie jest częścią struktury NDS, jakby to mogło się mylnie wydawać. A zatem
specyfikacja pliku lub katalogu w sieci składa się z dwóch części. Pierwsza część, tzw.
obiektowa, zawiera poprawną według konwencji przyjętych w NDS specyfikację obiektu, jakim
jest wolumin. Druga część, związana ze strukturą plikową zawiera poprawną według konwencji
przyjętych w systemie DOS specyfikację pliku lub katalogu zawartego w woluminie, przyjmując
umownie za szczyt struktury plikowej właśnie ten wolumin. Obie części specyfikacji oddziela
się znakiem dwukropka. Jak widać jednak na przytoczonym przykładzie, specyfikacja katalogu
może być bardzo długa i skomplikowana. Dlatego sposób odwoływania się do plików i
katalogów przez podanie ścieżki do nich jest mało praktyczne i z tego powodu twórcy systemu
wprowadzili kilka mechanizmów upraszczających takie odwołania. Mechanizmy te bazują na
tym, że użytkownik w czasie sesji pracy w sieci na ogół korzysta z kilku, najwyżej kilkunastu
katalogów na różnych woluminach. Proponowane rozwiązanie (zresztą bardzo skuteczne) polega
na tymczasowym nazwaniu tych katalogów literami alfabetu i odwoływanie się do nich poprzez
te symbole, zamiast podawania całej specyfikacji. Technika ta zwana jest mapowaniem dysków
lub przypisywaniem napędów.
Rejestrowanie się w systemie - logowanie
Każdy użytkownik na początku pracy w sieci musi zostać rozpoznany i zaakceptowany przez
system. Użytkowanie sieci polega na realizacji jednej lub wielu sesji pracy z siecią.
Identyfikacja użytkownika odbywa się przez podanie nazwy systemowej użytkownika oraz
(ewentualnie) hasła. Jeżeli system odnajdzie dane dotyczące rejestrującego się użytkownika (w
swoim rejestrze użytkowników), to udostępni mu swoje zasoby w stopniu określonym uprzednio
przez administratora sieci. W ten sposób rozpocznie się sesja pracy w sieci NetWare.
Proces rejestrowania się do sieci jest też zwany logowaniem (od ang. login). Zarejestrować się
do sieci można na kilka sposobów:
• Z poziomu systemu DOS należy użyć polecenia LOGIN. Jego składnia jest następująca:
LOGIN <'nazwa_użytkownika'>
przy czym nazwa użytkownika musi zostać poprzedzona specyfikacją kontekstu w NDS
o ile kontekst bieżący nie jest tym, w którym umieszczono obiekt reprezentujący
użytkownika, np:
LOGIN .TOMASZ.SERWIS.FIRMA.
Logowanie z poziomu DOS jest obecnie wykorzystywane jedynie w wyjątkowych
sytuacjach, lecz znajomość pełnej nazwy użytkownika jest niezbędna np. do korzystania
z programów obsługi poczty.
• W celu zarejestrowania się do sieci pod Windows należy użyć programu NetWare Login
(lub Novell Login – w zależności od wersji klienta Novell). W oknie dialogowym należy
podać nazwę rejestrowanego użytkownika (pole Username) i jego hasło (pole Password),
jak również nazwę drzewa NDS (nie wszędzie ‘stara’ nazwa NDS została zastąpiona
przez NDS), serwera i kontekstu rejestrowanego użytkownika.
Podczas logowania wykonywany jest skrypt logowania (Login Script), którego zadaniem jest
przygotowanie środowiska pracy. Raport z wykonania skryptu można prześledzić w oknie
skryptu (należy wyłączyć opcję automatycznego zamykania okna skryptu -> okno logowania ->
zaawansowane -> zakładka Skrypt Logowania -> automatyczne zamykanie okna)
Kończenie pracy
Poprawne zakończenie sesji pracy z siecią NetWare polega na wydaniu polecenia LOGOUT
(DOS), lub wybraniu opcji odłączenia od drzewa (Windows).
Praca w Windows - ikona paska zadań NetWare
W okienkowych systemach graficznych (np. Windows) wraz z podstawowymi plikami klienta
NetWare instalowanych jest wiele narzędzi ułatwiających pracę w sieci Novell. ‘Centrum
dowodzenia’ jest tu ikona paska zadań Novell NetWare (Rys. 1).
Rys. 1. Pasek zadań Novell
Kolejne pozycje umożliwiają:
• Logowanie NetWare – zalogowanie do NetWare
• Połączenia NetWare – wyświetlenie aktualnych połączeń oraz wylogowanie z systemu
• Novell – Mapuj dysk sieciowy – przypisanie litery napędu do wybranego katalogu w
systemie plików NetWare, przez co katalog na serwerze jest widziany jako lokalny napęd.
Najważniejsze katalogi (głownie systemowe) są mapowane podczas logowania.
• Odłącz dysk sieciowy – odłączenie zamapowanego napędu. Przechwycenie i zakończenie
przechwytywania portu drukarki
• Programy usługowe NetWare – kopiowanie plików, wysyłanie wiadomości do innych
użytkowników, zarządzanie prawami do obiektów, zarządzanie skasowanymi plikami
(odpowiednikiem windowsowego kosza )
• Zarządzanie użytkownikami dla DRZEWO – edycję własności użytkowników (np. adresu,
haseł)
• Przeglądanie sieci, zmianę konfiguracji klienta Novell i inne
Praca z poziomu DOS – podstawowe polecenia
Mimo iż DOS sam w sobie nie jest zbyt często wykorzystywanym systemem, to polecenia
konsoli bywają przydatne, m.in. do tworzenie skryptów (podobnie jak ma to miejsce w
systemach unixowych). Praca z poleceniami konsoli jest również cenna z dydaktycznego punktu
widzenia, gdyż stosowanie tych poleceń wymaga dużo lepszej znajomości systemu niż w
przypadku ‘klikanych’ programów. Dla każdego z programów dostępna jest pomoc kontekstowa
po skorzystaniu z opcji /?, czyli:
polecenie /?
Zmiana kontekstu - polecenie CX
Zmiana kontekstu jest możliwa przy użyciu polecenia systemowego CX. Wykorzystuje się je
często przy pracy z poziomu konsoli lub w skryptach. Program CX.EXE (zmień kontekst)
pozwala sprawdzić kontekst bieżący, zmienić go na inny, a nawet pokazać na ekranie strukturę
NDS. Praktycznie wykorzystuje się następujące funkcje programu CX:
•
•
•
•
CX (bez parametrów) - sprawdź kontekst bieżący. Zwykle po uruchomieniu stacji
roboczej i załadowaniu klienta kontekstem bieżącym będzie [Root]
CX /T/R - wypisz całą strukturę NDS od jej szczytu począwszy poprzez wszystkie
obiekty kontenerowe,
CX /A /CONT - wypisz również informację o wszystkich obiektach, a nie tylko
kontenerach, zawartych w bieżącym kontekście,
CX nowy_ kontekst - zmień kontekst bieżący na nowy_kontekst, wyszczególniony jako
parametr polecenia. Zamiast nowego_kontekstu można wpisać '.' (kropkę) i będzie to
oznaczać skok w górę struktury NDS o jeden poziom, a '..' - skok w górę o dwa poziomy
itd.
Należy zwrócić uwagę, że pracując w Novell jesteśmy jednocześnie w dwóch ‘bieżących’
miejscach: w bieżącym katalogu (system plików) i bieżącym kontekście NDS. Nie wolno mylić
tych pojęć !!!
Wyświetlanie informacji o obiektach – polecenie NLIST
Polecenie to umożliwia wyświetlanie informacji o obiektach NDS. Możliwość zastosowania
filtrów czyni z niego niezwykle przydatne narzędzie, nierzadko przewyższające funkcjonalnością
narzędzia dla Windows (np. umożliwia wyświetlenie wszystkich zalogowanych użytkowników z
działu ‘Produkcja’, którzy nie korzystają z hasła dostępu).
Zarządzanie bazą NDS – program NetWare Administrator
Program NetWare Administrator jest jednym z narzędzi do zarządzania bazą NDS. Umożliwia
tworzenie obiektów, zmianę ich własności, uprawnień, itp. W dzisiejszym ćwiczeniu posłuży do
zapoznania się ze strukturą NDS.
Ćwiczenia:
I.
Zapoznać się z programami paska zadań NetWare:
1. Zapoznać się podstawowymi funkcjami klienta Novell (Pomoc klienta Novell)
2. Przećwiczyć logowanie i wylogowanie, obejrzeć rezultaty wykonania skryptu
logowania
3. Przećwiczyć mapowanie i odłączanie woluminów
4. Zapoznać się z własnościami obiektu użytkownik (Zarządzanie użytkownikami
dla PWSZ_TREE)
5. Przećwiczyć wysyłanie wiadomości (Programy usługowe NetWare)
6. Zmienić (i zapamiętać !!!) swoje hasło
II. Uruchomić NetWare Administratora (SYS:/Public/win32/mwadmn32.exe), zapoznać się z
budową bazy NDS (hierarchią kontenerów)
III. Uruchomić konsolę (wiersz poleceń). Wyświetlić, zapoznać się z opisem i sprawdzić
działanie poleceń: LOGIN, LOGOUT, CX, SETPASS, WHOAMI, SEND, NLIST. Opis
poleceń możemy wyświetlić wydając polecenie z opcją ‘/?’, np.:
LOGIN /?
CX /?
Wykorzystując odpowiednie polecenia (CX, NLIST, WHOAMI) wykonać poniższe
ćwiczenia :
1. Wyświetlić całą strukturę NDS począwszy od szczytu.
2. Sprawdzić bieżący kontekst.
3. Na dwa sposoby (adresowanie względne i bezwzględne) zmienić kontekst na inny.
4. Zmienić kontekst na .PWSZ, następnie wyświetlić listę użytkowników z bieżącego
kontenera i ze wszystkich jego podkontenerów.
5. Znaleźć w drzewie NDS użytkownika o podanej nazwie i wyświetlić jego adres
sieciowy.
6. Wyświetlić wszystkie informacje szczegółowe na temat użytkownika o podanej nazwie.
7. Wyświetlić (ze swojego kontenera) listę użytkowników spełniających podane kryteria
(np. wymaganą długość hasła wyższą lub równą 5, ‘Department’ = ‘Produkcja’,
‘Telephone’ = ‘12345’, ‘Locality’ = ‘PWSZ’)
8. Wyświetlić listę zalogowanych użytkowników z bieżącego kontekstu i jego
podkontenerów oraz ich imię, nazwisko i numer telefonu
9. Wyświetlić listę użytkowników, którzy ostatnio logowali się wczoraj lub później
10. Nie zmieniając kontekstu wyświetlić szczegółowe informacje na temat studentów z
innej grupy
11. Wyświetlić podstawowe informacje o sobie.
12. Za pomocą SEND wysłać wiadomość do jednego z użytkowników

Podobne dokumenty