diff --git a/biblio.bib b/biblio.bib index f7159dd..cd256bf 100644 --- a/biblio.bib +++ b/biblio.bib @@ -99,8 +99,160 @@ @online{bib:ssh-article, author = {N/A}, - title = {SSH File Transfer Protocol (SFTP): Get SFTP client & server}, + title = {SSH File Transfer Protocol (SFTP): Get SFTP client and server}, year = {N/A}, url = {https://www.ssh.com/academy/ssh/sftp-ssh-file-transfer-protocol}, urldate = {2022-12-31} -} \ No newline at end of file +} + +@techreport{bib:ssh-rfc, + type = {Request for Comments}, + number = 4251, + publisher = {RFC Editor}, + doi = {10.17487/RFC4251}, + author = {Chris M. Lonvick and Tatu Ylonen}, + title = {{The Secure Shell (SSH) Protocol Architecture}}, + pagetotal = 30, + year = 2006, + abstract = {The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. {[}STANDARDS-TRACK{]}}, +} + +@online{bib:openssh-usage, + author = {N/A}, + title = {OpenSSH Users}, + year = {N/A}, + url = {https://www.openssh.com/users.html}, + urldate = {2022-12-31} +} + +@misc{bib:http-rfc, + series = {Request for Comments}, + number = 2068, + howpublished = {RFC 2068}, + publisher = {RFC Editor}, + doi = {10.17487/RFC2068}, + url = {https://www.rfc-editor.org/info/rfc2068}, + author = {Roy T. Fielding and Henrik Nielsen and Jeffrey Mogul and Jim Gettys and Tim Berners-Lee}, + title = {{Hypertext Transfer Protocol -- HTTP/1.1}}, + pagetotal = 162, + year = 1997, + month = jan, + abstract = {The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. {[}STANDARDS-TRACK{]}}, +} + +@online{bib:http-history, + author = {Mozilla MDN Contributors}, + title = {Evolution of HTTP}, + year = {ostatnia modyfikacja: Oct 28, 2022}, + url = {https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP#http1.1_%E2%80%93_the_standardized_protocol}, + urldate = {2022-12-31} +} + +@online{bib:http-overview, + author = {Mozilla MDN Contributors}, + title = {An overview of HTTP}, + year = {ostatnia modyfikacja: Nov 22, 2022}, + url = {https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview}, + urldate = {2022-12-31} +} + +@online{bib:http-methods, + author = {Mozilla MDN Contributors}, + title = {HTTP request methods}, + year = {ostatnia modyfikacja: Sep 9, 2022}, + url = {https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods}, + urldate = {2022-12-31} +} + +@incollection{bib:virtualization-article, + title = {1 - How Virtualization Happens}, + editor = {Diane Barrett and Gregory Kipper}, + booktitle = {Virtualization and Forensics}, + publisher = {Syngress}, + address = {Boston}, + pages = {3-24}, + year = {2010}, + isbn = {978-1-59749-557-8}, + doi = {https://doi.org/10.1016/B978-1-59749-557-8.00001-1}, + url = {https://www.sciencedirect.com/science/article/pii/B9781597495578000011}, + author = {Diane Barrett and Gregory Kipper} +} + + @misc{bib:kvm-small-look, + author = "KVM", + title = "Small look inside --- KVM{,} ", + year = "2009", + url = "https://www.linux-kvm.org/index.php?title=Small_look_inside&oldid=2282", + urldate = {2022-12-31}, + } + + @misc{bib:kvm-main, + author = "KVM", + title = "Main page --- KVM{,} ", + year = "2016", + url = "https://www.linux-kvm.org/index.php?title=Main_Page&oldid=173792", + urldate = {2022-12-31}, + } + +@techreport{bib:intel-vt-specs, + type = {Architecture Specification}, + publisher = {Intel}, + doi = {D51397-015}, + author = {Intel}, + title = {Intel ® Virtualization Technology for Directed I/O; Architecture Specification, rev. 4.0}, + year = 2022 +} +@techreport{bib:amd64-specs, + type = {Architecture Specification}, + publisher = {AMD}, + doi = {24593}, + author = {AMD}, + title = {AMD64 Technology; AMD64 Architecture Programmer’s Manual Volume 2: System Programming, Rev. 3.3}, + year = 2022 +} + +@online{bib:qemu-main, + author = {QEMU}, + title = {QEMU; A generic and open source machine emulator and virtualizer}, + year = {N/A}, + url = {https://www.qemu.org}, + urldate = {2022-12-31} +} + +@techreport{bib:pxe-specs, + type = {Architecture Specification}, + publisher = {Intel with special contributions from SystemSoft}, + author = {Intel with special contributions from SystemSoft}, + title = {Preboot Execution Environment (PXE) Specification, rev. 2.1}, + year = 1999 +} + +@misc{bib:dhcp-rfc, + series = {Request for Comments}, + number = 2131, + howpublished = {RFC 2131}, + publisher = {RFC Editor}, + doi = {10.17487/RFC2131}, + url = {https://www.rfc-editor.org/info/rfc2131}, + author = {Ralph Droms}, + title = {{Dynamic Host Configuration Protocol}}, + pagetotal = 45, + year = 1997, + month = mar, + abstract = {The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. {[}STANDARDS-TRACK{]}}, +} + +@misc{bib:tftp-rfc, + series = {Request for Comments}, + number = 1350, + howpublished = {RFC 1350}, + publisher = {RFC Editor}, + doi = {10.17487/RFC1350}, + url = {https://www.rfc-editor.org/info/rfc1350}, + author = {Dr. Karen R. Sollins}, + title = {{The TFTP Protocol (Revision 2)}}, + pagetotal = 11, + year = 1992, + month = jul, + abstract = {TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. {[}STANDARDS-TRACK{]}}, +} diff --git a/main.pdf b/main.pdf index f607958..373d674 100644 Binary files a/main.pdf and b/main.pdf differ diff --git a/main.tex b/main.tex index bee12b2..0d6f258 100644 --- a/main.tex +++ b/main.tex @@ -499,7 +499,7 @@ Prezentowana praca podzielona została na kilka rozdziałów: \begin{itemize} \item analiza tematu: przybliżenie wykorzystanych technologii, ich charakterystyka, historia i zastosowania - \item wymagania i narzędzia: jakie narzędzia zostały wykorzystane do rozwiązania problemu, ich opis oraz uzasadnienie wyboru + \item wymagania i narzędzia: jakie są wymagania dla aplikacji, jakie narzędzia zostały wykorzystane do rozwiązania problemu, ich opis oraz uzasadnienie wyboru \item specyfikacja zewnętrzna: specyfikacja opisująca całe rozwiązanie z perspektywy użytkowników końcowych, z wyszczególnionymi elementami składowymi rozwiązania \item specyfikacja wewnętrzna: specyfikacja opisująca techniczne aspekty rozwiązania, z perspektywy osoby technicznej zaznamiającej się z kodem źródłowym oprogramowania \item weryfikacja i walidacja: wyniki testów przeprowadzonych na testowym środowisku wdrożeniowym, ich analiza @@ -532,9 +532,9 @@ Istnieje kilka popularnych sposobów synchronizacji i przesyłania plików pomi Wśród nich warto zwrócić uwagę na poniższe rozwiązania: \begin{itemize} - \item RSYNC\cite{bib:redhat_rsync} - \item SFTP\cite{bib:ietf-secsh-filexfer-13} - \item serwer http serwujący pliki statyczne + \item RSYNC \cite{bib:redhat_rsync} + \item SFTP \cite{bib:ietf-secsh-filexfer-13} + \item serwer HTTP serwujący pliki statyczne \end{itemize} \paragraph{RSYNC} @@ -559,31 +559,235 @@ całych plików, jedynie zmian, które w nich nastąpiły.\cite{bib:rsync-articl \paragraph{SFTP} SFTP (Secure File Transfer Protocol) to bezpieczny protokół przesyłu plików wykorzystujący protokół SSH do uwierzytelnienia oraz szyfrowania przesyłanych danych. Pierwszym krokiem do przesyłu danych jest nawiązanie połączenia SSH pomiędzy urządzeniami, następnie -serwer SFTP sprawdza dostęp do maszyny klienta poprzez SSH. Jeżeli test przebiegnie pomyślnie, nawiązywane jest połączenie SFTP, przez -które rozpoczyna się transfer plików. SFTP obsługuje transport wielu +serwer SFTP sprawdza dostęp do maszyny klienta poprzez SSH (Secure SHell). Jeżeli test przebiegnie pomyślnie, nawiązywane jest połączenie SFTP, przez +które rozpoczyna się transfer plików. Protokół obsługuje przesył wielowątkowy, gdzie każda operacja transferu ma przypisany unikalny numer +identyfikacyjny, nadawany przez klienta, dzięki czemu serwer może odpowiadać na zapytania klienta asynchronicznie i bez zachowania kolejności. +Aby poprawić wydajność, klient wysyła często wiele zapytań zanim zatrzymuje się i czeka na odpowiedzi.\cite{bib:ssh-article} + +\paragraph{SSH} +SSH (Secure SHell) to standard protokołów, który miał w założeniu stanowić bezpieczną alternatywę dla protokołu telnet. +Do autoryzacji wykorzystuje kryptografię klucz publiczy - klucz prywatny, gdzie w najprostszej postaci +pary kluczy sa generowane automatycznie i służą do zabezpieczenia połączenia sieciowego, natomiast sama autoryzacja +odbywa się za pomocą hasła użytkownika systemu zdalnego.\cite{bib:ssh-rfc} Obecnie najpopularniejszą implementacją protokołu SSH jest OpenSSH, stworzona przez +część członków projektu OpenBSD. Jest wykorzystywana przez większość najpopularniejszych systemów operacyjnych, takich jak +różne dystrybucje Linux, macOS, Microsoft Windows, czy OpenBSD.\cite{bib:openssh-usage} + +\paragraph{Serwer HTTP} +Protokół HTTP (HyperText Transfer Protocol) powstał jako część WWW (World Wide Web) i miał służyć do transferu dokumentów hipertekstowych. +Prace nad nim były prowadzone przez Tima Berners-Lee zatrudnionego w CERN (Conseil Européen pour la Recherche Nucléaire) od 1989 roku +(pierwsza propozycja systemu hipertekstowego opartego o Internet), +gdzie implementacja nastąpiła w 1990 roku, by już rok później pojawiły się pierwsze serwery poza organizacją macierzystą twórcy\cite{bib:http-history}. +W 1997 roku powstała pierwsza ustandaryzowana wersja protokołu, HTTP/1.1, która została wykorzystana w tej pracy.\cite{bib:http-rfc} +HTTP to obecnie bardzo wszechstronne narzędzie, pozwalające obecnie na przesyłanie dowolnych danych poprzez sieć Internet. +Jako protokół jest podstawą współczesnej sieci Web, służy do obustronnego transferu danych pomiędzy serwerami i klientami. +Komunikacja jest rozpoczynana zawsze przez klienta. Tok takiej tranzakcji jest następujący (opis dotyczy wersji HTTP/1.1): -\paragraph{} -Do implementacji pierwszej części wykorzystano język Python, do zaimplementowania prostego serwera oraz klienta synchronizujących -obrazy maszyn wirtualnych, QEMU wraz z KVM do uruchamiania samych maszyn oraz system operacyjny nadzorcy Ubuntu Linux w wersji 22.04 LTS. +\begin{itemize} + \item otwarcie połączenia TCP (Transmission Control Protocol) z serwerem + \item wysłanie zapytania HTTP + \item odebranie odpowiedzi HTTP od serwera + \item zamknięcie połączenia, lub ponowne jego użycie (do wysłania kolejnego zapytania) +\end{itemize} + +Wiadomości HTTP (dla wersji HTTP/1.1 i starszych) mają ustandaryzowany format, czytelny dla człowieka i zapisywalny w postaci tekstu. +Format różni się dla zapytań i odpowiedzi, gdzie zapytanie posiada następujące pola\cite{bib:http-overview}: + +\begin{itemize} + \item metoda HTTP: definiuje operację, którą chce przeprowadzić klient. Może to być np. operacja pobrania danych (metoda GET), czy wysłania danych (metoda POST). Standard HTTP/1.1 zawiera poniższe metody\cite{bib:http-methods}: + \begin{itemize} + \item CONNECT + \item DELETE + \item GET + \item HEAD + \item OPTIONS + \item POST + \item PUT + \item TRACE + \end{itemize} + \item ścieżka dostępu do danych + \item wersja protokołu HTTP + \item opcjonalne nagłówki + \item ciało zapytania, dla metod obsługujących przesył danych z klienta do serwera +\end{itemize} + +Natomiast struktura odpowiedzi jest następująca\cite{bib:http-overview}: + +\begin{itemize} + \item wersja protokołu HTTP + \item kod statusu: jeden z kodów HTTP oznaczający czy zapytanie zostało obsłużone oraz jaki był efekt jego obsługi + \item wiadomość statusu: krótka wiadomość opisująca znaczenie kodu statusu + \item nagłówki HTTP, podobnie do zapytania + \item ciało odpowiedzi, jeżeli wymagane +\end{itemize} + +Z perspektywy prezentowanego projektu ważną cechą protokołu HTTP jest możliwość przesyłu dowolnych danych w ten sam sposób. Zostało to wykorzystane do +stworzenia serwera, który potrafi przesyłać dane do klientów w formacie JSON (JavaScript Object Notation), czyli tekstowym formacie +opisującym (w tym konkretnym przypadku) konfigurację oraz w formacie binarnym, co jest wykorzystywane do przesyłu obrazów maszyn wirtualnych. +Powyższe rozwiązanie zostało wybrane właśnie z powodu łatwości połączenia części przesyłającej konfigurację z serwera do klientów oraz części +przesyłającej obrazy. W dalszej części pracy opisano dokładną architekturę tego rozwiązania, jej zalety oraz wady. + +\paragraph{Maszyny wirtualne} +Maszyna wirtualna to w najprostszym ujęciu programowa implementacja fizycznego urządzenia, która wykonuje zadany program w sposób identyczny +do tego urządzenia. Aplikacja, która to umożliwia jest nazywana nadzorcą (ang. hypervisor). Jej zadaniem jest tłumaczenie zapytań programów +do natywnego sprzętu na zapytania do sprzętu, na którym działa uruchomiona maszyna wirtualna. Istnieje kilka popularnych rodzajów wirtualizacji\cite{bib:virtualization-article}: + +\begin{itemize} + \item pełna wirtualizacja z translacją binarną, rys. \ref{fig:fullvirt-diagram} przedstawia schemat działania takiego systemu + \item wirtualizacja ze wsparciem sprzętowym, rys. \ref{fig:hwvirt-diagram} przedstawia schemat działania takiego systemu + \item wirtualizacja wspierana przez system operacyjny i parawirtualizacja, rys. \ref{fig:paravirt-diagram} przedstawia schemat działania takiego systemu +\end{itemize} + +\begin{figure}[hb] +\centering +\includegraphics[width=0.8\textwidth]{./pictures/paravirt-diagram.png} +\caption{Diagram przedstawiający schemat działania systemu z parawirtualizacją (za \cite{bib:virtualization-article}, rys. 1.6)} +\label{fig:paravirt-diagram} +\end{figure} + +\begin{figure}[hb] +\centering +\includegraphics[width=0.8\textwidth]{./pictures/fullvirt-diagram.png} +\caption{Diagram przedstawiający schemat działania systemu z pełną wirtualizacją (za \cite{bib:virtualization-article}, rys 1.5)} +\label{fig:fullvirt-diagram} +\end{figure} + +\begin{figure}[hb] +\centering +\includegraphics[width=0.8\textwidth]{./pictures/hwvirt-diagram.png} +\caption{Diagram przedstawiający schemat działania systemu ze sprzętowym wsparciem wirtualizacji (za \cite{bib:virtualization-article}, rys. 1.7)} +\label{fig:hwvirt-diagram} +\end{figure} +%Rys. \ref{fig:etykieta-rysunku} przestawia … \paragraph{} -Część odpowiedzialna za obsługę systemów zarządców maszyn wirtualnych została także oparta o system operacyjny Ubuntu Linux w wersji 22.04 LTS, -serwer TFTP oraz PXE do serwowania medium instalacyjnego systemu bazowego nadzorców, cloud-init oraz Ansible do automatyzacji instalacji i konfiguracji hostów. +W prezentowanym projekcie wykorzystano model ze sprzętowym wsparciem dla wirtualizacji poprzez KVM (Kernel Virtual Machine) wraz z QEMU (Quick EMUlator) i technologie +Intel VT-d/AMD-V, pod kontrolą systemu operacyjnego Ubuntu Linux w wersji 22.04 LTS. + +\paragraph{KVM} +KVM to technologia obsługi akceleratorów sprzętowych wirtualizacji wbudowana w systemy z rodziny Linux oparte o jądro w wersji co najmniej 2.6.20, +a jej część przeznaczona dla użytkownika została wbudowana w narzędzie QEMU w wersji 1.3.\cite{bib:kvm-main} + +\paragraph{Intel VT-d/AMD-V} +Technologie Intel VT-d/AMD-V to zbiór rozwiązań technicznych zaimplementowanych podczas tworzenia procesora oraz chipsetu płyty głównej, +które wspierają i ułatwiają używanie maszyn wirtualnych. Sposób działania został opisany na podstawie technologii Intel VT-d.\cite{bib:intel-vt-specs} +Wsparcie dla wirtualizacji zostało tam osiągnięte poprzez zapewnienie: +\begin{itemize} + \item zestawu rozszerzeń dla procesora (nazwanych Intel VMX, Virtual Machine eXtensions) + \item wirtualizacji urządzeń We/Wy (Wejścia/Wyjścia) + \item wirtualizacji dostępu do pamięci +\end{itemize} + +Wirtualizacja dostępu do pamięci jest zapewniana poprzez mechanizm MMU (Memory Management Unit). Jest to układ tłumaczący adresy logiczne +pamięci operacyjnej na jej fizyczne adresy i zapewniający ochronę dostępu procesów do pamięci. + +Wirtualizacja urządzeń We/Wy jest realizowana poprzez mechanizm IOMMU (Input/Output Memory Management Unit). Działa on na analogicznej zasadzie co MMU, zapewniając kontrolę +oraz tłumaczenie adresów logicznych urządzeń do ich adresów fizycznych.\cite{bib:amd64-specs} Pozwala to na przekierowanie +urządzenia bezpośrednio pod kontrolę systemu operacyjnego uruchomionego w maszynie wirtualnej, pomijając sterownik systemu zarządcy. +Technologia ta może zostać wykorzystana do przekazania w taki sposób urządzeń wymagających bardzo niskich opóźnień i dużej przepustowości, +na przykład kart graficznych, lub kart sieciowych. Wtedy pełną kontrolę nad sprzętem otrzymuje system operacyjny gościa w maszynie +wirtualnej, a narzut wirtualizacji na wydajność jest zminimalizowany. + +\paragraph{DHCP} +Protokół DHCP (Dynamic Host Configuration Protocol) odpowiada za automatyczne przypisywanie adresów IP oraz wysyłanie konfiguracji +sieciowej do urządzeń. Jego założeniem była także iteroperatywność z już wtedy istniejącym protokołem BOOTP (BOOTstrap Protocol), przez co +pojedyncze paczki danych (nazwane wiadomościami) są te same dla obu protokołów (z kilkoma odstępstwami).\cite{bib:dhcp-rfc} +Format wiadomości DHCP jest następujący:\cite{bib:dhcp-rfc} + +\begin{itemize} + \item OP (1 bajt): typ wiadomości + \item HTYPE (1 bajt): typ adresu karty sieciowej + \item HLEN (1 bajt): długość adresu karty sieciowej + \item HOPS (1 bajt): ustawiane przez klienta na 0 (zero); używane przez agentów pośredniczących + \item XID (4 bajty): numer identyfikacyjny (ID) tranzakcji; używany do rozpoznania wiadomości przeznaczonych dla konkretnego klienta + \item SECS (2 bajty): liczba sekund od rozpoczęcia procesu odnawiania lub nabywania adresu; ustawiane przez klienta + \item FLAGS (2 bajty): flagi + \item CIADDR (4 bajty): adres IP klienta; uzupełniany tylko, jeżeli klient może odpowiedzieć na zapytanie ARP (Address Resolution Protocol) i jest w stanie BOUND, RENEW, lub REBINDING + \item YIADDR (4 bajty): ,,twój'' (klienta) adres IP + \item SIADDR (4 bajty): adres następnego serwera do użycia podczas pobierania + \item GIADDR (4 bajty): adres agenta pośredniczącego + \item CHADDR (16 bajtów): adres fizyczny klienta + \item SNAME (64 bajty): (opcjonalnie) nazwa serwera, łańcuch znaków zakończony zerem (0) + \item FILE (28 bajtów): nazwa pliku uruchomieniowego, łańcuch znaków zakończony zerem (0) + \item OPTIONS (zmienna długość): opcjonalne parametry +\end{itemize} + +Zdefiniowano następujące wiadomości w protokole DHCP:\cite{bib:dhcp-rfc} + +\begin{itemize} + \item DHCPDISCOVER - Klient wysyła pakiet rozgłoszeniowy, aby zlokalizować dostępne serwery + \item DHCPOFFER - Serwer odpowiada klientowi na zapytanie DHCPDISCOVER z proponowaną konfiguracją + \item DHCPREQUEST - Klient odpowiada serwerowi (a) żądając oferowanych parametrów od jednego serwera i ignorując pozostałe, (b) potwierdzając prawidłowość otrzymanej wcześniej konfiguracji, lub (c) przedłużając dzierżawę adresu IP + \item DHCPACK - Serwer odpowiada klientowi parametrami konfiguracji, wraz z przyznanym adresem IP + \item DHCPNAK - Serwer odpowiada klientowi zaznaczając, że konfiguracja żądana przez klienta jest nieprawidłowa, lub dzierżawa adresu wygasła + \item DHCPDECLINE - Klient odpowiada serwerowi, że dany adres sieciowy jest już w użytku + \item DHCPRELEASE - Klient odpowiada serwerowi, zwalniając dany adres sieciowy i anulując bieżącą dzierżawę + \item DHCPINFORM - Klient wysyła zapytanie serwerowi, prosząc o konfigurację lokalną; adres sieciowy skonfigurowany zewnętrznie +\end{itemize} + +Proces konfiguracji w takiej sieci jest następujący\cite{bib:dhcp-rfc}: + +\begin{itemize} + \item klient wysyła zapytanie \texttt{DHCPDISCOVER} + \item serwer wysyła klientowi proponowaną konfigurację poprzez wiadomość \texttt{DHCPOFFER} + \item klient żąda zadanej konfiguracji poprzez wiadomość \texttt{DHCPREQUEST} + \item serwer odpowiada klientowi wiadomością \texttt{DHCPACK}, jeżeli żądana konfiguracja jest poprawna, w przeciwnym przypadku odpowiada \texttt{DCHPNAK} + \item przy odłączaniu od sieci, klient wysyła wiadomość \texttt{DHCPRELEASE}, zwalniając zajmowany adres sieciowy +\end{itemize} +\paragraph{TFTP} +TFTP (Trivial File Transfer Protocol) to nieskomplikowany protokół przesyłu plików. Jego jedynym zadaniem jest +odczyt pliku po stronie serwera i przesłanie go do klienta. Nie obsługuje listowania plików, ani uwierzytelniania.\cite{bib:tftp-rfc} + +Protokół obsługuje następujące tryby przesyłu danych\cite{bib:tftp-rfc}: + +\begin{itemize} + \item \texttt{NETASCII}, czyli zmodyfikowana forma formatu \texttt{ASCII}, rozszerzona do długości 8 bitów i zawierająca dodatkowe znaki kontrolne + \item \texttt{OCTET}, czyli format przesyłu surowych bajtów danych + \item \texttt{MAIL}, uznany za przestarzały w specyfikacji RFC1350\cite{bib:tftp-rfc} +\end{itemize} + +Proces transferu plików jest następujący\cite{bib:tftp-rfc}: + +\begin{itemize} + \item klient wysyła zapytanie RRQ (read request/żądanie odczytu), lub WRQ (write request/żądanie zapisu), zawierające nazwę pliku i tryb transferu do serwera na port 69 + \item serwer odpowiada pakietem OPTIONS ACK (jeżeli były użyte) i pakietem ACK w przypadku zapytania WRQ; w przypadku zapytania RRQ odpowiedź to od razu pierwszy pakiet żądanych danych + \item maszyna będąca źródłem pliku wysyła go w ponumerowanych segmentach (domyślnie o wielkości 512 bajtów); maszyna odbierająca na każdy segment odpowiada pakietem ACK + \item ostatni segment jest rozpoznawany po wielkości, która jest mniejsza od poprzednich (domyslnie musi mieścić się w przedziale od 0 bajtów do 511 bajtów) + \item jeżeli odpowiedź ACK dla danego segmentu nigdy nie została otrzymana przez maszynę wysyłającą, po upływie określonego czasu (timeout) segment jest retransmitowany +\end{itemize} + +\paragraph{PXE} +PXE (Preboot eXecution Environment) to specyfikacja ustandaryzowanego środowiska pozwalającego na uruchamianie oprogramowania +poprzez sieć. Rozwiązanie takie pracuje w architekturze klient-serwer, gdzie od klienta wymagane jest jedynie posiadanie +odpowiedniej karty sieciowej (wspierającej to rozwiązanie) oraz wsparcie w oprogramowaniu inicjalizującym maszyny, odpowiedzialnym +za uruchamianie oprogramowania (na przykład BIOS/UEFI dla maszyn o architekturze X86). Część serwera jest zbiorem już wcześniej istniejących +rozwiązań, składającym się z serwera DHCP oraz serwera TFTP. \cite{bib:pxe-specs} + +Proces uruchamiania składa się z następujących kroków\cite{bib:pxe-specs}: \begin{itemize} -\item sformułowanie problemu -\item osadzenie tematu w kontekście aktualnego stanu wiedzy (\ang{state of the art}) o poruszanym problemie -\item studia literaturowe \cite{bib:artykul,bib:ksiazka,bib:konferencja,bib:internet} - opis znanych rozwiązań (także opisanych naukowo, jeżeli problem jest poruszany w publikacjach naukowych), algorytmów, + \item wysłanie zapytania \texttt{DHCPDISCOVER} w trybie BROADCAST przez klienta + \item serwer DHCP odpowiada poprzez wiadomość \texttt{DHCPOFFER}; jeżeli serwer DHCP nie implementuje obsługi PXE, wysyła poprawną wiadomość nie zawierającą informacji o lokalizacji plików potrzebnych do uruchomienia minimalnego systemu, a maszyna klienta nie uruchamia się poprzez PXE. W przeciwnym przypadku, serwer DHCP poza zwykłymi informacjami przesyłanymi we wiadomości \texttt{DHCPOFFER} dodaje także informacje o lokalizacji serwera TFTP, gdzie znajdują się pliki potrzebne do uruchomienia minimalnego środowiska uruchomienowego, oraz o nazwach tych plików + \item klient PXE konfiguruje się danymi przesłanymi przez serwer DHCP oraz pobiera pliki uruchomieniowe do pamięci RAM (Random Access Memory); uruchamia otrzymane pliki + \item minimalne środowisko uruchomieniowe powinno pobrać pełen obraz instalacyjny lub obraz systemu do uruchomienia i obsłużyć jego urchomienie/instalację; ten krok najczęściej jest wykonywany poprzez bardziej skomplikowane i niezawodne protokoły, takie jak HTTP, lub NFS \end{itemize} +Jako minimalne środowisko uruchomieniowe wykorzystuje się często zestaw jądra Linux oraz prostego obrazu initrd, które mają za zadanie +pobrać i uruchomić instalator pełnego systemu operacyjnego. -Wzory -\begin{align} -y = \frac{\partial x}{\partial t} -\end{align} -jak i pojedyncze symbole $x$ i $y$ składa się w trybie matematycznym. +%\begin{itemize} +%\item sformułowanie problemu +%\item osadzenie tematu w kontekście aktualnego stanu wiedzy (\ang{state of the art}) o poruszanym problemie +%\item studia literaturowe \cite{bib:artykul,bib:ksiazka,bib:konferencja,bib:internet} - opis znanych rozwiązań (także opisanych naukowo, jeżeli problem jest poruszany w publikacjach naukowych), algorytmów, +%\end{itemize} +% +% +% Wzory +% \begin{align} +% y = \frac{\partial x}{\partial t} +% \end{align} +% jak i pojedyncze symbole $x$ i $y$ składa się w trybie matematycznym. @@ -591,6 +795,17 @@ jak i pojedyncze symbole $x$ i $y$ składa się w trybie matematycznym. \chapter{Wymagania i narzędzia} \label{ch:wymagania-i-narzedzia} +\paragraph{} +Do implementacji pierwszej części projektu wyszczególnionej powyżej wykorzystano język Python, do zaimplementowania prostego serwera oraz klienta, synchronizujących +obrazy maszyn wirtualnych, QEMU wraz z KVM do uruchamiania samych maszyn oraz system operacyjny nadzorcy Ubuntu Linux w wersji 22.04 LTS. + +\paragraph{} +Część projektu odpowiedzialna za obsługę systemów zarządców maszyn wirtualnych została także oparta o system operacyjny Ubuntu Linux w wersji 22.04 LTS, +serwer TFTP oraz PXE do serwowania medium instalacyjnego systemu bazowego nadzorców, cloud-init oraz Ansible do automatyzacji instalacji i konfiguracji hostów. + +\paragraph{QEMU} +QEMU to zintegrowany system do emulacji procesorów poprzez tłumaczenie binarne, potrafi także korzystać z technologii KVM do uruchamiania +aplikacji/maszyn wirtualnych z minimalnym narzutem wydajnościowym. \cite{bib:qemu-main} \begin{itemize} \item wymagania funkcjonalne i niefunkcjonalne \item przypadki użycia (diagramy UML) -- dla prac, w których mają zastosowanie diff --git a/pictures/fullvirt-diagram.png b/pictures/fullvirt-diagram.png new file mode 100644 index 0000000..feb0ff6 Binary files /dev/null and b/pictures/fullvirt-diagram.png differ diff --git a/pictures/hwvirt-diagram.png b/pictures/hwvirt-diagram.png new file mode 100644 index 0000000..de89221 Binary files /dev/null and b/pictures/hwvirt-diagram.png differ diff --git a/pictures/paravirt-diagram.png b/pictures/paravirt-diagram.png new file mode 100644 index 0000000..b65ec48 Binary files /dev/null and b/pictures/paravirt-diagram.png differ diff --git a/pictures/paravirt-diagram.svg b/pictures/paravirt-diagram.svg new file mode 100644 index 0000000..3ba405f --- /dev/null +++ b/pictures/paravirt-diagram.svg @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + + + + Ring 3 + Ring 2 + Ring 1 + Ring 0 + Aplikacje użytkownika + System gościa + Warstwa wirtualizacji + + Warstwa sprzętowa hosta + Bezpośrednie wykonaniezapytania użytkownika + Hiperzapytania (ang. hypercalls)są tłumaczone do zapytań natywnychdla architektury i sprzętu nadzorcy + + + +