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

Transkrypt

Załącznik nr 1. Próbki tekstu do tłumaczenia. Łódź, 02.10
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
Załącznik nr 1. Próbki tekstu do tłumaczenia.
Łódź, 02.10.2012 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 3261.
Najważniejsze strony dotyczące SIP:
http://www.ietf.org/html.charters/sip-charter.html
http://www.sipforum.org/
http://www.cs.columbia.edu/sip/assignments.html
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: 224.0.1.75 i skojarzona
strona 1 / 9
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
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
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
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
2617.
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
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
• 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
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
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
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
(...)
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
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
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
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
(…)
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
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl
Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Programu Operacyjnego Innowacyjna Gospodarka
(…)
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
NOITE s.c., ul. Łyżwiarska 40, 94-124 Łódź, REGON: 101081463, NIP: 7272777114
tel. +48 42 288 10 25, fax:+48 42 288 10 35, e-mail: [email protected], www.noite.pl