Unix-miniprzewodnik
Tekst ten ma w zamierzeniu stanowić materiał uzupełniający do kursu Wstęp do UNIXa oraz podręczne kompendium dla użytkowników sieci unixowej w Ośrodku Komputerowym Wydziału Fizyki Uniwersytetu Warszawskiego. Nie stanowi on (ani nie będzie stanowić) wyczerpującego podręcznika użytkownika UNIXa, jak również nie zastąpi posługiwania się dokumentacją systemu (man, info).
Niniejszy miniprzewodnik jest obecnie w trakcie powstawania, uwzględnimy w nim odpowiedzi na pytania najczęściej stawiane przez użytkowników.
UWAGI OGÓLNE
W Ośrodku Komputerowym Wydziału Fizyki funkcjonują dwie, z grubsza niezależne, sieci komputerowe: sieć oparta na standardzie Novell Netware, w której terminale użytkowników pracują pod kontrolą systemu MS DOS/Windows, oraz sieć unixowa, w której użytkownik pracuje pod systemem operacyjnym Linux. Jako terminale dla użytkowników służą komputery PC znajdujące się w salach A i B (przeznaczonych do zajęć dydaktycznych) oraz C i D (sale pracy własnej). Każdy z tych komputerów może być uruchomiony zarówno w trybie Novell jak i w trybie unixowym -- w zależności od wyboru dokonanego z menu pojawiającego się bezpośrednio po włączeniu komputera (przed jakimkolwiek loginem).
Z punktu widzenia użytkownika najważniejsze cechy pracy w sieci komputerowej (w porównaniu z pracą na komputerze ,,wolnostojącym'' to:
• jednolity system kontroli dostępu, tzn. użytkownik otwierając sesję ,,przedstawia się'' systemowi tym samym identyfikatorem (nazwą konta, podawaną w odpowiedzi na zapytanie o login) oraz hasłem (podawanym w odpowiedzi na zapytanie o password) -- niezależnie od tego, z którym z terminali (PC) ma w danej chwili do czynienia;
Obowiązuje zasada przydzielania tych samych identyfikatorów konta (login) użytkownikowi do pracy zarówno w sieci Novell jak i unixowej; dla wygody przydziela się zazwyczaj takie same hasła początkowe (przy utworzeniu konta) do obu sieci, jednak są to hasła niezależne -- zmiana jednego z nich nie pociąga za sobą automatycznie zmiany drugiego.
• jednolite środowisko pracy, również niezależne od aktualnie używanego terminala -- dostęp do tych samych programów (zainstalowanych do wspólnego użytku) oraz plików własnych użytkownika, z każdej stacji;
W sieci unixowej na pliki własne użytkownika przeznaczony jest katalog o nazwie /home/nazwa_grupy/login; aktualnie katalogi te znajdują się na dysku sieciowym udostępnianym wszystkim terminalom przez serwer tempuson, komputer Sparc pracujący w systemie Sun Solaris 7.
Zawartość tego samego katalogu użytkownika widziana jest również w sesji Novell, jako zawartość dysku H:. Dla kont utworzonych w latach poprzednich, gdy dyski sieciowe widziane w sieci Novell były oddzielne od dysków udostępnianych w sieci unixowej, dawna zawartość dysku użytkownika Novell znalazła się w podkatalogu _okwf1_ katalogu /home/nazwa_grupy/login.
• możliwość łączności z Internetem bez szczególnych zabiegów dodatkowych -- a więc dostęp do usług takich, jak m. in. poczta elektroniczna i WWW.
Poczta elektroniczna dostępna jest spod sieci unixowej; dostępne programy pocztowe to np. pine i Netscape Mail. Adres użytkownika sieci OKWF ma postać login@tempac.okwf.fuw.edu.pl. Aktualnie serwerem poczty jest komputer tempac, by czytać pocztę najlepiej więc otworzyć sesję zdalną na tempac (p. Sieć i praca zdalna).
Dodatkowo w sieci unixowej dostępne są (dla pracy zdalnej) komputery tempac (Sparc, Sun Solaris 6), służący jako serwer poczty studenckiej (p. powyżej), oraz primus (Pentium III, Debian GNU/Linux), dostępny również z terminali znakowych Wyse ustawionych na II piętrze budynku głównego (koło Nowej Auli). Różnią się one nieco od pozostałych repertuarem dostępnego oprogramowania i są przeznaczone (w sensie bezpośredniej pracy) raczej dla użytkowników zaawansowanych.
Na Wydziale Fizyki funkcjonuje również ogólnowydziałowa sieć pracownicza. Konta i dyski sieciowe w sieci pracowniczej są oddzielone od sieci studenckiej. Konto w sieci pracowniczej może uzyskać magistrant na wniosek opiekuna naukowego; w sprawach z tym związanych należy zwracać się do administratorów sieci pracowniczej (pok. 231 na parterze).
KONTA I HASŁA
,,Zapomniałem swojego hasła, czy może Pan mi je podać?'' Stawianie takiego pytania administratorowi nie ma sensu. Ani administrator, ani nikt inny nie ma możliwości odczytania hasła dostępu do konta. Właściwy tekst w takiej sytuacji brzmi: ,,Zapomniałem swojego hasła, proszę o założenie mi nowego'' -- uprawnienia administratora pozwalają na zmianę hasła dowolnego użytkownika, bez potrzeby znajomości hasła dotychczasowego.
Natomiast każdy użytkownik może w dowolnej chwili zmienić swoje własne hasło (no, chyba że właśnie zapomniał jakie ono było). Służy do tego komenda passwd. Wywołuje się ją bez żadnych argumentów, wynikiem będzie zapytanie o stare hasło i, po jego weryfikacji, prośba o wprowadzenie (dwukrotne) nowego hasła. W wypadku pomyłki (nie wprowadzono dwukrotnie tego samego hasła) operacja się nie powiedzie i należy zacząć od nowa (od komendy passwd).
Po co wogóle są hasła? Oczywiście przede wszystkim po to, by dostęp do komputerów miały jedynie osoby uprawnione. Są też jednak i inne powody, wśród nich:
• miejsce na dysku dostępne użytkownikowi jest limitowane, na ogół nie chcemy aby ktoś inny korzystał z naszego limitu;
• nie chcemy również by ktoś -- czy to z niewiedzy, czy to ze złośliwości -- kasował nasze pliki;
• zazwyczaj nie chcielibyśmy by osoby postronne miały możliwość swobodnego czytania adresowanych do nas listów czy też wysyłania listów w naszym imieniu;
• działalność koleżanki/kolegi na komputerze może czasami naruszać regulamin pracowni lub tzw. ,,dobre obyczaje'' -- więc jeśli już musi, to niech lepiej to robi na własny a nie cudzy rachunek (w 99% takich przypadków da się ustalić z czyjego konta korzystano, trudniej jest ustalić jaka to osoba fizycznie siedziała przy terminalu);
itp. Stąd prosty wniosek: hasło chroni nie tylko system komputerowy ale również interes samego użytkownika. We własnym interesie należy więc unikać udostępniania hasła konta osobom postronnym, jak również stosowania haseł które łatwo odgadnąć (np. komuś kto wie jak się nazywa mój pies czy jak ma na imię moja dziewczyna/żona/narzeczony itd.).
Jakie więc reguły należy stosować przy wyborze hasła, aby było ono względnie ,,bezpieczne''? Po pierwsze, długość hasła ograniczona jest do ośmiu znaków. Dłuższe hasła są akceptowane przez system bez sprzeciwu, ale dalszy ciąg jest ignorowany (tj. nie podlega sprawdzaniu). Po drugie -- jak już wspomniano -- nie ma metody efektywnego ,,odszyfrowania'' haseł, istnieje jednak metoda ,,prób i błędów'' za pomocą której można próbować hasło ,,złamać'', czasami z powodzeniem. Metoda ta jest (statystycznie) dość skuteczna po pierwsze dzięki temu, że realizuje się ją oczywiście za pomocą odpowiedniego programu komputerowego, a komputery to obecnie dość szybkie bestie; a po drugie, dzięki naturalnej skłonności użytkowników do wybierania haseł ,,łatwych do zapamiętania''. Nieco upraszczając i nie wnikając w szczegóły techniczne: nieodporne na atak są hasła będące po prostu wyrazami występującymi w słownikach języka polskiego, angielskiego czy innych w miarę pospolitych; na pewno nie jest bezpieczne hasło identyczne z nazwą konta (loginem), czy będące np. tym samym loginem ale zapisanym wielkimi literami; itd. Prosta reguła mówi że hasło jest tym ,,lepsze'', im bardziej przypomina czysto losowy ciąg znaków. W osiągnięciu tego efektu pomaga np. mieszanie małych i wielkich liter, cyfr, czy wtrącenie znaków przestankowych.
Uwagi praktyczne
• W OKWF hasła dla komputerów unixowych (Linux: komputery w salach ćwiczeń i salach pracy własnej, primus; Sun Solaris: tempac) są obsługiwane przez sieciową bazę danych (NIS), a zatem na wszystkich tych komputerach obowiązują te same konta i hasła.
• Hasła w sieci unixowej OKWF i hasła w sieci Novell (tj. dla komputerów uruchamianych w trybie DOS/Windows) są niezależne, nawet jeżeli przy tworzeniu konta nadaje się im dla wygody te same wartości początkowe. Zmiana jednego z tych haseł nie skutkuje więc automatycznie zmianą drugiego.
• W hasłach unixowych rozróżniane są wielkie i małe litery.
PLIKI I SYSTEMY PLIKÓW
Plik (ang. file) jest podstawową jednostką przechowywania danych w komputerach, a dokładniej: na tzw. urządzeniach pamięci masowej wykorzystywanych przez komputery. W praktyce, urządzenia te to najczęściej:
• twarde dyski magnetyczne
• dyskietki magnetyczne
• płyty CD z zapisem optycznym
• taśmy magnetyczne.
System plików (ang. filesystem) to z kolei warstwa systemu operacyjnego pośrednicząca w dostępie do informacji zapisanej na pamięci masowej, a więc do plików właśnie. Dzięki systemowi plików użytkownik (czy raczej wykorzystywane przez niego programy) nie potrzebuje troszczyć się np. o to, gdzie fizycznie na dysku zapisana jest potrzebna informacja; zamiast tego, system plików udostępnia użytkownikowi pewną strukturę logiczną (drzewo katalogów), o wiele wygodniejszą jako forma organizacji zapisu danych niż byłoby np. bezpośrednie lokalizowanie pliku przez jego adresy na dysku (numery sektorów lub t.p.). Ponadto system plików zarządza pewnymi meta-danymi o plikach i udostępnia je programom, realizując zarazem np. mechanizmy kontroli dostępu do plików.
Drzewo katalogów
Podstawową strukturą w unixowych systemach plików jest wspomniane już drzewo katalogów: katalogi (ang. directory) to też rodzaj plików, lecz o specjalnym charakterze -- służą one nie bezpośrednio do przechowywania danych, lecz do przechowywania informacji o innych plikach. Drzewowy charakter struktury polega na tym, że każdy katalog posiada swój (jedyny) katalog nadrzędny (odwołać się do niego można przez specjalną nazwę ".."), natomiast sam może ,,zawierać'' na równych prawach zarówno inne katalogi, jak i pliki ,,zwyczajne''; te ostatnie stanowią ,,liście'' drzewa katalogów. Wyjątkiem jest katalog główny, stanowiący ,,korzeń'' tego drzewa; jako jedyny nie posiada on katalogu nadrzędnego, natomiast wszystkie katalogi (i pliki) dostępne w danej chwili są osiągalne przez podanie tzw. pełnej ścieżki dostępu, specyfikującej cały łańcuch kolejnych podkatalogów przez które należy przejść, aby odnaleźć pozycję katalogową odnoszącą się do danego pliku. Nazwy kolejnych podkatalogów w ścieżce dostępu oddziela się znakiem "/". Przykładowo:
• / oznacza sam katalog główny
• /vmlinuz oznacza plik o nazwie vmlinuz umieszczony w katalogu głównym
• /usr/bin/pico oznacza plik o nazwie pico umieszczony w katalogu bin, będącym podkatalogiem katalogu usr, który jest z kolei podkatalogiem katalogu głównego
itd.
Należy pamiętać, że drzewo katalogów jest pewną abstrakcją, ,,lokalizacja'' danego pliku w obrębie drzewa katalogów nie ma a priori wiele wspólnego z lokalizacją odpowiednich danych na urządzeniu (lub urządzeniach) fizycznych (tj. dyskach). W szczególności, jednolite drzewo katalogów jest na ogół ,,zszyte'' z kawałków odpowiadających różnym urządzeniom: partycjom dysków bezpośrednio podłączonych do danego komputera, dyskom udostępnianym przez serwery sieciowe, itp.
Komendy: przykłady
% pwd
/home/staff/rjb
% cd tmp ; pwd
/home/staff/rjb/tmp
% cd /tmp ; pwd
/tmp
% cd ; pwd
/home/staff/rjb
% mkdir kuku ; ls -al kuku
total 16
drwxr-sr-x 2 rjb rjb 4096 Nov 4 02:36 .
drwxr-sr-x 74 rjb rjb 12288 Nov 4 02:36 ..
% rmdir kuku ; ls -al kuku
ls: kuku: No such file or directory
% cd .. ; pwd
/home/staff
% _
Nazwy plików
Jak widać, każdy plik (a więc i katalog) posiada swoją nazwę, przy czym nazwa ta musi być unikalna ale jedynie w ramach określonego katalogu, tj. wystąpienia tej samej nazwy w różnych katalogach nie mają ze sobą a priori nic wspólnego -- odnoszą się do w zasadzie różnych plików. Jeśli chodzi o reguły tworzenia nazw plików, to zasada jest dość prosta: nazwy te są (niemal) całkowicie dowolne, mogą składać się z dowolnych znaków (właściwie bajtów), z wyjątkiem jedynie znaku "/" oraz bajtu zerowego; ponadto zastrzeżone są nazwy "." oraz "..", które pojawiają się automatycznie w każdym nowo utworzonym katalogu i odnoszą się odpowiednio do samego danego katalogu (pojedyncza kropka) i jego katalogu nadrzędnego (dwie kropki). Poza tym np. kropka jako element nazwy nie jest w żaden sposób wyróżniona, a małe i wielkie litery są rozróżnianie (i równie dozwolone) w nazwach plików. Z drugiej jednak strony, wiele programów użytkowych stosuje się do pewnych konwencji dotyczących nazw plików, a szczególnie co do tzw. końcówki nazwy -- ciągu znaków po ostatniej kropce. Np. o pliku o nazwie nazwa.c zakłada się, że zawiera kod źródłowy w języku C, podobnie nazwa.C lub nazwa.cpp powinien na mocy umowy zawierać kod źródłowy w C++ (konwencje stosowane przez kompilatory), nazwa.html zawierać powinien tekst strony WWW w języku HTML (konwencja serwera WWW), itp. Podkreślić należy jednak, że są to konwencje które nie mają wpływu na sposób traktowania tych nazw przez sam system plików.
Ważnym przypadkiem takie konwencji są nazwy zaczynające się od kropki (np. .login czy .profile). Pliki o takich nazwach to tzw. pliki ukryte; nie są one np. domyślnie uwzględniane w spisie zawartości katalogu wypisywanym przez komendę ls. Są one najczęściej wykorzystywane do zapisu osobistych ustawień użytkownika dotyczących poszczególnych używanych przez niego programów, i często są tworzone automatycznie przez te programy, a ,,ukrywane'' są po prostu dla wygody: ponieważ rzadko potrzebujemy korzystać z nich bezpośrednio, uwzględnianie ich w spisach zawartości katalogów tworzyłoby jedynie zbędny ,,szum informacyjny''. Znowu jednak sam system nie traktuje ich w żaden szczególny sposób, i w razie potrzeby możemy mieć do nich bezpośredni dostęp na ogólnych zasadach.
Długość nazwy pliku (liczba znaków z której się składa) nie jest oczywiście nieograniczona, konkretna wartość tej granicy zależy od systemu: np. typowo w Linuxie maksymalna długość nazwy pliku to 255 znaków, a maksymalna długość pełnej ścieżki dostępu do pliku to 4095 znaków (patrz /usr/include/linux/limits.h).
W praktyce, dobierając nazwy dla tworzonych przez nas plików, warto przestrzegać wspomnianych konwencji nazewniczych oraz mimo wszystko unikać stosowania w nazwach znaków ,,specjalnych'', takich jak posiadające szczególne znaczenie dla shella (interpretera komend): takimi są np. *,?,!,<,>,|,\,$ oraz spacja. ,,Bezpieczne'' są nazwy składające się ze znaków alfanumerycznych oraz niektórych znaków przestankowych, takich jak kropka, - (minus), _ (znak podkreślenia). Wprawdzie stosowanie innych znaków nie jest zakazane, lecz nazwy je zawierające mogą sprawiać kłopoty ze względu na konieczność pamiętania o tym, by ,,chronić'' je odpowiednio przed interpretacją przez shell oraz z powodu ograniczeń występujących w niektórych, nie całkiem ,,porządnie'' napisanych programach, które mogą nie traktować ich poprawnie.
Dowiązania ,,twarde'' i ,,miękkie'' (symboliczne)
W rzeczywistości, katalogi nie tyle ,,zawierają'' same pliki, co pewne meta-dane opisujące te pliki (i umożliwiające dostęp do danych zapisanych w tych plikach). Fakt ten ma istotną konsekwencję praktyczną: jednemu i temu samemu plikowi (jako zbiorowi danych) może odpowiadać więcej niż jeden wpis, w tym samym lub w różnych katalogach, i sytuacja taka jest całkowicie legalna. Mówimy wtedy o ,,twardych dowiązaniach'' (ang. hard links). Wszystkie takie dowiązania, tj. różne pozycje katalogowe wskazujące na te same zbiory danych, są równoprawne; usunięcie jednego z nich nie spowoduje utraty dostępu do odpowiadających mu danych (tj. ich ,,skasowania''), dopóki nie zostanie usunięte ostatnie takie dowiązanie. Dopiero wtedy miejsce na dysku zajmowane przez te dane zostanie dołączone do ,,mapy wolnej przestrzeni'' utrzymywanej przez system, i (w trudnym do przewidzenia czasie) zostanie ponownie wykorzystane na zapis kolejnych danych.
Nie ma prostego sposobu, by ustalić jakie konkretnie twarde dowiązania do danego pliku istnieją w określonej chwili. Łatwo dostępna jest jedynie informacja o liczbie istniejących twardych dowiązań. Istnienie twardych dowiązań podlega ponadto pewnym ograniczeniom: większość systemów unixowych nie pozwala na tworzenie twardych dowiązań do katalogów (w odróżnieniu do plików ,,zwyczajnych'', a to ze względu na możliwość wytworzenia ,,pętli'' dowiązań); co ważniejsze jednak, wszystkie twarde dowiązania do danego pliku muszą znajdować się w poddrzewie drzewa katalogów odpowiadającym temu samemu fizycznemu urządzeniu (np. partycji dyskowej).
To ostatnie ograniczenie nie obowiązuje w przypadku dowiązań ,,miękkich'', zwanych też symbolicznymi (ang. soft links, symbolic links). W odróżnieniu od dowiązania twardego, dowiązanie symboliczne nie jest równoprawnym wpisem katalogowym wskazującym na dany plik, lecz specjalnym typem pliku, zawierającym jedynie informację o innym wpisie katalogowym na który wskazuje (zamiast wskazywać ,,bezpośrednio'' na plik). Usunięcie dowiązania symbolicznego w żadnym przypadku nie stanowi ,,skasowania'' odpowiednich danych, za to możliwa jest sytuacja, gdy dowiązanie symboliczne wskazuje ,,w próżnię'', tj. na nieistniejącą pozycję katalogową. Z tymi zastrzeżeniami, z dowiązania symbolicznego można korzystać tak samo jak z ,,prawdziwej'' pozycji katalogowej wskazującej na plik. W tym przypadku nie obowiązuje również zakaz tworzenia dowiązań wskazujących na katalogi. Tworzenie ,,łańcucha'' kolejnych dowiązań symbolicznych również jest legalne, lecz długość (liczba ,,ogniw'') takiego łańcucha podlega ograniczeniom.
Operacje na linkach
$ echo Hello, World > hello ; ls -l
total 4
-rw-r--r-- 1 rjb rjb 13 Nov 5 23:08 hello
$ ln hello hi ; ls -l
total 8
-rw-r--r-- 2 rjb rjb 13 Nov 5 23:08 hello
-rw-r--r-- 2 rjb rjb 13 Nov 5 23:08 hi
$ cat hi
Hello, World
$ echo It\'s a beautiful day >> hi ; cat hello
Hello, World
It's a beautiful day
$ rm hello ; ls -l
total 4
-rw-r--r-- 1 rjb rjb 34 Nov 5 23:13 hi
$ ln -s hi hello ; ls -l
total 4
lrwxrwxrwx 1 rjb rjb 2 Nov 5 23:15 hello -> hi
-rw-r--r-- 1 rjb rjb 34 Nov 5 23:13 hi
$ echo Good night > hello ; cat hi
Good night
$ rm hi ; ls -l
total 0
lrwxrwxrwx 1 rjb rjb 2 Nov 5 23:15 hello -> hi
$ cat hello
cat: hello: No such file or directory
$ _
Kontrola dostępu
Komputer unixowy z założenia ma umożliwiać pracę wielu użytkownikom (i to równocześnie), stąd też bierze się konieczność istnienia mechanizmów kontroli dostępu do danych zapisanych na pamięciach masowych (dyskach). Mechanizm taki w standardowej wersji, realizowanej we wszystkich unixowych systemach plików, jest dość prosty:
• każdy plik jest ,,własnością'' któregoś z użytkowników, oraz jest przypisany do którejś z grup użytkowników
• prawa do działań na pliku przysługujące użytkownikowi są zróżnicowane, w zależności od przynależności użytkownika do trzech kategorii (w stosunku do danego pliku); otóż określa się prawa dostępu przysługujące
1. właścicielowi danego pliku (u jak user)
2. członkom grupy do której przypisany jest plik (g jak group)
3. i wreszcie wszystkim użytkownikom systemu (o jak other)
(wydawać by się mogło przesadą ograniczanie praw właściciela do jego własnych plików, daje to jednak pewną ochronę przed skutkami własnych błędów; naturalnie, właściciel pliku może sobie w każde chwili przyznać dowolne prawa dostępu do swoich własnych plików)
• w ramach każdej z powyższych kategorii może być przyznane lub nie każde z trzech rodzajów uprawnień dostępu do pliku:
1. prawo do odczytu informacji zapisanej w pliku (r jak read)
2. prawo do zapisu, a więc do jakiejkolwiek modyfikacji zawartości pliku (w jak write)
3. prawo do uruchamiania pliku jako programu (co oczywiście nie uda się i tak jeżeli nie umożliwia tego zawartość pliku... x jak execute)
Jako że są trzy rodzaje uprawnień i trzy kategorie użytkowników, daje to w sumie dziewięć pozycji, które przyjęto reprezentować jako dziewięć bitów (bit ,,ustawiony'' czyli równy jeden oznacza oczywiście przyznanie danego prawa, a wartość zerowa odmowę), co jest równoważne trzem cyfrom układu ósemkowego. Oznaczają one kolejno: prawa właściciela (u), prawa grupy (g) oraz prawa ogólne (o), a wartość każdej z nich powstaje przez dodanie liczby cztery (jeżeli przysługuje prawo odczytu) do liczby dwa (jeżeli przysługuje prawo zapisu) i do liczby jeden (jeżeli przysługuje prawo uruchamiania); jak widać, otrzymuje się wartość między 0 a 7, gdzie 0 reprezentuje brak jakichkolwiek uprawnień a 7 -- pełne prawa.
Pewnej uwagi wymaga interpretacja praw dostępu w zastosowaniu do katalogów. Z katalogami związany jest taki sam zestaw bitów uprawnień jak ze ,,zwykłymi'' plikami, przy czym brak prawa x (uruchamiania) ma znaczenie zakazu jakiegokolwiek dostępu do zawartości danego katalogu (oraz jego podkatalogów). Należy też mieć na uwadze, że operacje utworzenia pliku czy też jego skasowania (usunięcia z katalogu) nie są operacjami na zawartości pliku, lecz na zawartości odpowiedniego katalogu, możliwość ich wykonania uwarunkowana jest więc prawami dostępu danego użytkownika nie do samego pliku, a do katalogu w którym się on znajduje.
Z dowiązaniami symbolicznymi nie są natomiast związane żadne prawa dostępu; ponieważ dowiązanie takie jest jedynie wskazaniem na jakąś inną pozycję katalogową, to obowiązują prawa dostępu określone dla pliku na który dowiązanie wskazuje. Natomiast (jak wspomniano powyżej) operacje utworzenia czy usunięcia dowiązania są operacjami dotyczącymi katalogu w którym ono się znajduje.
Prawa dostępu: przykłady
$ echo Hello, World > hello ; ls -l
total 4
-rw-r--r-- 1 rjb rjb 13 Nov 7 23:36 hello
[ standardowe prawa: odczytu i zapisu dla właściciela,
tylko odczytu dla grupy i reszty ]
$ chmod u-w hello ; ls -l
total 4
-r--r--r-- 1 rjb rjb 13 Nov 7 23:36 hello
[ odebrałem sobie prawo do zapisu, czyli modyfikacji ]
$ chmod 400 hello ; ls -l
total 4
-r-------- 1 rjb rjb 13 Nov 7 23:36 hello
[ teraz tylko ja mam prawo odczytu ]
$ chmod 666 hello ; ls -l
total 4
-rw-rw-rw- 1 rjb rjb 13 Nov 7 23:36 hello
[ prawo odczytu i zapisu dla wszystkich ]
$ chmod go-w hello ; ls -l
total 4
-rw-r--r-- 1 rjb rjb 13 Nov 7 23:36 hello
[ przywróciłem stan początkowy ]
$ echo '#!/bin/sh' > hello ; echo 'echo Hello, World' >> hello ; cat hello
#!/bin/sh
echo Hello, World
[ stworzyłem najprostszy skrypt shellowy ]
[ a teraz zrobię z niego program wykonywalny ]
$ chmod +x hello ; ls -l
total 4
-rwxr-xr-x 1 rjb rjb 28 Nov 7 23:47 hello
$ ./hello
Hello, World
[ i rzeczywiście, działa ! ]
Jak widać na powyższych przykładach, komenda chmod, służąca do zmiany praw dostępu, akceptuje instrukcje zarówno w postaci symbolicznej, określającej czy dane uprawnienie (r, w, x) należy przyznać (+) czy odebrać (-) i komu (u, g, o), jak i w postaci bezwzględnej, polegającej na podaniu kodu ósemkowego docelowej postaci żądanych praw dostępu do pliku.
Uwaga: prawa dostępu dotyczą samego pliku, a nie danej pozycji katalogowej. Oznacza to tyle, że w sytuacji istnienia wielu twardych dowiązań do jednego pliku prawa dostępu nie będą się dla nich różniły.
Limit miejsca czyli quota
Limitowanie przestrzeni dyskowej nie tylko zapobiega ,,antyspołecznym'' zachowaniom użytkowników; jest ono również zabezpieczeniem przed sytuacją, gdy błędnie zachowujący się program zapełnia całe dostępne miejsce na dysku bezużytecznymi wynikami lub komunikatami o błędach. Trzeba jednak przyznać, że stosowanie (dość niskich) limitów przestrzeni dyskowej na użytkownika wynika zazwyczaj głównie z braku środków na zakup większych dysków.
Limity zapisu czyli quota dotyczą każdego urządzenia pamięci masowej (partycji dyskowej) osobno, i zazwyczaj stosowane są przede wszystkim do partycji będącej nośnikiem poddrzewa /home, zawierającego katalogi własne użytkowników. Zresztą zazwyczaj ,,szeregowemu'' użytkownikowi prawo do zapisu plików przysługuje jedynie w obrębie jego katalogu własnego oraz katalogów takich, jak /tmp czy /var/tmp, przeznaczonych do zapisu plików tymczasowych.
Limity zapisu są dwojakiego rodzaju: tzw. miękki limit (ang. quota), którego ,,miękkość'' polega na tym, że może on być przekroczony, choć jedynie przez ograniczony czas (zazwyczaj tydzień). Po przekroczeniu tego czasu dalsze operacje zapisu zlecane przez danego użytkownika zostają zablokowane, dopóki nie zmniejszy on wykorzystania przestrzeni dyskowej poniżej wartości quoty. Limit ,,twardy'' (ang. limit) z kolei nie może zostać przekroczony: system od razu odmawia wykonania operacji zapisu powodującej przekroczenie limitu.
Ponadto zarówno quota jak i limit mogą dotyczyć dwóch różnych wielkości: ilości zajętego miejsca na dysku (liczonej np. w kB), oraz liczby zajętych inodów (w uproszczeniu, chodzi o liczbę plików wytworzonych przez użytkownika, niezależnie od ich wielkości). Zazwyczaj praktyczne znaczenie ma ograniczenie w kilobajtach, przekroczenie granicy liczby inodów jest w praktyce mało prawdopodobne.
Aktualnie w OKWF quota dla kont studenckich wynosi standardowo 10 MB, natomiast limit -- 12 Mb.
Do ustalenia stanu wykorzystania swojej quoty służy komenda quota. Wywołana bez opcji wypisze informację jedynie jeżeli quota jest aktualnie przekroczona, natomiast w postaci quota -v poinformuje użytkownika o stanie wykorzystania jego ,,przydziału'' w każdym przypadku.
Najczęstsze przyczyny bezwiednego przekroczenia limitów dyskowych to:
• pliki core zawierające zrzut zawartości pamięci programu, który ,,zginął tragicznie'' w trakcie wykonywania, tj. wykonał niedozwoloną operację i został zakończony przez system, co zwykle jest skutkiem błędów w danym programie. Pliki core przydają się, jeżeli mamy zamiar analizować błędny program który je produkuje w celu naprawy jego usterek; jeżeli nie mamy takiego zamiaru, plik o nazwie core można bez wahania usunąć.
• działalność programu Netscape, zapisującego znaczne ilości plików tymczasowych w katalogu ~/.netscape/cache. W wypadku natrafienia na ten problem, należy sprawdzić w ustawieniach Netscape wielkość limitu miejsca przeznaczonego na cache dyskowy przez ten program, i ewentualnie limit ten zmniejszyć. Zawartość katalogu ~/.netscape/cache można w razie potrzeby bezkarnie usunąć (program Netscape nie powinien być w tym momencie włączony).
Jedną z przykrych konsekwencji przekroczenia limitu dyskowego jest niemożliwość otwarcia sesji użytkownika na terminalu graficznym (X Window System). Zainicjowanie sesji wiąże się bowiem z zapisaniem paru plików w katalogu użytkownika (co nie ma miejsca w przypadku otwierania sesji na terminalu znakowym). Rozwiązanie polega więc na otwarciu sesji na terminalu znakowym i usunięciu plików powodujących przekroczenie limitu. Na PC linuxowych dostęp do trybu terminala znakowego uzyskuje się zazwyczaj przez kombinację klawiszy Ctrl-Alt-F[1-6], tj. należy wcisnąć równocześnie klawisze Ctrl, Alt (lewy) oraz jeden z klawiszy oznaczonych F1, F2, ...F6. Powrót do trybu graficznego następuje przez naciśnięcie Alt-F7.
PROGRAMY I PROCESY
Uruchamianie programów jest podstawową czynnością wykonywaną przez użytkownika komputera; warto więc od początku zrozumieć parę pojęć z tym związanych.
Program rozumiemy tu jako plik wykonywalny, a więc taki, który system potrafi uruchomić, np. w reakcji na działanie użytkownika. Działaniem tym może być np. wypisanie nazwy tego pliku w linii komend shella (interpretera komend) lub (w środowisku okienkowym) kliknięcie na ikonę powiązaną z danym programem.
Procesem z kolei jest instancja działającego programu, która powstała w wyniku jego uruchomienia. W danej chwili może istnieć i działać wiele różnych procesów, będących wynikiem uruchomienia tak tego samego, jak i różnych programów, przez wielu różnych użytkowników. Dlatego m. in. należy rozróżniać pomiędzy procesem a programem. Każdy proces posiada przydzielony przez system, jednoznaczny (w danej chwili czasu) numeryczny identyfikator (PID) i wykonuje się w zasadzie niezależnie od innych procesów, działających na tym samym komputerze; może się jednak z nimi komunikować, za pośrednictwem całego szeregu mechanizmów komunikacji międzyprocesowej zapewnionych przez system operacyjny.
Programy
Aby plik mógł być uruchomiony jako program, muszą być spełnione dwa warunki:
• Użytkownikowi uruchamiającemu program musi przysługiwać prawo do uruchamiania danego pliku
• Zawartość pliku musi być odpowiednia.
Pierwszy warunek został omówiony w rozdziale o plikach; drugi warunek jest spełniony, gdy plik programu powstał w wyniku kompilacji i linkowania kodu źródłowego (napisanego w jakimś języku programowania, takim jak C, Fortran, Pascal, ...) przez odpowiedni kompilator (mówimy wówczas o programie binarnym). Jest on spełniony również, jeżeli plik zawiera tekst instrukcji w języku interpretowanym (takim jak język shella sh, Perl, Python, ...), program interpretujący ten język jest właściwie zainstalowany na systemie, a treść pierwszej linijki pliku zbudowana jest według wzoru
#! /bin/sh
tj. zawiera jako dokładnie dwa pierwsze znaki sekwencję #!, a po nich następuje pełna ścieżka dostępu do programu interpretującego. Taki program nazywa się często skryptem.
Programy binarne przeznaczone do wspólnego użytku zainstalowane są w katalogach ogólnosystemowych, takich jak /bin (programy niezbędne do uruchomienia systemu), /usr/bin (większość narzędzi przeznaczonych dla użytkowników), /usr/local/bin (programy spoza ,,oficjalnej" zawartości systemu operacyjnego), /usr/X11R6/bin (programy związane ze środowiskiem okienkowym X Window System), /usr/dt/bin (programy związane ze środowiskiem graficznym CDE stosowanym w systemie Sun Solaris). Każdy plik spełniający warunki opisane powyżej może być jednak uruchomiony (niezależnie od jego lokalizacji) poprzez podanie w linii komend specyfikacji ścieżki dostępu (zamiast tylko nazwy pliku); np. uruchomienie programu o nazwie np. mojprog znajdującego się w katalogu aktualnym (nie będącym jednym z katalogów systemowych) wymaga na ogół podania komendy w postaci
./mojprog
Nazwa uruchamianego pliku jest generalnie bez znaczenia, w szczególności Unix nie przywiązuje wagi do tzw. końcówki nazwy programu (nie spotyka się programów zapisanych w plikach o nazwach kończących się na .EXE, .BAT czy .COM).
Procesy i interpreter komend
Najprostszym sposobem stworzenia procesu przez użytkownika jest uruchomienie (legalnego) pliku wykonywalnego, przez podanie jego nazwy (lokalizacji) w linii komend. W wielu przypadkach, w zależności od uruchamianego programu można też (lub należy) podać opcje dla programu oraz argumenty -- będące często (choć nie zawsze) nazwami plików które mają być przetworzone. Dla większości programów obowiązuje zasada, że bezpośrednio po nazwie (lokalizacji) programu podajemy ew. opcje uruchomienia; mają one najczęściej postać skrótów jednoliterowych poprzedzonych znakiem - (minus), np. ls -l, przy czym w wypadku podawania kilku opcji jednocześnie można je grupować: np. zamiast ls -l -A można równoważnie napisać ls -lA. Ewentualne argumenty podawane są po opcjach, np. ls -Al /tmp.
Należy wiedzieć, że zawartość linii komend podlega pewnej interpretacji i ,,obróbce'' przez shell (interpreter komend) zanim opcje i argumenty zostaną przekazane uruchomionemu programowi. W dużym uproszczeniu: treść linii komend jest dzielona na ,,słowa'' (sekwencje znaków oddzielone ciągami spacji), i każde ,,słowo'' będzie potraktowane jako oddzielny argument (lub grupa opcji); po czym następuje interpretacja pewnych znaków specjalnych (metaznaków). Przytoczę tu jedynie najprostsze (i najczęściej przydatne) przykłady zastosowania rozwinięć metaznaków:
• znaki *, ? oraz sekwencje postaci [...] stosowane są do tworzenia wzorców nazw plików; w takim wzorcu, * zastępuje dowolny ciąg (zera lub więcej) znaków, ? dowolny (ale dokładnie jeden) znak, np. [bpdt] dowolny pojedynczy znak spośród wymienionych (a więc tu: b, p, d lub t), np. [b-k] dowolny pojedynczy znak z podanego zakresu (tu: od b do k). Zakres znaków wyznaczony jest tu przez zakres wartości ich kodów ASCII; warto więc wiedzieć, że w kodowaniu ASCII wszystkie cyfry występują w porządku (0-9), poprzedzając wszystkie wielkie litery (A-Z), występujące w porządku alfabetycznym, które z kolei poprzedzają wszystkie małe litery (a-z), również występujące w porządku alfabetycznym. Bezpośrednio po znaku [, znak ^ ma znaczenie dopełnienia (podanego zbioru lub zakresu znaków), tak np. [^a-z] oznacza dowolny znak nie bedący małą literą.
Interpretacja tak utworzonych wzorców polega na ich zastąpieniu przez listę nazw istniejących plików, pasujących do podanego wzorca. Znak separatora katalogów (/) nie jest nigdy wynikiem rozwinięcia, tzn. wynikiem interpretacji wzorca nie zawierającego znaku / mogą być wyłącznie nazwy plików z katalogu aktualnego. Można jednak tworzyć również wzorce zawierające /; będą one interpretowane zgodnie z ogólnymi regułami specyfikowania lokalizacji plików (p. Pliki i systemy plików).
• ,,Słowa'' zaczynające się od znaku tyldy (~) interpretowane są jako katalog ,,domowy'' aktualnego użytkownika (sam znak ~ lub sekwencja ~/), lub jako katalog ,,domowy'' użytkownika o nazwie (loginie) która następuje po ~, np. ~rjb: ścieżka do katalogu domowego użytkownika rjb. Znak ~ występujący w pozycji innej niż na początku słowa nie podlega specjalnej interpretacji.
• Sekwencja rozpoczynająca się od znaku $ zastępowana jest przez wartość zmiennej shella, której nazwa następuje po $; np. polecenie echo $PATH wypisuje aktualną wartość zmiennej PATH (a nie napis $PATH).
• Znaki ", ' (cudzysłów i apostrof) oraz \ służą do ,,ochrony'' innych metaznaków przed interpretacją przez shell, w przypadku gdy powinny one być przekazane do uruchamianego programu w postaci dosłownej. Znak \ ,,chroni'' znak po nim następujący; para apostrofów '...' zapobiega interpretacji wszelkich metaznaków (z wyjątkiem samego apostrofu); para cudzysłowów "..." ,,chroni'' spacje i metaznaki tworzące wzorce nazw plików, natomiast nie zapobiega interpretacji znaku $.
Inny użyteczny trik to komenda1 `komenda2`, działa on następująco: jako pierwsza zostanie wykonana komenda2 (może ona oczywiście zawierać również argumenty), wynik jej wykonania -- to, co normalnie pojawiłoby się na ekranie, tj. zawartość standardowego strumienia wyjściowego -- zostanie umieszczony w linii komend wywołującej komenda1, która następnie zostanie wykonana (z zastosowaniem pozostałych reguł rozwijania).
Shell umożliwia również edycję linii komend, oraz odwoływanie się do komend wpisanych uprzednio (klawisz ,,strzałka w górę''), z możliwością ich edycji (modyfikacji) przed ponownym wykonaniem. Wśród innych udogodnień ułatwiających pracę interakcyjną warto wymienić tzw. autouzupełnianie (nazw komend i argumentów); w szczegółach jego działanie różni się w zależności od używanej wersji shella i opcji konfiguracyjnych, ale zazwyczaj pozwala ono na użycie klawisza ,,Tab'' po wpisaniu części nazwy komendy, lub nazwy pliku mającej być argumentem, czego wynikiem jest uzupełnienie tej nazwy o dalsze znaki na tyle, na ile jest to jednoznacznie możliwe (tj. jeżeli do początkowych kilku znaków pasuje nazwa tylko jednego faktycznie istniejącego pliku, to pojawi się ona na linii komend w całości).
W istocie shell jest interpreterem dość zaawansowanego języka programowania, potrafiącym wykonywać programy bezpośrednio z plików tekstowych, zwanych skryptami shella. Język ten zawiera w zasadzie wszystkie elementy przydatne do tworzenia nawet dość rozbudowanych programów (zmienne, pętle, instrukcje warunkowe, możliwość definicji funkcji ...); bardziej szczegółowe jego omówienie wykracza jednak poza zakres niniejszych notatek. Wspomnę jedynie, że składnia języka shella różni się dość istotnie w zależności od typu shella; używany jako domyślny do pracy interakcyjnej w naszej sieci tcsh nie jest szczególnie godny polecenia (w dość powszechnej opinii) do tworzenia bardziej rozbudowanych skryptów; do tego celu zazwyczaj używa się bardziej standardowego sh, lub będącego domyślnym w większości instalacji Linuxa shella bash.
Z bardziej zaawansowanych właściwości shella omówię tu pobieżnie jedynie dwie: kontrolę zadań, oraz przekierowania i potoki. Kontrola zadań stwarza możliwość uruchamiania procesów ,,w tle'', tj. z natychmiastowym powrotem do shella i możliwością wydawania kolejnych poleceń bez czekania na zakończenie uruchomionego właśnie procesu, ,,zawieszania'' wykonania aktualnie działającego procesu oraz żonglowania na rozmaite sposoby grupą zadań uruchomionych z aktualnej instancji shella. Jest to szczególnie przydatne w przypadku uruchamiania długotrwałych procesów, które wykonują się bez potrzeby interakcji z użytkownikiem, oraz przy uruchamianiu programów które np. tworzą własne okna graficzne i poprzez nie komunikują się interakcyjnie z użytkownikiem. Uruchomienie procesu w tle dokonuje się przez zakończenie linii komend znakiem &, postawionym po wszystkich argumentach do polecenia i ew. przekierowaniach (p. poniżej). Do ,,zawieszenia'' procesu aktualnie działającego ,,w pierwszym planie'' służy zazwyczaj sekwencja klawiszy Ctrl-z; w odróżnieniu od procesu uruchomionego ,,w tle'', proces zawieszony wstrzymuje działanie i czeka na ewentualne ,,odwieszenie''. Listę zadań związanych z aktualnym shellem (zawieszonych i uruchomionych w tle) można obejrzeć komendą jobs; każde zadanie z tej listy będzie opatrzone numerem identyfikacyjnym, z którego można skorzystać do wydawania poleceń zmieniających stan danego zadania. Polecenie fg %n (gdzie n jest tym numerem identyfikacyjnym) przenosi dane zadanie do ,,pierwszego planu'', zarazem je wznawiając (o ile było ono zatrzymane); natomiast bg %n wznawia wykonywanie zadania zawieszonego, pozostawiając je ,,w tle''.
Mechanizm przekierowania i potoków pozwala z kolei na proste wykonywanie nawet dość złożonych operacji przetwarzania danych poprzez łączenie w ,,łańcuszek'' szeregu prostych komend, z których każda wykona jeden z etapów przetwarzania przekazując wynik następnej w celu wykonania koleknek operacji. Korzysta tu się z faktu, że z każdym procesem unixowym związane są trzy tzw. standardowe strumienie wejścia-wyjścia: standardowe wejście (stdin), standardowe wyjście (stdout) i standardowy strumień błędu (stderr). Domyślnie, stdin utożsamiony jest z klawiaturą terminala, a stdout i stderr -- z ekranem. Tzn. np. że dane wyprowadzone przez program na stdout pojawią się na ekranie użytkownika. Większość standardowych programów narzędziowych, stanowiących podstawowe wyposażenie systemu unixowego, potrafi czytać dane wejściowe zarówno z plików (z dysku), jak i ze strumienia stdin, natomiast wyniki przetwarzania wyprowadza domyślnie na strumień stdout. Strumień stderr służy natomiast do wypisywania komunikatów nie będących ,,normalnym'' wynikiem przetwarzania danych, tj. komunikatów o błędach i ew. ostrzeżeń o sytuacjach mniej lub bardziej ,,anomalnych''.
Dla przykładu, komenda sort służy do sortowania (domyślnie: alfabetycznego) linijek tekstu stanowiących dane wejściowe. Gdy się ją wywoła z argumentami będącymi nazwami plików, danymi do sortowania będzie zawartość tychże; w przypadku wywołania bez argumentów (nie będących opcjami, za pomocą których można zadać bardziej złożone kryteria sortowania), komenda sort oczekuje, że dane do przetworzenia pojawią się w standardowym strumieniu wejściowym. W obu tych przypadkach, wynik sortowania pojawi się na stdout.
Mechanizm o którym mowa polega na udostępnieniu możliwości przedefiniowania standardowych strumieni, na dwa sposoby: bądź przez połączenie ich z plikami, bądź przez połączenie stdout jednego procesu z stdin innego. Konstrukcja komenda ... > plik powoduje, że zawartość stdout wywołanej komendy, zamiast na ekranie, pojawi się w pliku o podanej nazwie (w miejscu wielokropka umieścić można dowolne opcje i inne argumenty wywołania); podobnie komenda ... < plik spowoduje, że zawartość podanego pliku będzie stanowiła stdin wywołanej komendy. Z kolei pisząc komenda1 ... | komenda2 ... sprawimy, że dane wyprowadzone przez komenda1 na jej stdout staną się zawartością stdin dla komenda2. Wszystkich tych rodzajów przekierowania można też użyć łącznie, np.: komenda1 < plik1 | komenda2 > plik2.
Uwagi:
• Jeśli zastosujemy przekierowanie komenda .. > plik, a plik już istnieje, to jego wcześniejsza zawartość zostanie zastąpiona przez zawartość stdout wywołanej komendy -- tj. utracona! Istnieje druga postać przekierowania stdout: komenda ... >> plik, przy której zawartość stdout wywołanej komendy nie zastępuje ew. wcześniejszej zawartości podanego pliku, lecz zostanie dopisana do jej końca.
• Przekierowanie stdout nie ma wpływu na powiązanie stderr z ekranem, komunikaty o błędach pojawią się i tak na ekranie terminala użytkownika. Większość narzędzi unixowych nie wypisuje żadnych komunikatów w przypadku, gdy ich działanie przebiega zgodnie z oczekiwaniami.
• Przekierowanie potokowe może być również zastosowane wielokrotnie w ramach jednej komendy złożonej, np. komenda1 ... | komenda2 ... | komenda3 .... Shell nie czeka z uruchomieniem kolejnych poleceń występujących w potoku przetwarzania na zakończenie poprzednich, będą one działały równolegle w miarę napływania danych.
SIEĆ I PRACA ZDALNA
Po podaniu identyfikatora użytkownika -- login, oraz hasła na którymś z komputerów pracujących w sieci unixowej znajdujemy się w sesji lokalnej, tj. uruchamiane przez użytkownika programy wykonują się na tym komputerze, przy którym on siedzi -- niezależnie od tego, że funkcje sieci umożliwiają mu dostęp do szeregu zasobów udostępnianych przez serwer lub serwery sieciowe (głównie plików na dyskach sieciowych). Ta forma dostępu do zasobów sieci nie wymaga żadnych szczególnych zabiegów ze strony użytkownika, praca na dysku sieciowym niczym się w zasadzie nie różni od pracy na dysku podłączonym bezpośrednio do używanego w danej chwili komputera.
Funkcje sieci unixowej pozwalają jednak również na bardziej ,,bezpośredni'' dostęp do komputera zdalnego, polegający na otwarciu zdalnej sesji np. w jednym z okienek terminalowych uruchomionych w ramach systemu okienkowego. Wiąże się to zazwyczaj z ponownym podaniem loginu i hasła (przedstawiamy się innemu komputerowi); programy uruchomione w ramach sesji zdalnej wykonują się na zdalnym komputerze i mają bezpośredni dostęp do jego zasobów -- dysków itp., oczywiście w ramach uprawnień przysługujących danemu użytkownikowi. Zdalny komputer może znajdować się w tej samej sieci lokalnej (tj. np. w OKWF) lub wręcz na drugim końcu świata -- o ile jest dostępny poprzez łącza internetowe. Oczywiście w tym drugim przypadku konieczne jest posiadanie konta uprawniającego do dostępu do tego właśnie komputera.
Poza programami terminalowymi, tj. komunikującymi się z użytkownikiem poprzez terminal znakowy (jakim jest np. okienko xterm), możliwe jest również zdalne uruchamianie programów okienkowych, pracujących w standardzie X Window System -- komunikujących się z użytkownikiem poprzez swoje własne okna (jak np. Netscape). Z reguły możliwe jest to jednak jedynie w ramach sieci lokalnej, odpowiednie kanały komunikacji sieciowej są zazwyczaj blokowane na styku sieć lokalna -- ,,reszta świata'', ze względów bezpieczeństwa. Zresztą komunikacja dalekiego zasięgu przez Internet jest zazwyczaj zbyt powolna aby zapewnić wygodną pracę w zdalnie uruchamianym programie okienkowym.
Omówimy tu również skrótowo inne możliwości wykorzystania sieci czy usługi sieciowe, takie jak transfer plików z wykorzystaniem protokołu FTP, korzystanie z WWW, Usenet, i pocztę elektroniczną.
PRACA ZDALNA: TELNET
Najprostszym narzędziem do pracy zdalnej jest program telnet; w dużym uproszczeniu, uruchomienie go zamienia aktualnie używany terminal (okienko typu xterm lub konsolę znakową) w terminal ,,jakby'' bezpośrednio podłączony do komputera zdalnego. Jako argument wywołania telnet podajemy nazwę lub adres zdalnego komputera, z którym chcemy się połączyć; w przypadku (najczęstszym) gdy jest to komputer z tej samej sieci lokalnej (dokładniej: domeny DNS), wystarczy podać pierwszy człon tej nazwy (np. telnet tempac, telnet primus). Po (udanym) przedstawieniu się zdalnemu komputerowi (identyfikatorem użytkownika oraz hasłem), uzyskujemy dostęp do wszelkich zasobów tego komputera (do których dostęp przysługuje danemu użytkownikowi), a więc dysków i zainstalowanych na nim programów. Programy posługujące się interfejsem znakowym możemy uruchamiać tak samo, jak byłoby to możliwe na terminalu podłączonym bezpośrednio do zdalnego komputera.
Zakończenie sesji telnet i powrót do sesji lokalnej następuje przez podanie komendy logout lub exit. Wprowadzenie z klawiatury sekwencji specjalnej (zazwyczaj Ctrl-], oznaczane również jako ^], co znaczy równoczesne wciśnięcie klawiszy Ctrl i ]) umożliwia skorzystanie z szeregu wewnętrznych funkcji samego programu komunikacyjnego telnet, takich jak: close (natychmiastowe zamknięcie sesji), czy z (czasowe ,,zawieszenie'' sesji, powrót do sesji zdalnej przez komendę fg).
Głównym niedostatkiem programu telnet jest fakt, że cała treść komunikacji ze zdalnym komputerem przesyłana jest ,,otwartym tekstem'', włącznie z hasłem użytkownika. W dzisiejszych warunkach uznawane jest to za poważne zagrożenie dla bezpieczeństwa i z tego powodu komunikacja w protokole telnet jest zazwyczaj blokowana na styku sieć lokalna -- reszta świata (firewall). Również komputery OKWF nie są dostępne poprzez telnet z zewnątrz sieci Wydziału Fizyki.
PRACA ZDALNA: SSH I SLOGIN
Nieco lepszą wersję pracy zdalnej umożliwia program ssh, różniący się od telnet głównie tym, że strumień komunikacji pomiędzy klientem a serwerem jest szyfrowany -- dość ,,silnym'', a więc trudnym do złamania algorytmem (w każdym razie złamanie go wprost jest poza zasięgiem możliwości domorosłych ,,hackerów''). Z tego względu komunikacja przez ssh częściej bywa dostępna w połączeniach dalekiego zasięgu (poza siecią lokalną), np. komputer tempac dostępny jest spoza Wydziału Fizyki przez połączenia ssh. Dostępna jest również opcjonalnie kompresja strumienia komunikacyjnego, co istotnie poprawia współpracę z programami okienkowymi uruchomionymi w sesji ssh na odległym komputerze. Zarówno szyfrowanie jak i kompresja odbywają się w sposób ,,przezroczysty'' dla użytkownika i nie wymagają od niego specjalnych zabiegów, poza ew. poinformowaniem programu czy kompresja ma być wykorzystywana czy wyrażeniem preferencji co do stosowanego algorytmu szyfrowania.
Przy uruchamianiu zdalnej sesji w ssh może być konieczne podanie w linii komend identyfikatora konta (login), z którego zamierzamy korzystać na zdalnym komputerze, o ile nie brzmi on tak samo jak login konta lokalnego. Chcąc uruchomić sesję interakcyjną, tj. o własnościach (dla użytkownika) najbardziej zbliżonych do sesji telnet, wywołujemy program slogin, w postaci np. slogin login@tempac (jest to program pomocniczy dla programu ssh).
Aby mieć możliwość uruchamiania w sesji zdalnej programów okienkowych (których okna będą wówczas pojawiały się na naszym aktualnym terminalu, zakładając oczywiście, że pracuje on w trybie graficznym), może być konieczne dodanie opcji -X (np. slogin -X login@primus). Należy jednak wiedzieć, że administrator zdalnego komputera mógł mu ,,zabronić'' uruchamiania programów okienkowych dla sesji ssh.
Istnieje wiele możliwości zmodyfikowania sposobu działania ssh i slogin dla danego użytkownika, poprzez zapisanie odpowiednich opcji i informacji w plikach umieszczonych w katalogu ~/.ssh/. Możliwe jest m. in. zadanie różnych domyślnych identyfikatorów (loginów) dla różnych zdalnych komputerów, kontrolowanie opcji dotyczących szyfrowania, kompresji i możliwości uruchamiania programów okienkowych, oraz wykorzystanie tzw. autoryzacji RSA (metodą klucza publicznego), co pozwala uniknąć każdorazowego podawania hasła do zdalnego konta przy otwieraniu sesji. Dociekliwi znajdą odpowiednie szczegóły w dokumentacji (man ssh).
Program ssh posiada również możliwość wygodnego transferu plików z i do zdalnych komputerów, w czym może często zastąpić ftp (w trybie nieanonimowym, p. poniżej). W tym celu wywołujemy go poleceniem postaci scp [login@]adres:ścieżka_do_pliku_zdalnego plik_lokalny (dla transferu z komputera zdalnego na lokalny), i z odwróceniem kolejności argumentów dla transferu w kierunku odwrotnym. Ścieżka do pliku zdalnego może być podana bądź w postaci bezwzględnej (zaczynając od /), bądź względem katalogu ,,domowego'' dla zdalnego konta.
TRANSFER PLIKÓW: FTP
Protokół FTP i obsługujący go program (również o nazwie ftp) służy do przesyłania plików siecią pomiędzy klientem (tj. komputerem z którego inicjujemy połączenie) a serwerem, i to w obu kierunkach. Nie jest on potrzebny w przypadku, gdy chodzi o dwa komputery posiadające wspólny dostęp do dysków sieciowych, natomiast często wykorzystywany jest do udostępniania np. archiwów swobodnie dostępnego oprogramowania poprzez Internet.
W najprostszym przypadku używamy FTP do przesyłania plików z i do komputera, na którym również posiadamy własne konto. Wówczas, po uruchomieniu programu ftp podajemy login i hasło do konta na zdalnym komputerze, uzyskując w ten sposób dostęp do odczytu i zapisu plików w ramach uprawnień danego konta. Najważniejsze komendy dostępne w programie ftp to:
• dir lub ls: lista zawartości aktualnego katalogu na zdalnym komputerze;
• cd katalog_zdalny: zmiana katalogu aktualnego na zdalnym komputerze;
• lcd katalog_lokalny: zmiana katalogu aktualnego na lokalnym komputerze -- przetransferowane pliki będą domyślnie umieszczane w aktualnym katalogu;
• get plik_zdalny [plik_lokalny]: sprowadzenie zdalnego pliku na lokalny komputer i zapisanie jego zawartości w pliku lokalnym o podanej (opcjonalnie) nazwie -- domyślnie, pod tą samą nazwą co na komputerze zdalnym;
• mget wzorzec_pliku_zdalnego: sprowadzenie na lokalny komputer wszystkich plików z aktualnego katalogu zdalnego, których nazwy pasują do podanego wzorca; budowa wzorców nazw jest analogiczna jak w linii komend shella, tj. z wykorzystaniem znaków takich, jak *, ? ...
• put plik_lokalny [plik_zdalny]: przesłanie na zdalny komputer pliku lokalnego i umieszczenie jego zawartości w pliku o opcjonalnie podanej nazwie;
• mput wzorzec_pliku_lokalnego: przesłanie na zdalny komputer wszystkich plików lokalnych z aktualnego katalogu, o nazwach pasujących do podanego wzorca;
• prompt: domyślnie, w trakcie wykonywania poleceń dotyczących wielu plików (mget, mput) program zapytuje użytkownika o potwierdzenie operacji dla każdego kolejnego pliku. Polecenie prompt wyłącza te zapytania, a więc operacje te będą przeprowadzane bez pytania o potwierdzenie. Jeżeli zapytania wcześniej wyłączono, polecenie to włącza je z powrotem;
• binary: transfer będzie wykonywany w trybie binarnym, zachowującym ,,co do bitu'' zawartość przesyłanych plików. Obecnie większość serwerów FTP ustawia domyślnie tryb binarny przy otwarciu sesji, należy zwrócić uwagę na pojawienie się odp. komunikatu na początku sesji -- jeżeli go nie było, ustawić tryb binarny przed transferem, p. poniżej;
• ascii: transfer będzie wykonywany w trybie ASCII. Oznacza to w praktyce, że ,,najstarszy'' z ośmiu bitów tworzących każdy bajt danych ulegnie ,,zmasakrowaniu'', tak więc przesłane w ten sposób programy nie będą działały, pliki graficzne nie dadzą się otworzyć, a pliki tekstowe zawierające znaki spoza zakresu podstawowego (ą, ć, ę, ...) będą w ich miejsce zawierać nie wiadomo co. Tryb ASCII jest reliktem historycznym i nie należy go używać w zasadzie nigdy;
• bye lub quit: kończy sesję i działanie programu ftp.
Drugi tryb FTP to tzw. tryb anonimowy. Wykorzystywany on jest w kontaktowaniu się z serwerami publicznymi, na których udostępnione są pliki które można pobrać bez wykazania się jakimikolwiek uprawnieniami. W trybie anonimowym w miejsce identyfikatora konta podajemy anonymous lub (krócej) ftp, a w miejsce hasła można podać cokolwiek, z tym że dobrym zwyczajem jest wpisanie swojego adresu poczty elektronicznej (rzadko jest to jednak w jakikolwiek sposób egzekwowane, o ile w ogóle). Poza tym praca w trybie anonimowym wygląda dokładnie tak samo, jak w ,,zwykłym'', niemożliwe jest jednak na ogół umieszczanie swoich plików na zdalnym serwerze. Interesująca dla ,,gości'' zawartość zdalnego serwera znajduje się na ogół w katalogu /pub i jego podkatalogach.
Uwaga: w wielu przypadkach zabezpieczenia stosowane na firewallach uniemożliwiają transfery FTP spoza sieci lokalnej w domyślnym trybie programu. W takiej sytuacji należy wywoływać program jako ftp -p lub pftp; jeżeli dostępna wersja ftp nie udostępnia żadnej z tych opcji, to może zadziałać podanie na początku sesji FTP komendy quote PASV.
Obecnie przy przeglądaniu publicznych archiwów FTP wykorzystuje się zazwyczaj przeglądarkę WWW (np. Netscape), która również potrafi posługiwać się protokołem FTP, przynajmniej w trybie anonimowym. Jest to wygodne gdy nie wiemy dokładnie, czego szukamy; natomiast gdy znana jest nam lokalizacja plików do przetransferowania, użycie ,,klasycznego'' programu FTP często pozwala wykonać zadanie szybciej i sprawniej.