Ostatni  odcinek skończył się pełnym sukcesem i wreszcie router ma dostęp do Internetu. Czas zatem na ważny moment. Z bliżej mi nieznanych przyczyn urządzenia, które kupowałem nawet całkiem niedawno, mają bardzo starą wersję EdgeOS. Wręcz prehistoryczną. W momencie pisania tego tekstu aktualna wersja to 1.9.7 + hotfix 4 (hotfix’y to zupełnie nowy wynalazek, który pojawił się z wersją 1.9.7),  tymczasem na routerze znajdziemy:

Tak, dobrze widzicie. Wersję z połowy 2013 roku, w routerze, który opuścił fabrykę w 2017 roku. Przy okazji, coraz częściej będę od Was oczekiwał samodzielności, więc albo dostaniecie zrzut ekranu i komendę, będziecie musieli odczytać z niego samodzielnie, albo podam Wam polecenie (szczególne jeśli będzie złożone), ale efekt jego działania zobaczycie dopiero jak sami z niego skorzystacie. Wracając zatem do aktualizacji.

Szukamy najnowszej wersji

Celem sprawdzenia najnowszej wersji udajemy się na stronę WWW firmy Ubiquiti Networks i wybieramy kolejno DOWNLOADS w górnym menu, z linii produktów EdgeMAX, a z menu po lewej model, czyli w moim wypadku jest to EdgeRouter Lite.

Po wybraniu wersji, do której chcemy zaktualizować system routera, wybieramy ikonę strzałki po prawej stronie, w kolumnie file, zatwierdzamy licencję EULA jeśli się pojawi (nie zawsze) i… nie, nie. Nic nie pobieramy. Klikamy na przycisk COPY URL.

Oczywiście, że CLI

Jeśli spodziewaliście się pobierania pliku na swój komputer, wgrywania go przez FTP’a, to nic z tych rzeczy. Postawcie się w roli administratora, który musi to zrobić zdalnie, na urządzeniu, które może stać setki albo i tysiące kilometrów od niego. Przecież po to właśnie jest linia komend, by służyła w takiej sytuacji pomocą. Wydajemy zatem polecenie add system image i jeśli korzystacie z programu PuTTY to kliknięciem prawego klawisza myszy wklejacie zawartość schowka lub korzystacie ze skrótu, jaki przewidział producent aplikacji, z której korzystacie. W efekcie wasze polecenie dla wersji 1.9.7 hotfix 4 powinno wyglądać tak:

• add system image https://dl.ubnt.com/firmwares/edgemax/v1.9.7/ER-e100.v1.9.7+hotfix.4.5024004.tar

Po zatwierdzeniu komendy rozpocznie się pobieranie nowej wersji oprogramowania, a jego postęp będzie na bieżąco aktualizowany:

Po pobraniu oprogramowania zostanie ono sprawdzone na wypadek ewentualnych błędów i jeśli takowe nie wystąpiły nastąpi aktualizacja zakończona stosownym komunikatem:

Zwróćcie uwagę, że aktualizacji dokonujemy z trybu operacyjnego a nie konfiguracyjnego! Oczywiście nowa wersja systemu zostanie wczytana po ponownym uruchomieniu routera, a zatem wydajemy polecenie reboot, które należy potwierdzić.

Sprawdzam

Korzystając z poznanej już na wstępie komendy, sprawdzamy efekt naszych działań:

Widać, że nowa wersja została zainstalowana, jest aktualnie uruchomiona (running boot) i zostanie również wczytana przy kolejnym uruchomieniu routera (default boot). Co istotne, na wszelki wypadek stara wersja również jest dostępna na FLASH-u.

Zadanie domowe: jak zmusić router, by przy kolejnym uruchomieniu ponownie załadował stary obraz systemu? Mała podpowiedź: pamiętajcie o znaku zapytania i zwróćcie uwagę, że w trybie operacyjnym też jest dostępna komenda set. Dalej jest już z górki

Kopia zapasowa to podstawa

Należy mieć na uwadze, że migracja konfiguracji jest jednokierunkowa. To znaczy jeśli podnosimy wersję EdgeOS, to konfiguracja zostanie „przepisana” z uwzględnieniem zmian jakie zaszły w składni. Operacja ta nie jest odwracalna, dlatego zawsze przed aktualizacją warto wykonać kopię zapasową konfiguracji, by móc do niej wrócić, jeśli zajdzie potrzeba przywrócenia starej wersji oprogramowania. Niestety z tego co wiem, nie istnieje równie prosta metoda pobrania pełnej kopii zapasowej z CLI i do tego celu należy posłużyć się GUI. Co nie znaczy, że dla chcącego nic trudnego. Tym bardziej ambitnym podpowiem, że plik konfiguracyjny znajdą w lokalizacji /config/config.boot. Inna opcja to wyświetlenie bieżącej konfiguracji w postaci zestawu poleceń konfiguracyjnych, które można w prosty sposób skopiować, czy to między urządzeniami, czy do pliku. Służy do tego komenda show configuration commands.

To jeszcze nie koniec

Co prawda temat „podstaw” wyczerpaliśmy, nie znaczy to jednak końca przygód z routerami Ubiquiti. Wręcz przeciwnie, wiele jeszcze zostało do omówienia, ale będą to już tematy nieco bardziej zaawansowane, jak konfiguracja firewall’a, VLAN’y, VPN’y… Będziemy korzystać zarówno z CLI, jak i graficznego interfejsu użytkownika (GUI). I tak dalej. Także zaglądajcie regularnie na TestHub.pl po kolejne poradniki. I piszcie w komentarzach, co Was szczególnie interesuje.

Artykuł Podstawy pracy z interfejsem linii komend (CLI) systemu EdgeOS – część 3 pochodzi z serwisu TestHub.pl.

Zanim przejdziemy dalej, taka mała uwaga organizacyjna. Jeśli jakieś zagadnienia są dla Was obce lub niejasne i wymagają objaśnienia, zadawajcie pytania w komentarzach, ale zachęcam też do samodzielnego poszukiwania odpowiedzi w Internecie. Tak zdobyta wiedza daje dużą satysfakcję i zostaje na dłużej. Dajcie też znać, czy poruszane zagadnienia są dla Was ciekawe.

Czas na show!

Z lektury pierwszej części wiecie już, jakie są tryby pracy CLI oraz jak przejść do edycji konfiguracji, zatwierdzić zmiany czy zapisać je w konfiguracji startowej. A jak wyświetlić podstawowe informacje o urządzeniu, czyli sprawdzić jego konfigurację czy adresację interfejsów? Służy temu komenda „show” z dodatkowymi opcjami. I tak bieżącą konfigurację wyświetla polecenie „show configuration”. Poniżej wynik tej komendy na routerze EdgeRouter Lite z konfiguracją domyślną (czyli po wyjęciu z pudełka lub przywróceniu ustawień fabrycznych).

Jak widać, konfiguracja przywodzi na myśl jakiś język programowania i początkowo może wydawać się straszna, ale z czasem nie będzie miała dla was żadnych tajemnic. Widać, że jest podzielona na sekcje, a wcięcia oznaczają szczegóły konfiguracji danego elementu. I tak, konfiguracja interfejsów to sekcja „interfaces”, która zawiera interfejsy Ethernet oznaczone kolejno „eth0″, „eth1″ oraz „eth2″, jak i interfejs loopback. Jak widać, tylko interfejs „eth0″ posiada dodatkowe opcje, w tym wypadku jest to adres IP i maska, odpowiednio 192.168.1.1 oraz 255.255.255.0 (bo właśnie taka maska to inaczej 24 bity).

Adresacja interfejsów

Skoro potrafimy już modyfikować konfigurację, a w pierwszej części w przykładach kasowaliśmy i dodawaliśmy adresy, to dostosujmy konfigurację routera do naszych potrzeb. Przyjmijmy, że chcemy, aby interfejs „eth0″ był interfejsem do sieci Internet (WAN) i uzyskiwał adres automatycznie z DHCP, a na interfejsie „eth1″ chcemy skonfigurować naszą sieć lokalną (LAN) z adresem 192.168.100.1 i maską 255.255.255.0. Poniżej lista komend które musimy wydać, plus krótki komentarz:

• „configure” – aby przejść do trybu konfiguracji,
• „delete interfaces ethernet eth0 address 192.168.1.1/24” – musimy skasować niepotrzebny nam adres,
• „set interfaces ethernet eth0 address dhcp” – konfigurujemy interfejs „eth0” na pobieranie adresu z DHCP,
• „set interfaces ethernet eth1 address 192.168.100.1/24” – nadajemy adres interfejsowi „eth1”,
• „commit” – zatwierdzamy zmiany.

Rezultat zmian możecie zweryfikować znanym już poleceniem „show configuration”, ale w tym wypadku miałoby ono jedną wadę. Mianowicie poznalibyście konfigurację bieżącą interfejsów, ale zamiast adresu interfejsu „eth0”, uzyskalibyście tylko informację, że ma on być pobrany z DHCP. Zmieńmy zatem komendę na „show interfaces”.

Tak jest znacznie lepiej, widzimy listę interfejsów (Interface), ich adresy IP (IP Address) oraz ich stan (S/L), plus ewentualny opis (Description). Czym są te dwie ostatnie kolumny? Pierwsza z nich – S/L, informuje nas o tym, czy interfejs jest administracyjnie włączony (u, z ang. Up) czy wyłączony (A, z ang. Admin Down) oraz jaki jest status linku – aktywny (u) lub nieaktywny (D, z ang. Down). Na czym polega różnica? Link to stan fizyczny – urządzenie sprawdza, czy jest połączone z innym, natomiast stan administracyjny to możliwość celowego włączenia lub wyłączenia interfejsu przez użytkownika. Ostatnie pole pozwala na dodanie do interfejsu krótkiego komentarza, co niewątpliwe ułatwi w przyszłości nam lub innym osobom zrozumienie konfiguracji.

Zostaw sobie wiadomość

Każdy programista wie, jakim koszmarem jest czytanie kodu, nawet własnego, pozbawionego komentarzy. Dla administratora sieci podobny koszmar to brak jakiejkolwiek dokumentacji. Skoro zatem mamy taką możliwość, zostawmy sobie (lub innym) wiadomość, by w przyszłości mieć prostsze zadanie. Komenda, której użyjemy ma postać „set interfaces ethernet ethX description 'komentarz'”, gdzie „x” oznacza oczywiście numer interfejsu. Przy okazji wyłączmy nieużywany interfejs „eth2″ poleceniem „set interfaces ethernet eth2 disable” i porównajmy wynik z wcześniejszym:

Czyż tak nie jest zdecydowanie lepiej? Od razu wiemy, który interfejs jaką rolę pełni, a nawet dodaliśmy informację o operatorze. Nie ma to wielkiego znaczenia, gdy korzystamy z jednego ISP, ale gdybyśmy mieli dwa interfejsy WAN do dwóch dostawców, wtedy na pewno w przyszłości docenimy własną zapobiegliwość. Widzimy również, że stan interfejsu „eth2” został oznaczony literką „A”, czyli wyłączony przez administratora. Tak na marginesie, wyłączanie nieużywanych interfejsów jest dobrą praktyką, zapobiegającą ewentualnym problemom, gdyby ktoś inny lub nawet sami w pośpiechu, roztargnieniu lub z innego powodu, wpięlibyśmy tam jakiś niewłaściwy kabelek.

Interfejs myszki Miki

Ci najbardziej zniecierpliwieni mogą wreszcie odetchnąć z ulgą, uruchomić przeglądarkę i po zaadresowaniu karty sieciowej w podsieci 192.168.100.0/24 i skierowaniu się pod adres https://192.168.100.1 skorzystać z graficznego interfejsu użytkownika. Oczywiście w przypadku powyższej konfiguracji kabel Ethernet wpiąć należy do interfejsu „eth1”. Przy pierwszym skorzystaniu z interfejsu webowego pojawi się komunikat jak niżej z prośbą o zaakceptowanie licencji użytkownika.

Zapominalskim przypominam, że domyślny login i hasło to ubnt.

Routing

Jeśli jednak spodobała się Wam praca z CLI to zapraszam do dalszej lektury. Czego jeszcze potrzebujemy, by móc wreszcie skorzystać z Internetu? Tak, dobrze słyszę, ktoś krzyczy o bramie i/lub routingu? Oczywiście, nasz router musi wiedzieć dokąd kierować ruch. Ale zaraz zaraz, czy on na pewno tego już nie wie? Możemy to sprawdzić wyświetlając tablicę routingu poleceniem „show ip route”.

Ależ wie, dzięki DHCP. Oczywiście nie zawsze jest tak dobrze, że dostawca udostępnia DHCP i czasem musimy adresację i bramę ustawić ręcznie. Adresację już omówiliśmy, zatem pozostaje kwestia bramy. Można ją skonfigurować na dwa sposoby – oba równie dobre i dające ten same efekt.

• „set system gateway-address 172.23.0.1”

lub

• „set protocols static route 0.0.0.0/0 next-hop 172.23.0.1”

Jak wspomniałem efekt, czy to będzie adres uzyskany z DHCP, czy skonfigurowany jedną z tych dwóch komend, będzie taki sam. Po prostu, ta pierwsza komenda jest prostsza do zapamiętania i zrozumienia przez mniej zaawansowanych użytkowników, dla których zagadnienia routingu statycznego i dynamicznego brzmią jak czarna magia i niekoniecznie wiedzą lub chcą wiedzieć co oznacza adres sieci 0.0.0.0/0.

Serwery DNS

Analogicznie do bramy domyślnej wygląda kwestia serwera(ów) DNS lub jeśli ktoś woli serwera(ów) nazw (z ang. name server). Jeśli korzystamy z DHCP, wówczas router pobierze je automatycznie. W przeciwnym wypadku musimy je dodać sami komendą „set system name-server x.x.x.x” gdzie „x.x.x.x” to oczywiście adres IP serwera DNS. Jeśli chcemy dodać więcej niż jeden serwer, kolejne dodajemy ponownie wprowadzając tę komendę. Ja zachęcam do skorzystania z serwerów OpenDNS, których adresy to 208.67.222.222 oraz 208.67.220.220. Wystrzegajcie się natomiast tak popularnych serwerów firmy Google o adresach 8.8.8.8 oraz 8.8.4.4, gdyż jest to jeden ze sposobów szpiegowania Was przez tę firmę i serwowania Wam reklam, między innymi w oparciu o odwiedzane przez Was strony. Przykład konfiguracji serwerów OpenDNS:

NAT

Tak skonfigurowany router będzie już miał dostęp do Internetu, co możemy zweryfikować poleceniem „ping”.

Możecie w tym miejscu spytać, czemu najpierw robię ping dla adresu IP, a potem dla domeny? Z bardzo prostej przyczyny – brak odpowiedzi na ping na znany adres IP, o którym wiemy, że nie filtruje zapytań ICMP pozwala sprawdzić czy mamy poprawną adresację i czy wszystko działa, natomiast ping nazwy pozwala sprawdzić, czy poprawna jest konfiguracja serwerów nazw i otrzymujemy od nich odpowiedź. Jeśli jednak ten sam manewr wykonalibyście z komputera, okaże się, że test zakończy się niepowodzeniem. Tak, tak, została jeszcze jedna rzecz do skonfigurowania czyli NAT lub jak wolą inni PAT, a miłośnicy Linuksa zakrzykną maskarada (z ang. masquerade), bo przecież w Linuksie wszystko musi być inaczej ;P Wydajemy więc komendy:

• „set service nat rule 5000 outbound-interface eth0”,
• „set service nat rule 5000 protocol all”,
• „set service nat rule 5000 type masquerade”.

Bardziej zaawansowaną konfigurację mechanizmów NAT jeszcze omówimy, więc w skrócie, powyższe komendy tworzą regułę numer 5000. Nie jest on przypadkowy, EdgeOS narzuca zakresy numeracji w zależności od rodzaju NATu i w przypadku nie zastosowania się do wytycznych, po prostu dostaniemy komunikat błędu. Reguła, którą utworzyliśmy mówi, aby stosować maskaradę (dynamiczny NAT adresów źródłowych), dla wszystkich protokołów, dla pakietów wychodzących interfejsem „eth0”.

Sukces, udało się nam skonfigurować router z systemem EgdeOS do obsługi Internetu Ale zanim zaczniecie świętować. profilaktycznie zmieńcie użytkownika i hasło:

• „set system login user testhub authentication plaintext-password 'haslo'”.

Konieczne jest też usunięcie użytkownika „ubnt”, ale nie uda się wam tego zrobić bez wylogowania i zalogowania jako nowy, przed chwilą dodany użytkownik „testhub”, gdyż otrzymacie komunikat błędu „Attempting to delete current user: ubnt”. Zatem wydajemy polecenie „exit” w trybie operacyjnym, co spowoduje wylogowanie i logujemy się już jako nowy użytkownik.

Przypominam o zapisaniu konfiguracji! I jeszcze ważna uwaga. Gdybyście po dodaniu użytkownika zajrzeli do konfiguracji to odkryjecie, że hasło, które przed chwilą podaliście jawnym tekstem, w konfiguracji jest zaszyfrowane. Również w pliku z kopią zapasową jest ono nie do odczytania (dla dociekliwych jego fragment wygląda tak: $6$Xzz6titfBc$SVwMWbuZAk3oBZPFbZKWjKSP87gCjsQ….), zatem warto je zapamiętać, bo w przypadku jego utraty konieczny będzie restart urządzenia do ustawień fabrycznych, co oznacza pożegnanie się z konfiguracją, często długo dopieszczaną i dopracowywaną.

Podsumowanie

Nie, tym razem nie będę przypominał wszystkich komend jeszcze raz. Za to zachęcam do przećwiczenia ich celem utrwalenia, zabawy ze zmianą adresacji i odkrywania dodatkowych opcji, które podpowie wam znak zapytania. Na zachętę zdradzę komendę „show configuration all”. Napiszcie w komentarzach swoimi słowami, czym różni się jej wynik od samego „show configuration”.

Artykuł Podstawy pracy z interfejsem linii komend (CLI) systemu EdgeOS – część 2 pochodzi z serwisu TestHub.pl.

System operacyjny routerów serii EdgeMax firmy Ubiquiti Networks, nosi nazwę EdgeOS. Bazuje on na Debian GNU Linux, przy czym posiada własny command line do konfigurowania wszystkich usług, dzięki czemu nie musimy sięgać do plików konfiguracyjnych każdej usługi systemu Linux z osobna oraz interfejsu graficznego (GUI). Swoimi korzeniami EdgeOS sięga projektu VyattaOS w wersji 6.3 community edition (system dostępny był w niekomercyjnej edycji community oraz jako produkt komercyjny). Świadomie i celowo unikam określenia EdgeOS jako fork’a systemu VyattaOS z dwóch powodów. W świecie free and open source software przyjmuje się, że fork to projekt rozwijany równolegle i okresowo aktualizowany względem swojego pierwotnego źródła. I tak forkiem Ubuntu jest Kubuntu, przy czym oba projekty są rozwijane równolegle, sięgają do tych samych repozytoriów, a kolejne wersje wydawane są w podobnym cyklu. Taka zależność nie zachodzi pomiędzy EdgeOS a VyattaOS, ponieważ ten drugi system nie jest już rozwijany (powstał co prawda projekt VyOS, ale to już temat na inną okazję), w konsekwencji zakupu firmy Vyatta przez Brocade w 2012 roku. Ostatnia wersja VyattaOS 6.6 wydana została w maju 2013 roku. Zatem właściwie od początku, bo EdgeOS w wersji 1.0.2 wydany został 7 listopada 2012 roku, rozwijany jest jako osobny projekt.

Tryb operacyjny i tryb konfiguracji

Po zalogowaniu do systemu (poprzez port konsoli, z użyciem protokołu SSH lub z poziomu okna terminala w GUI), lądujemy w trybie nazwanym przez producenta „operacyjnym” (z ang. operational mode), który rozpoznajemy po znaku zgłoszenia (z ang. prompt) „admin@CERBER:~$”, zakończonym symbolem „$”. Tak przy okazji, prompt składa się z nazwy użytkownika oraz nazwy hosta, w tym wypadku jest to użytkownik „admin”, na hoście o nazwie „CERBER”. Listę wszystkich dostępnych w tym trybie komend uzyskamy przez wprowadzenie w terminalu znaku zapytania „?”,  co poskutkuje wyświetleniem samych nazw komend, a jeśli ponownie wprowadzimy znak zapytania, efektem będzie lista w postaci komend, z ich krótkim opisem. Zatem zobaczmy, jak to działa w praktyce (w terminalu nie widać znaków zapytania wprowadzonych z klawiatury).

Więcej o poszczególnych komendach opowiem w kolejnych częściach cyklu, natomiast na tym etapie poznawania CLI najważniejsza z nich to „configure”, która pozwala przejść do trybu konfiguracji (z ang. configuration mode). O zmianie trybu informuje zmieniony znak zgłoszenia na „#”. Poniższy obrazek prezentuje, jak taka operacja wygląda w praktyce i od razu skorzystajmy z podpowiedzi, którą już wiecie jak uzyskać.

Z trybu konfiguracji do trybu operacyjnego wracamy komendą „exit”.

Hello world!

Nie, programować nie będziemy, ale spróbujmy coś wreszcie skonfigurować. Kluczową komendą, która pozwala ustawić wartość parametru lub stworzyć nowy element to „set”.  Jeśli zatem chcielibyśmy zmienić nazwę hosta, powiedzmy na „testhub”, to w trybie konfiguracji trzeba użyć komendy „set system host-name testhub”. Tak, wiem, poza set pojawiło się jeszcze kilka opcji, których nie znacie, ale wszystko z czasem się wyjaśni. Co bardzo ważne, samo wydanie tego polecenia nie spowoduje absolutnie żadnych zmian. Osoby przyzwyczajone do pracy z CLI Cisco, mogą w tym momencie być nieco zaskoczone, zaś te zaznajomione, np. z CLI Junipera, poczują się prawie jak w domu. Otóż zmiany (może być ich wiele) musimy zatwierdzić komendą „commit”. Rozwiązanie to ma swoje zalety – wybiegnę tu trochę do przodu, ale chcę, żebyście zrozumieli istotę tego rozwiązania. Powiedzmy, że potrzebujecie zmienić adres IP interfejsu WAN pracując zdalnie. Kroki, jakie w tym celu trzeba uczynić, to usunąć stary adres i dodać nowy. Czyli w tym wypadku, byłyby to kolejno komendy „delete interfaces ethernet eth0 address stary_adres_IP” i zaraz po niej „set interfaces ethernet eth0 address nowy_adres_IP”. Już macie pomysł, czemu bez „commit” mielibyśmy problem? Gdyby pierwsza komenda została wykonana od razu po wprowadzeniu, interfejs straciłby adres IP i odcięlibyśmy się od routera, zanim zdążylibyśmy wprowadzić nowy adres IP. Dzięki temu, że zmiany są wykonywane dopiero po poleceniu „commit”, możemy wprowadzić wszystkie zaplanowane zmiany i dopiero na koniec niejako nakazać ich wykonanie. W praktyce wyglądałoby to tak:

Uważni czytelnicy, zapewne zauważyli jeszcze jedną komendę, mianowicie „save”. Popularnie stosowane urządzenia domowe, czasem pogardliwie nazywane „mydelniczkami” (zapewne z racji kształtu i plastikowej obudowy), mają tę cechę, moim zdaniem brzydką, że od razu wszystkie wprowadzone zmiany zapisują. Czemu brzydką? Bo jak coś popsujemy w konfiguracji, to często zostaje tylko reset do ustawień fabrycznych. Dlatego te bardziej zaawansowane urządzenia, posiadają zazwyczaj niezależnie dwie konfiguracje – bieżącą, czyli tę, którą modyfikujemy i startową, czyli tą, z którą urządzenie się uruchomiło. Aby zmiany dokonane w konfiguracji bieżącej utrwalić w konfiguracji startowej, należy je zapisać i temu jak się zapewne już domyśliliście, służy komenda „save”. Jej odpowiednikiem, np. w CLI Cisco jest „copy running-config startup-config”.

Tylko bez paniki ;(

Jak się ratować w sytuacji, gdy zdarzy się wam błąd? Jedną z opcji poznaliście – przed zapisaniem konfiguracji zawsze można ratować się restartem urządzenia. Jest to jednak rozwiązanie nieeleganckie i nieefektywne (tracicie w ten sposób owoc często długich minut spędzonych na konfigurowaniu urządzenia), a w przypadku routerów z EdgeOS, nie wolno tego robić poprzez zwyczajne wyłączenie zasilania, gdyż bez poprawnego zamknięcia systemu operacyjnego można uszkodzić system plików.

Rozważmy zatem kilka przypadkowych problemów. W najprostszym, niech to będzie literówka w poleceniu, a zatem trzymając się wcześniejszego przykładu, zamiast nazwy hosta testhub wprowadziliśmy polecenie „set system host-name tetshub”. Rozwiązanie jest bardzo proste i zamiast zatwierdzać zmiany, po prostu je odrzucamy komendą „discard”. Tu od razu uwaga – samo wyjście z trybu konfiguracji poleceniem „exit” nie wystarczy – system zasygnalizuje błąd „Cannot exit: configuration modified”, mówiący o tym, że dokonano zmiany konfiguracji. Można natomiast połączyć te polecenia w jedno i wydać komendę „exit discard”.

Jeśli zdarzy się, że błąd spostrzeżemy już po jego zatwierdzeniu, pomocna jest komenda „delete”, która pojawiła się przy okazji dygresji o zmianie adresacji, a służy do usuwania wartości parametru lub elementu. Zróbmy zatem celowo błąd, a potem go usuńmy.

Co się wydarzyło? Zachowałem się jak początkujący administrator i popełniwszy błąd w adresie IP w komendzie „set interfaces ethernet eth1 address 10.10.10.1/24″, postanowiłem go poprawić, wydając polecenie po raz kolejny, ale tym razem z dobrym adresem „set interfaces ethernet eth1 address 20.10.10.1/24″. I tu tkwi pułapka na początkujących adeptów administracji sieciami – otóż w przeciwieństwie do wspomnianych „mydelniczek”, nie jest niczym niezwykłym dla takiego routera posiadanie dwóch adresów na jednym interfejsie, co pokazuje powyżej komenda „show interfaces ethernet eth1″. Rozwiązaniem tego problemu jest właśnie komenda  „delete” i w tym przypadku miałaby ona postać „delete interfaces ethernet eth1 address 10.10.10.1/24″. Przy okazji widać, że router przypomina o konieczności zapisania zmian, jeśli tego nie uczyniliśmy, a skorzystamy z komendy „exit”. 

Uzupełnianie komend

Podczas pracy z CLI, drugim użytecznym klawiszem na klawiaturze, poza już poznanym znakiem zapytania jest Tabulator, na części klawiatur opisany jako Tab. Działa on podobnie jak u innych producentów i pozwala szybko uzupełniać komendy. Na przykład, jeśli napiszemy tylko litery „sh” i wciśniemy klawisz Tab, system podpowie nam, że tak rozpoczynają się dwie komendy „show”  oraz „shutdown”, natomiast ten sam Tab naciśnięty po literach „shu”, już bez dalszych podpowiedzi uzupełni się do „shutdown”.

Podsumowanie

Powinniście już umieć poruszać się po trybach operacyjnym i konfiguracji, do którego przechodzimy komendą „configure”, a wychodzimy z niego poleceniem „exit”. Zmiany wartości parametru lub dodanie elementu realizuje „set”, natomiast skutek odwrotny uzyskamy, sięgając po „delete”. Zmiany należy zatwierdzić poleceniem „commit” lub odrzucić komendą „discard”. Aby utrwalić zmiany w konfiguracji bieżącej należy je zapisać komendą „save” w konfiguracji startowej. W każdej chwili możecie też skorzystać z pomocnych klawiszy „?” oraz „Tab”.

Artykuł Podstawy pracy z interfejsem linii komend (CLI) systemu EdgeOS – część 1 pochodzi z serwisu TestHub.pl.