Załącznik nr 1. Próbki tekstu do tłumaczenia. Łódź, r.

Transkrypt

1 Załącznik nr 1. Próbki tekstu do tłumaczenia. Łódź, r. Uwaga: tekst zaznaczony na żółto zawiera listingi lub polecenia w języku angielskim i nie wymaga tłumaczenia. Próbka nr 1: SIP (ang. Session Initiation Protocol) jest protokołem służącym do zestawiania komunikacji pomiędzy punktami końcowymi w sieci. Nie jest ograniczony do zestawiania połączeń głosowych, ale w tej dziedzinie głównie się go wykorzystuje. Określony został w dokumencie RFC Najważniejsze strony dotyczące SIP: W celu zapewnienia możliwości podobnego jak w sieciach telefonicznych kontaktowania się użytkowników wprowadzony został format URI (ang. Uniform Resource Identifier): sip:user:password@domain:port;uri-parameters?headers Najczęściej jednak spotyka się uproszczoną wersję: sip:user@domain Gdzie user jest nazwą wywoływanego użytkownika, a domain nazwą domeny protokołu DNS lub adresem IP. Porty przydzielone dla SIP przez IANA: 5060 TCP i UDP 5061 TLS-over-TCP Dodatkowo przydzielony został adres multicast dla wiadomości REGISTER: i skojarzona strona 1 / 9

2 z nim nazwa domenowa sip.mcast.net (Multicast address for REGISTER). Implementacja protokołu SIP obsługuje również numery portów zwracane przez rekord SRV protokołu DNS, zawsze jednak nadrzędny jest URI. Współpraca z mechanizmami DNS wykorzystuje również rekordy NAPTR, A, AAAA, co zostało opisane w RFC 3263 (SIP: Locating SIP Servers). Rysunek 1 Komunikacja w SIP Poniżej omówiono przedstawioną na rysunku metodę wykonywania wywołań przez SIP: 1. Oba telefony rejestrują się u swoich serwerów pośredniczących protokołu SIP (SIP proxy server) za pomocą komunikatów REGISTER. Ten etap nie jest wykonywany za każdym dzwonieniem, a jedynie przy rejestracji stacji. 2. Telefony otrzymują komunikat OK od swoich serwerów. 3. Telefon A wysyła komunikat INVITE zawierający informacje o wspieranych kodekach, portach i adresie IP przeznaczonych dla strumieni dźwiękowych. 4. Używając zapytań DNS, Proxy A określa, który serwer jest odpowiedzialny za obsługę wywołanego URI, i przekazuje wiadomość INVITE do serwera Proxy B. 5. Równocześnie wiadomość 100 TRYING jest wysyłana zwrotnie do Telefonu A. 6. Proxy B odbiera INVITE, sprawdza czy Telefon B jest aktualnie zarejestrowany i przekazuje do niego wiadomość. 7. Telefon B akceptuje komunikat INVITE i zwraca wiadomość 180 RINGING. 8. Proxy B przekazuje wiadomość 180 RINGING do Proxy A. 9. Proxy A przekazuje wiadomość 180 RINGING do Telefonu A. 10. Użytkownik B w końcu podnosi słuchawkę, w efekcie Telefon B akceptuje połączenie (wywołanie) i wysyła 200 OK do Proxy B. Wiadomość zawiera informacje o wspieranych kodekach, portach i adresie IP, przeznaczonych dla strumieni dźwiękowych. 11. Proxy B przekazuje wiadomość 200 OK do Proxy A. 12. Proxy A przekazuje wiadomość 200 OK do Telefonu A. 13. Telefon A zwraca potwierdzenie (zgodę) ACK do Proxy A. ACK może zawierać informację dotyczącą preferowanych mediów transmisji. strona 2 / 9

3 14. Proxy A przekazuje ACK do Proxy B. 15. Proxy B przekazuje ACK do Telefonu A. 16. Dwa telefony mogą teraz nawiązać komunikację bezpośrednio ze sobą. Serwery SIP proxy nie będą już angażowane. Plusem tego protokołu jest właśnie fakt nieangażowania serwerów SIP do komunikacji pomiędzy użytkownikami, poza umożliwieniem im zestawienia połączenia. Protokół SIP umożliwia dynamiczną rejestrację stacji końcowych za pomocą wysyłanego periodycznie komunikatu REGISTER, co wspiera w ograniczonym stopniu stacje mobilne. Jeśli SIP proxy nie jest powiadomiony o adresie i parametrach Telefonu (stacji końcowej), to przy próbie wywołania zwraca najczęściej komunikat: 480 Temporarily Unavailable, generując w telefonie wywołującym połączenie sygnał zajętości. SIP używa autentykacji opartej na metodzie zastosowanej w protokole HTTP i zdefiniowanej w RFC Specyfikacja zawarta w RFC 3261 dokonuje podziału funkcji serwerów SIP na trzy części, które mogą występować jako oddzielne serwery: SIP Registrar Server przyjmuje komunikaty REGISTER, SIP Redirect Server odbiera zapytania SIP i wysyła odpowiedzi o kodach, np. 3xx redirection, przekierowując stacje końcowe na adres, z którym należy się skontaktować, SIP Proxy Server przekazuje żądania do UAS (User Agent Servers), a odpowiedzi do UAC (User Agent Clients). Wiadomości protokołu SIP podobnie jak wielu innych protokołów internetowych są w formacie w miarę czytelnym dla człowieka. Próbka nr 2: Rodzaje pracy systemu LDAP Praca serwera LDAP omówiona we wcześniejszych rozdziałach realizowana był wyłącznie z wykorzystaniem jednego serwera LDAP. Tak jak omówiono wcześniej X.500 oraz LDAP stworzone zostały z wykorzystaniem hierarchicznej bazy danych, umożliwiającej możliwość rozproszenia jej w ramach wielu serwerów. Taka funkcjonalność powoduje realizację zadań w ramach rozproszonego geograficzne systemu informatycznego, w którym działa serwer LDAP. Rozproszenie katalogu powoduje, że serwer LDAP może działać jako: strona 3 / 9

4 główny (master) serwer bazy katalogu serwer zapasowy (slave) zawierający kopię bazy katalogu serwer dodatkowy realizujący zadania dla poszczególnych gałęzi katalogu serwery mieszane realizujące zadania kopii dla poszczególnych gałęzi katalogu. serwer pośredniczący, którego zadaniem jest przekazywanie zapytań do serwera głównego oraz buforowania odpowiedzi Replikacja Replikacja jest mechanizmem pozwalającym na automatyczne kopiowanie danych z jednego serwera do drugiego. Po skopiowaniu danych z serwera utrzymującego główną kopie danych do serwerów utrzymujących inne kopie tych danych, mechanizm replikacji nadal synchronizuje wszystkie kopie na serwerach, tzn. zmiana danych na serwerze z prawem zapisu danych skutkuje wprowadzeniem tych samych zmian w kopiach danych na innych serwerach. Utrzymywanie kopii danych na kilku serwerach ma następujące zalety : pozwala zapewnić dostępność danych zarówno dla odczytu jak i zapisu danych, pozwala na równoważenie obciążenia serwerów całkowite obciążenie operacjami np. przeszukiwania jest dzielone na kilka serwerów utrzymujących kopie danych, można także podzielić serwery na te udostępniane do modyfikacji danych oraz inne tylko do odczytu (utrzymujące kopie danych tylko do odczytu) Używanie centralnego źródła informacji ma wiele zalet, ale ma także wielką wadę. Jeśli z jakiegoś powodu serwer będzie niedostępny z komputera klienta system stanie się praktycznie bezużyteczny dla użytkowników. Aby rozwiązać ten problem można użyć mechanizmu implementowanego w serwerach LDAP zwanego replikacją. Jeden z serwerów jest używany jako master a pozostałe jako slaves (repliki). Każda zmiana w zawartości głównego LDAPa jest propagowana do replik. Jeśli klient nie będzie mógł się połączyć z masterem, to pobierze dane z repliki. (...) Konfiguracja z serwerami referencyjnymi Konfiguracja w tym trybie umożliwia powiązanie pomiędzy sobą różnych serwerów LDAP. Poszczególne serwery w zależności od zapytania odsyłają aplikację kliencką pomiędzy sobą. Aplikacja kliencka otrzymuje od serwera LDAP do którego było zgłoszone żądanie wykonania akcji referencję do innego serwera LDAP, który obsługuje dane żądanie klienta. Klient po otrzymaniu referencji ponawia żądanie, kierując je już do właściwego serwera. strona 4 / 9

5 Serwery LDAP obsługują dwa rodzaje referencji: Referencje definiowane w pliku slapd.conf z wykorzystaniem słowa kluczowego referral Jeśli żądanie klienta dotyczy węzła spoza obsługiwanej domeny określonej poprzez słowo suffix, serwer zwraca klientowi określoną referencję do innego serwera LDAP, który może obsłużyć żądanie klienta lub odesłać go do innego serwera. Przykład: referral ldap://inny.serwer.ldap/ Przykład: suffix dc=akademia-linux,dc=pl Referencje definiowane dla węzła poprzez przypisanie węzłowi obiektu referral Drugim modelem realizacji referencji jest stworzenie w bazie LDAP wpisu z referencją, która służy do przekazania informacji że dany wpis obsługiwany jest przez inny serwer. Teki mechanizm umożliwia przechowywanie różnych gałęzi drzewa LDAP pomiędzy serwerami. Przykład: dn: dc=klasa,dc=akademia-linux,dc=pl objectclass: referral objectclass: extensibleobject dc: poddrzewo ref: ldap://inny.serwer.ldap/dc=klasa,dc=akademia-linux,dc=pl strona 5 / 9

6 (...) Konfiguracja replikacji Konfiguracja serwera slurpd Wykorzystanie serwera slurpd jest możliwe wyłącznie w systemie OpenLDAP w wersji wcześniejszej niż 2.4. Modyfikacja serwera głównego Istniejący serwer zacznie pełnić rolę mastera. W tym celu konieczne jest dodanie następujących linii do /etc/openldap/slapd.conf. replica host=<ip OF REPLICA> binddn="cn=replicator,dc=akademia-linux,dc=pl" bindmethod=simple credentials=secret Powyższa linia określa z jakimi prawami będzie podłączony serwer zapasowy do bazy katalogu. Oczywiście odpowiedni DN musi być dodany do katalogu. Do bazy LDAP należy dodać DN, który będzie używany przez mastera w celu dowiązania do repliki: dn: cn=replicator,dc=akademia-linux,dc=pl objectclass: top objectclass: person userpassword: secret cn: Replicator sn: Replicator Do pliku /etc/openldap/slapd.conf należy dodatkowo dodać prawa umożliwiające dokonywanie replikacji: access to * by dn="cn=replicator,dc=akademia-linux,dc=pl" write by * read Dodatkowo można określić także, gdzie ma być przechowywany plik logów: replogfile /vat/spool/slurpd/file.log Po dokonaniu zmian należy wystartować serwer główny slapd oraz serwer replikacji slurpd. strona 6 / 9

7 Próbka tekstu nr 3: Powłoka jest najważniejszym elementem komunikacji użytkownika z systemem. Powłoka może być realizowana w różny sposób. Aktualnie najpopularniejszy sposób komunikacji odbywa się poprzez ekran komputerowy oraz różne urządzenia wejścia-wyjścia, jak na przykład klawiatura czy mysz komputerowe. W systemach uniksowych (linuksowych) najbardziej popularnym sposobem komunikacji jest tryb tekstowy. Jednak praca w trybie graficznym jest także swego rodzaju interpreterem poleceń, wydawanych jednak nie za pomocą komend, ale za pomocą odpowiedniej akcji urządzenia wskazującego np. myszki. Praca w trybie graficznym realizowana jest przez system X-Window, który zostanie opisany w dalszej części. Praca w trybie tekstowym polega na wykonaniu sekwencji poleceń. Sposób wpisywania tych komend, mechanizm ich edycji oraz sposób ich realizacji jest główną rolą każdego interpretera poleceń. W systemie Linux użytkownik ma do wyboru kilka aplikacji pełniących rolę powłoki. Decyzja o wyborze jednego z nich może wiązać się z upodobaniami każdego użytkownika. Każdy z interpreterów posiada zazwyczaj własne niepowtarzalne cechy. W systemie Linux, podobnie jak winnych systemach uniksowych istnieją dwie rodziny programów powłok: powłoki sh, powłoki csh. W pierwszym przypadku najpopularniejszą jest powłoka BASH, jest to darmowa odmiana tradycyjnej powłoki pracującej w środowiskach uniksowych o nazwie Bourne SHELL (sh). Powłoka sh narzuciła w świecie uniksowym pewien standard, określając pewne zachowania systemu takie jak: klawisze wspomagające pracę z powłoką, edytor komend, zarządzanie historią wydawanych komend, mechanizm tworzenia aliasów. ( ) Powłoka BASH Użytkownik pracując pod kontrolą trybu tekstowego w systemie Linux zazwyczaj pracuje w powłoce BASH. Jest to najpopularniejsza powłoka posiadająca wiele udogodnień. Wśród nich jest wiele poleceń, wbudowanych w powłokę BASH. Wiele z nich zostanie omówionych w dalszej części dokumentacji. strona 7 / 9

8 ( ) Sposoby uruchomienia Domyślnie powłoka uruchamiana jest po zalogowaniu użytkownika w systemie. Za określenie rodzaju powłoki, aplikacji jaką uruchamia system na rzecz użytkownika odpowiedzialne jest ostatnie pole przypisane mu w pliku /etc/passwd. student:x:1022:1024::/home/student:/bin/bash Ostatnia linia określa jaka aplikacja ma być uruchomiona, gdy użytkownik zastanie poprawnie zautoryzowany w systemie, np. za pomocą komendy login (przy lokalnym logowaniu) lub programu ssh (przy zdalnym logowaniu). W przypadku powłoki BASH, jest to oczywiscie program /bin/bash. ( ) Innym sposobem uruchomienia powłoki, jest oczywiście wykonanie komendy /bin/bash (lub bash). Do komendy można wtedy dodawać przełączniku modyfikujące jej działanie lub ustawiające parametry. Składnia polecenia: bash [opcje] [plik] opcje polecenia: -c - odczytuje polecenia z podanego jako argument ciągu -r - uruchamia wersję okrojoną powłoki -i - uruchamia powłokę w trybie interaktywnym -s - odczytuje polecenia ze standardowego strumienia wejścia -D - na ekranie wypisywana jest lista wszystkich podwójnie cytowanych łańcuchów poprzedzonych znakiem $ +0, -0 - ustawia opcję powłoki obsługiwane przez komendę wbudowana shopt, (-O nadaje wartość, +O usuwa ustawienie) --init-file, --rcfile plik - wykonuje polecenia z podanego pliku zamiast z pliku użytkownika ~/.bashrc --login - powłoka działa tak, jakby został wywołany jako powłoka zgłoszeniowa --noediting - nie używa biblioteki GNU readline do odczytu wierszy poleceń w trybie interaktywnym. --noprofile - nie odczytuje pliku /etc/profile ani żadnego z plików osobostych ~/.bash_profile, ~/.bash_login, ~/.profile --norc - nie odczytuje i nie wykonuje osobistego pliku inicjującego ~/.bashrc jeśli powłoka jest interaktywna --posix - powłoka pracuje w trybie zgodności ze standardem POSIX --restricted - powłoka uruchamiana jest w trybie okrojona strona 8 / 9

9 ( ) Powłoka z restrykcjami W systemach korporacyjnych często spotyka się wykorzystanie trybu okrojonej powłoki. Wykorzystując ten tryb administrator blokuje użytkownikowi pewne możliwości pracy w systemie, takie jak: zmiana katalogu za pomocą polecenia cd, zmiana wartości zmiennych SHELL, PATH, ENV lub BASH_ENV, podawanie nazw poleceń zawierających /, importowanie definicji funkcji podczas inicjalizacji powłoki, analiza opcji powłoki przy inicjalizowaniu powłoki, przekierowywanie wyjścia, wykorzystywaniem polecenia wbudowanego exec, podawanie opcji p polecenia command, wyłączenie trybu okrojonego za pomocą polecenia set. (...) Tryb logowania Plik /etc/profile jest głównym plikiem inicjalizującym powłoki bash w trybie logowania. Domyślnie prawo do tego pliku ma wyłącznie administrator systemu. W pliku tym znajdują się ustawienia globalne dla wszystkich użytkowników. Kolejnym plikiem uruchamianym przez powłokę jest kolejno plik.bash_profile lub.bash_login lub.profile. Pliku te mogą istnieć w katalogu domowym użytkownika ale tylko jeden z tych plików jest uruchamiany. Istnienie tych plików sprawdzane jest w podanej kolejności. Często w pliku występuje wykonanie także pliku.bashrc, jednak realizują to skrypty a nie powłoka i zależy to od dystrybucji. Sama powłoka w trybie logowania nie uruchamia pliku.bashrc. strona 9 / 9