Po skonfigurowaniu adresacji, nazw hostów i routingu nasze laboratorium w końcu zaczyna przypominać coś więcej niż tylko kilka maszyn, które „się pingują”. I bardzo dobrze, bo w prawdziwym środowisku sieć nie istnieje po to, żeby podziwiać tablicę routingu, tylko po to, żeby udostępniać usługi i zasoby.
Jednym z najczęstszych praktycznych zastosowań poprawnie skonfigurowanej sieci jest właśnie dostęp do zdalnych plików i katalogów. W pewnym momencie każdy system zaczyna potrzebować rzeczy, które znajdują się gdzieś indziej: wspólnego folderu dla zespołu, miejsca na backup, katalogu z dokumentami, archiwum logów albo udziału na serwerze plików.
Zasoby sieciowe rozwiązują ten problem. Zamiast kopiować pliki tam i z powrotem, montujesz zdalny folder i używasz go jak zwykłego katalogu w systemie. Dla użytkownika i aplikacji to po prostu ścieżka, na przykład /mnt/wspolne, niezależnie od tego, czy dane leżą lokalnie, czy po drugiej stronie sieci.
Ten artykuł jest naturalnym rozwinięciem poprzednich części serii. W pierwszym wpisie skonfigurowaliśmy interfejsy i adresację IP, w drugim uporządkowaliśmy nazwy hostów, plik hosts i DNS, a w trzecim uruchomiliśmy routing między podsieciami. Dzięki temu możemy teraz przejść do czegoś bardzo praktycznego: montowania zasobów z innych maszyn w naszym labie.
W tym poradniku pokażę Ci trzy mechanizmy, które pokrywają większość codziennych scenariuszy związanych z zasobami sieciowymi w Linuxie:
- SMB/CIFS – gdy chcesz korzystać z udziałów z Windowsa,
- NFS – gdy udostępniasz katalogi pomiędzy systemami Linux,
- autofs – gdy chcesz montować zasoby automatycznie dopiero wtedy, gdy są potrzebne.
NFS i autofs w skrócie: o co chodzi i po co mi to?
W środowisku, w którym działa kilka serwerów i stacji roboczych, dane bardzo często są trzymane centralnie i udostępniane innym hostom. Jeden system może wystawić katalog przez NFS (Network File System), a pozostałe maszyny korzystają z niego tak, jakby był lokalnym katalogiem.
Problem pojawia się wtedy, gdy trzeba taki zasób montować ręcznie. Trzeba pamiętać o poleceniach mount, odpowiednich ścieżkach, a przy starcie systemu czasem dochodzą jeszcze opóźnienia albo błędy, gdy serwer plików chwilowo nie odpowiada.
Właśnie tutaj wchodzi autofs. To usługa, która montuje zasób dopiero wtedy, gdy ktoś naprawdę spróbuje z niego skorzystać. Gdy katalog przestaje być używany, autofs po określonym czasie może go odmontować. To wygodne, lekkie i bardzo praktyczne, szczególnie w labach i na serwerach, które nie powinny się blokować przy starcie.
NFS + autofs w naszym laboratorium
W poprzednich artykułach przygotowaliśmy środowisko, w którym Debian potrafi już komunikować się z hostami po drugiej stronie CentOS-a. Wykorzystamy to teraz w praktyce.
W tym scenariuszu:
- Ubuntu (172.16.20.11) będzie udostępniał katalog przez NFS,
- Debian (192.16.0.10) będzie montował ten katalog przez autofs, zasób ma być dostępny jako ubuntu:/home/guests/
- autofs odmontowuje udział po 30 sekundach bezczynności,
- CentOS zapewni trasowanie ruchu między podsieciami,
- Użytkownicy na serwerze i kliencie mają te same UID, katalogi zapisywane są tylko przez właścicieli
Serwer NFS – Ubuntu (172.16.20.11)
Na początku należy zainstalować narzędzia nfs-kernel-server i uruchomić usługę nfs-server. Włączenie enable –now sprawia, że NFS startuje od razu i po każdym restarcie. Jeśli tego kroku zabraknie, klient będzie próbował montować „coś”, czego po prostu nie ma.
sudo apt install -y nfs-kernel-server
sudo systemctl enable --now nfs-serverDodanie reguł firewalla
Następnie należy dodać reguły do firewalla. Te usługi otwierają porty potrzebne do działania NFS (w szczególności rpcbind i mountd). Bez tego klient często kończy z timeoutami albo „permission denied”, mimo że wszystko wygląda poprawnie.
sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --reloadPrzygotowanie katalogu i użytkowników
Załóżmy, że Ubuntu będzie udostępniał katalog /home/guests z katalogami domowymi wybranych użytkowników:
sudo mkdir -p /home/guests
sudo useradd -u 1020 -d /home/guests/magdalena -m magdalena
sudo useradd -u 1021 -d /home/guests/daniel -m daniel
sudo chmod 700 /home/guests/magdalena /home/guests/danielTutaj obowiązuje ta sama zasada co w klasycznym NFS: prawa dostępu nie opierają się na samej nazwie użytkownika, tylko przede wszystkim na numerach UID/GID. Dlatego zarówno na serwerze jak i kliencie identyfikatory muszą się zgadzać.
Eksport w /etc/exports
Aby katalog został udostępniony w sieci należy dodać odpowiedni wpis w /etc/exports. Wpis ten mówi „udostępnij /home/guests hostowi debian z prawem zapisu (rw)”. Opcja sync każe serwerowi potwierdzać zapis dopiero po faktycznym zapisaniu danych na dysku. Opcja no_subtree_check wyłącza sprawdzanie „poddrzewa” przy eksporcie, co zwykle poprawia stabilność i wydajność przy eksporcie katalogów zawierających podkatalogi.
sudo vi /etc/exports
/home/guests debian(rw,sync,no_subtree_check)Następnie przeładuj eksporty:
sudo exportfs -ravSzybka weryfikacja eksportu na serwerze
Polecenie showmount -e pozwala sprawdzić, czy serwer faktycznie „widzi” swoje eksporty. To prosty test, który od razu pokazuje, czy /etc/exports jest poprawny i załadowany.
Klient NFS + autofs – Debian (192.16.0.10)
Podobnie jak wcześniej najpierw należy zainstalować i włączyć odpowiednie usługi. W tym przypadku dodatkowo należy zainstalować autofs.
apt install -y autofs nfs-kernel-server
systemctl enable --now autofsPunkt montowania + użytkownicy (UID muszą się zgadzać z serwerem):
Należy utworzyć katalog, w którym automatycznie zostaną zamontowane katalogi użytkowników z serwera. Użytkownicy muszą mieć identyczne UID jak na serwerze, bo inaczej prawa do plików się nie zepną. Nie musisz tu tworzyć katalogów domowych ręcznie – autofs sam zajmie się montowaniem właściwych ścieżek z serwera.
mkdir -p /home/guests
useradd -u 1020 -M magdalena
useradd -u 1021 -M danielUżyłem tutaj opcji -M, żeby Debian nie tworzył lokalnych katalogów domowych. W tym scenariuszu katalogi mają być montowane zdalnie przez autofs.
Konfiguracja autofs:
Pozostało skonfigurować autofs tak aby montował katalogi w odpowiednim miejscu. Edytuj poniższy plik i dodaj w nim odpowiedni wpis.
vi /etc/auto.master
/home/guests /etc/auto.home --timeout=30Wpis w /etc/auto.master mówi usłudze „zarządzaj katalogiem /home/guests na podstawie mapowania w /etc/auto.home”. Parametr –timeout=30 oznacza automatyczne odmontowanie po 30 sekundach bezczynności.
Plik /etc/auto.home nie istnieje, należy go stworzyć ręcznie. Należy również dodać w nim odpowiednie mapowanie.
vi /etc/auto.home
* -rw,sync ubuntu:/home/guests/&Gwiazda oznacza regułę dla dowolnego katalogu, a znak & podstawia nazwę katalogu, do którego użytkownik próbuje wejść. Dzięki temu:
- wejście do /home/guests/magdalena spowoduje montaż ubuntu:/home/guests/magdalena,
- wejście do /home/guests/daniel zamontuje ubuntu:/home/guests/daniel.
Restart autofs:
Na koniec należy zrestartować usługę autofs aby przeładować konfiguracje i mapowania. Autofs zaczyna działać według nowych zasad.
sudo systemctl restart autofsTest działania montowania:
Zaloguj się na poszczególnych użytkowników i sprawdź zawartość ich katalogów poleceniem ls. W katalogu Magdaleny znajduje sie utworzony plik na serwerze ubuntu co oznacza, że zasób został poprawnie zamontowany. Dodatkowo warto sprawdzić poleceniem mount zamontowane zasoby a potem po 30 sekundach bezczynności sprawdzić ponownie. Jeśli wpis zniknie, oznacza to, że autofs poprawnie odmontował zasób.
Krótko o smb
W sieciach, w których obok Linuxa funkcjonują komputery lub serwery z Windows, bardzo często pojawia się potrzeba dostępu do tych samych plików z obu światów. Najczęściej dotyczy to katalogów roboczych, archiwów, dokumentów użytkowników, zasobów aplikacji albo prostych udziałów „na pliki” utrzymywanych na Windows Server, zwykłej stacji roboczej lub urządzeniu NAS. Zamiast kopiować dane ręcznie, wygodniej jest udostępnić je w sieci i korzystać z nich z Linuxa tak, jakby były lokalnym katalogiem.
Do tego służy SMB (Server Message Block) – standardowy protokół udziałów plików w ekosystemie Windows. Po stronie Linuksa obsługa SMB jest zwykle kojarzona z nazwą CIFS (spotkasz ją w narzędziach i opcjach montowania), a dostęp realizuje się poprzez montowanie udziału w systemie plików. W praktyce oznacza to, że udział typu \Windows\Share można podpiąć np. pod /ShareWindows, a aplikacje i użytkownicy mogą pracować na plikach bez zmiany przyzwyczajeń.
SMB/CIFS – zasób z Windowsa montowany w Debianie
Drugim bardzo częstym scenariuszem jest dostęp z Linuxa do udziałów udostępnionych przez system Windows. I znowu: nie tworzymy osobnego świata tylko do tego jednego ćwiczenia. Wykorzystamy ten sam lab.
W tym przykładzie:
- Windows CL2 (172.16.20.10) udostępnia folder przez SMB,
- Debian (192.16.0.10) montuje go jako udział CIFS,
- CentOS pośredniczy w komunikacji między podsieciami.
Przykład ten pokazuje nie tylko współpracę Linuxa z Windowsem, ale też praktyczne użycie routingu z wcześniejszego artykułu. Debian będzie sięgał po zasób do hosta, który znajduje się po drugiej stronie całej topologii.
Udostępnianie zasobu w Windows CL2
Na Windows CL2 utwórz katalog, na przykład:
C:\SharedNastępnie:
- utwórz lokalnego użytkownika, który będzie używany do dostępu do udziału,
- udostępnij folder w sieci pod nazwą Shared,
- upewnij się, że użytkownik ma odpowiednie prawa do udziału i do systemu plików NTFS, na potrzeby laba ustawiłem pełną kontrolę dla wszystkich
- dodaj jakiś plik testowy.
Montowanie SMB w Debianie
W systemie Windows to wszystko co należy zrobić. Kolejną rzeczą jest zainstalowanie narzędzi cifs w Debianie.
apt install cifs-utilsTworzenie punktu montowania:
Następnie utwórz katalog, do którego ma być zamontowany udział sieciowy z Windowsa.
mkdir /SharedWindows
Szybkie montowanie testowe
Pozostało już tylko zamontowanie katalogu udostępnionego z Windowsa do stworzonego właśnie katalogu. Możemy to zrobić za pomocą poniższej komendy. Wadą tej metody jest to, że po restarcie katalog taki się odmontuje i trzeba będzie go montować ponownie, a także fakt, że hasło ląduje w historii poleceń. Rób to tylko podczas labowania!
mount -t cifs -o username=marek,password=Zaq12wsx //cl2/Shared /SharedWindowsJeśli wszystko zostało zrobione poprawnie powinieneś zobaczyć zamontowany katalog z systemu Windows.
Dużo lepiej przygotować osobny plik z loginem i hasłem i skorzystać z pliku /etc/fstab, który już omawialiśmy wcześniej. Na początku utwórz ukryty plik .secret i wpisz w nim nazwę użytkownika z Windowsa oraz jego hasło.
touch /root/.secret
username=marek
password=Zaq12wsx
chmod 600 /root/.secretNastępnie wpisz poniższą linijkę do pliku /etc/fstab. Po jej wpisaniu zasób ten będzie automatycznie montowany przy każdorazowym starcie systemu. Tutaj szczególnie przydatne są dwie opcje:
- netdev – mówi systemowi, że to zasób sieciowy,
- nofail – system nie wywróci startu, jeśli udział będzie chwilowo niedostępny.
Po zapisaniu możesz sprawdzić wpis bez restartu używając komendy do montowania mount -a, a potem wchodząc do katalogu.
Kopiowanie plików pomiędzy systemami za pomocą scp
Montowanie zasobów sieciowych przez NFS czy SMB/CIFS to bardzo wygodne rozwiązanie, gdy chcesz pracować na zdalnych plikach tak, jakby były lokalne. Nie zawsze jednak potrzebujesz „podpinać” cały katalog. Czasem chcesz po prostu szybko przesłać pojedynczy plik albo cały katalog z jednej maszyny na drugą.
I właśnie tutaj świetnie sprawdza się scp (secure copy). Jeśli znasz polecenie cp, które służy do kopiowania plików lokalnie, to scp będzie bardzo łatwe do zapamiętania – działa bardzo podobnie, tylko potrafi kopiować dane pomiędzy różnymi systemami przez SSH. To oznacza, że podczas przesyłania szyfrowane są zarówno dane, jak i sam proces uwierzytelniania.
Składnia polecenia scp
Składnia polecenia scp jest bardzo prosta i podobna do zwykłego polecenia kopiującego pliki.
scp [opcje] [sciezka źródłowa] [ścieżka docelowa]Jeżeli źródło albo cel znajduje się na zdalnym systemie, używamy formatu:
uzytkownik@host:/ścieżka/do/plikuCzyli:
- po lewej stronie podajesz użytkownika,
- potem adres IP albo nazwę hosta,
- po dwukropku wpisujesz ścieżkę na zdalnym systemie.
W praktyce wygląda to bardzo podobnie do zwykłego kopiowania, tylko jedna ze ścieżek może wskazywać zdalną maszynę.
Przykład 1: kopiowanie pliku z Debiana do Ubuntu
Załóżmy, że pracujesz na Debianie i chcesz wysłać plik do Ubuntu. Najpierw utwórzmy plik testowy:
touch /home/patryk/dokument.txtNastępnie wyślijmy go na Ubuntu:
scp /home/patryk/dokument.txt patryk@ubuntu:/home/patryk/To polecenie:
- skopiuje lokalny plik /home/patryk/dokument.txt
- do katalogu /home/patryk/ na zdalnym hoście Ubuntu
- logując się jako użytkownik patryk.
Przykład 2: kopiowanie pliku z Ubuntu na Debiana
Możemy też zrobić to w drugą stronę, czyli pobrać plik ze zdalnego hosta:
scp patryk@ubuntu:/home/patryk/plik.txt /home/patryk/W tym przypadku:
- źródłem jest plik na Ubuntu,
- celem jest katalog lokalny na Debianie.
To bardzo wygodne, gdy chcesz szybko pobrać logi, kopię konfiguracji albo pojedynczy plik roboczy z innego serwera.
Przykład 3: kopiowanie całego katalogu
Jeśli chcesz przesłać cały katalog wraz z zawartością, użyj opcji -r:
scp -r /home/patryk/projekty patryk@ubuntu:/home/patryk/To przydaje się wtedy, gdy zamiast pojedynczego pliku chcesz przesłać np. cały katalog z dokumentacją, backupem albo zestawem plików testowych.
Najważniejsze opcje scp
Podczas pracy z scp, najczęściej przydają się te przełączniki:
- -P – określa port SSH na serwerze zdalnym,
- -C – włącza kompresję podczas przesyłania,
- -r – kopiuje katalogi rekursywnie,
- -l – ogranicza przepustowość transferu,
- -p – zachowuje czasy modyfikacji, dostępu i uprawnienia,
- -v – pokazuje szczegółowe informacje, przydatne przy debugowaniu.
Co warto zapamiętać?
NFS sprawdza się bardzo dobrze w środowiskach linuksowych, gdy chcesz udostępniać katalogi między serwerami i stacjami roboczymi. autofs świetnie go uzupełnia, bo montuje zasoby dopiero wtedy, gdy są potrzebne. Z kolei SMB/CIFS jest naturalnym wyborem wtedy, gdy Linux ma współpracować z Windowsem. Możesz również wykorzystać scp do przesyłania pojedynczych plików lub folderów.
W naszym laboratorium każdy z tych mechanizmów korzysta z tego, co zrobiłeś wcześniej:
- adresacji,
- nazw hostów,
- routingu,
- poprawnej komunikacji między podsieciami.
I to jest chyba najfajniejsza rzecz w tej serii: każdy kolejny artykuł nie zaczyna wszystkiego od nowa, tylko dokłada następną warstwę do tego samego środowiska. W kolejnym artykule pokaże Ci czym jest protokół SSH i jak z niego korzystać.
