Bądź na bieżąco - RSS

Mikrotik – problemy z L2TP

27 października, 2019 | Brak Komentarzy | Kategoria: Porady, Windows
Mikrotik

Routery Mikrotik na przestrzeni 20 lat zdobyły ogromną popularność. Sam byłem bardzo zaskoczony gdy dowiedziałem się, że ta litewska firma zatrudnia ponad setkę pracowników i jest notowana wśród 20 największych biznesów w swojej ojczyźnie. Można powiedzieć, że jest to przykład dużego sukcesu w dziedzinie, która dla wielu z nas nie istnieje ze względu na aktualną modę na serverless business oraz rozwiązania chmurowe.

Jedną z cech urządzeń Mikrotik, które mnie osobiście przekonała najbardziej jest możliwość szybkiego i łatwego skonfigurowania zestawu serwerów VPN, od najprostszego PPTP począwszy po OpenVPN czy L2TP. Nie ukrywam, że od wielu lat, z różnych względów moim faworytem jest właśnie ten ostatni protokół. W artykule nie chciałbym jednak skupiać się na opisie jego budowy za pomocą MikrotikOS, a bardziej na kliencie VPN L2TP.

Wspomniany klient jest zazwyczaj dostarczany w postaci natywnej razem z systemem operacyjnym. Jak go skonfigurować można dowiedzieć się bezpośrednio pod linkiem https://tinyurl.com/m8ytljr. Powinien działać od razu. Jednak po kolejnych aktualizacjach systemu Windows 10 pojawiły się problemy ze stabilnością połączeń L2TP. Przez dłuższy czas użytkownicy odwoływali się do różnych trików. Jedne były bardziej a inne mniej pomocne i skuteczne. Tymczasem ostatnio pojawiło rozwiązanie potwierdzone jednoznacznie przez Microsoft TechNet.

Aby zapewnić sobie prawidłową konfigurację połączeń L2TP VPN w windows 10 należy skorzystać z edytora rejestrów systemowych i znaleźć klucz:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent

Następnie tworzymy nową zmienną typu DWORD (32-bit) Value oraz nazywamy ją AssumeUDPEncapsulationContextOnSendRule. Aby zastosować omawianą łatkę należy jej nadać wartość 2. Ostatnią czynością będzie nieśmiertelny restart systemu Windows w celu załadowania nowych, poprawnych ustawień. Ta prosta czynność ułatwi nam nieprzerwaną pracę w sieci opartej o VPN typu L2TP.

MG

Tagi: ,

OpenVAS – testy penetracyjne

29 września, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
OpenVAS

W dzisiejszych czasach wykonywanie testów penetracyjnych jest, lub przynajmniej powinno być, elementarzem każdego administratora, który zarządza siecią z serwerami obsługiwanymi przez innych użytkowników. Doświadczenie uczy, że pomysłowość ludzka polegająca m. in. na pozostawianiu niezabezpieczonych usług, skonfigurowanych niepoprawnie aplikacji itp. jest praktycznie nieograniczona. Niestety sieć jest tak bezpieczna jak jej nasłabszy punkt. Dlatego chciałem napisać parę słów o dosyć popularnym i prostym w obsłudze narzędziu jakim jest OpenVAS.

Większość popularnych dystrybucji Linuxa posiada gotowe paczki do instalacji. W Debianie 10 Buster (jak do tej pory ostatnim) nie trzeba nawet wspomagać się dodatkowymi bibliotekami, wystarczy wydać polecenie:

apt-get install openvas -y

Po kilku lub kilkunastu minutach, w zależności od stanu łacza internetowego, cały pakiet zostanie zainstalowany i można przejść do jego konfiguracji:

openvas setup

Aplikacja rozpocznie pobieranie aktualizacji z 3 źródeł – NVT, Cert Data i SCAP Data, tak abyśmy mieli dostęp to świeżego zestawu testów, czyli tak naprawdę np. najnowszych definicji dotyczących exploitów, opisanych zagrożeń itp. Całość trochę potrwa i na koniec zostaniemy poinformowani o sukcesie (mam nadzieję) oraz co najważniejsze wyświetlone zostanie hasło dla administratora usługi. Hasło w zasadzie jest jednorazowe i należy je zmienić od razu po pierwszym zalogowaniu, tym bardziej, że nie jest wygodne do zapamiętania.

OpenVAS jest obsługiwany za pomocą przeglądarki internetowej. Domyślnie skonfigurowany jest tylko dostęp lokalny. Może to stanowić pewne utrudnienie, szczególnie w sytuacji gdy korzystamy z serwera bez środowiska graficznego. Dlatego powinniśmy sprawdzić adres IP swojego serwera:

ip a

Następnie trzeba wedytować 2 pliki konfiguracyjne:

/lib/systemd/system/greenbone-security-assistant.service
/lib/systemd/system/openvas-manager.service

i zmienić adres ‚127.0.0.1’ na uzyskany adres naszego serwera – w każdym miejscu, w którym występuje.

Na koniec pozostaje uruchomić ponownie usługę OpenVAS:

systemctl daemon-reload 
openvas-stop
openvas-start

Od tej chwili możemy cieszyć się w pełni funkcjonalnym skanerem sieci do celów testów penetracyjnych. Otwieramy przeglądarkę i podajemy adres:

https://adres_ip_serwera:9392

MG

Tagi: , , , ,

Wysoki uptime – jak nie restartować serwera

26 maja, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Uptime - system is up to date

Być może obecnie nie jest to specjalnie popularne, ale dawno, dawno temu jednym z parametrów świadczących o stabilności serwera i zarazem o zdolnościach jego administratora był tzw. uptime. Żyjemy w czasach gdy aktualizacje systemowe bardzo często wymuszają restart całego systemu. Niestety nie dotyczy to tylko serwerów Windows, co kiedyś było głównie ich domeną, ale również serwerów opartych o jądro Linuxa. Często tego typu działania kończą się wyzerowaniem licznika serwera i wspomniany uptime rozpoczyna zliczanie od początku.

Stare nawyki jednak pozostają na trwałe w pamięci i o ile dla Windowsów przestałem się wogóle przejmować ponownym uruchamianiem systemu, o tyle w przypadku ulubionego Debiana za każdym razem ręka drżała jeśli po aktualizacji pojawiał się komunikat o nowych bibliotekach systemowych czy o zgrozo nowej wersji jądra.

Tak było przez kilkanaście lat. Po prostu uznałem, że tak musi być i za każdym razem wolałem dla świętego spokoju zrestartować system. I nagle w zeszłym tygodniu, przy okazji serii aktualizacji serwerów, pojawiła się myśl, że być może są jakieś narzędzia, które podpowiedzą czy na pewno muszę tracić licznik uptime. Okazało się, że jak najbardziej można sobie pomóc. W końcu to Linux.

Pierwsza metoda jest niezwykle prosta. Po każdej aktualizacji należy sprawdzić czy w określonym miejscu pojawił się plik systemowy o nazwie reboot-required. Wygląda to następująco:

$ ls /var/run/reboot-required

Jeśli otrzymamy wynik pozytywny to oczywiście musimy ponownie uruchomić serwer.

Druga metoda polega na zainstalowaniu narzędzia o nazwie needrestart.

$ apt-get install needrestart

Różnica polega na tym, że w wyniku jego działania np. po ręcznym wywołaniu komendy, otrzymamy pełen raport dotyczący nie tylko zrestartowania systemu ale również usług, które należy uruchomić ze względu na nowe wersje bibliotek systemowych. Dodatkowym bonusem jest fakt, że po każdorazowej aktualizacji needrestart zostanie uruchomiony samoistnie i podpowie co należy zrobić dalej. Czyli prawie jak na Windowsach. 😉

MG

Tagi: , , ,

Hasło root – jak je odzyskać?

28 kwietnia, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Hasło root

Czasami zdarza się nam zapomnieć hasła. Nie jest to żaden duży problem jeżeli np. chodzi o konto w usłudze internetowej gdzie zazwyczaj dostępna jest opcja przypomnienia za pomocą adresu e-mail. Jednak inaczej sprawa wygląda gdy zapomnieliśmy hasła administracyjnego, a jeszcze gorzej hasła administratora dla konta root w systemie opartym o jądro Linuxa. No właśnie. Pytanie brzmi jak odzyskać hasło root?

Istnieje sporo metod pozwalających odzyskać takie hasło, a dzisiaj chciałem skupić się na systemie Debian w wersji 9. Pisze o tym ponieważ całkiem niedawno padłem ofiarą własnego gapiostwa i zakładając kilka maszyn wirtualnych pod rząd zdecydowałem, że nie będę zapisywał haseł. Oczywiście przesłałem je użytkownikom ale… niestety w kilku przypadkach z błędem. Mając alternatywę przygotowywania systemów od początku i wizję kolejnych spędzonych bezproduktywnie godzin zdecydowałem się poszperać w sieci, żeby szybko odzyskać, a w zasadzie zmienić hasła.

Po lekturze kliku artykułów w sieci, ze zdziwieniniem odkryłem, że nie będę nawet musiał uruchamiać systemów z płyty instalacyjnej, ale po kolei.

Po pierwsze powinniśmy uruchomić ponownie system i w chwili pojawnienia się menu startowego z wyborem opcji uruchomieniowych zatrzymać rozruch dowolnym klawiszem (nie może to być Enter 🙂 ). Wybierając pierwszą opcje startową należy wcisnąć e aby przejść do edycji linii wywołania jądra systemowego z opcjami.

Po drugie przechodzimy do linii zaczynającej się od słowa linux, pracowicie przesuwamy się na jej koniec i dopisujemy frazę

init=/bin/bash

Po trzecie wciskamy ctrl+x lub F10 aby uruchomić system. W ten sposób wystartujemy w trybie pojedynczego użytkownika z systemem plików zamontowanym w trybie tylko-do-odczytu. Ponieważ chcemy zmienić hasło root zdecydowanie trzeba to zmienić. Wpisujemy zatem polecenie:

mount -o remount /

Po czwarte używamy dobrze znanej komendy (mam taką nadzieję)

passwd

aby zmienić hasło root. Na koniec uruchamiamy ponownie system, jednak tym razem znamy już hasło.

MG

Tagi: , , ,

AIDE – wykrywanie zmian w systemie plików

31 marca, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
AIDE

Wiele lat temu miałem wątpliwą przyjemność doświadczyć ataku na jeden z serwerów Apache, którymi się opiekowałem. Zmiany, które skutkowały przejęciem serwera i rozsyłaniem za jego pomocą spamu pojawiały się każdego dnia a ja usiłowałem bezskutecznie walczyć z nimi. Wtedy po raz pierwszy pojawiła się myśl, żeby po prostu podejrzeć co atakujący zmienia w systemie plików, tak aby można było rozszyfrować na czym polega sama metoda włamania. Ostatecznie, szczerze mówiąc, zostałem pokonany i wszystko skończyło się instalacją od początku serwisu, ale poznałem narzędzie detekcji włamiań działające na poziomie systemu plików jakim jest AIDEAdvanced Intrusion Detection Environment.

Wiele lat później ta wiedza i to narzędzie bardzo mi pomogły w powstrzymaniu jednego z ataków na inny serwer w celu uruchomienia koparki kryptowalut. Myślę, że warto jest korzystać z AIDE, w szczególności na serwerach wystawionych na publiczny dostęp. Zatem do dzieła!

Zaczynamy od instalacji pakietu AIDE, po uprzednim zaktualizowaniu systemu:

apt-get update -y && apt-get upgrade -y
apt-get install aide

Następnie wykonujemy kopie zapasową pliku konfiguracyjnego AIDE:

cp /etc/aide/aide.conf /ect/aide/aide.oryg;

Teraz możemy przejść do edycji pliku konfiguracyjnego, aby poprawić/dostosować niektóre jego ustawienia. Możemy skorzystać na przykład z edytora nano.

nano /etc/aide.conf 

W plików tym, na początek, zmieniamy absolutne minimum opcji. Z czasem, po zapoznaniu się z pełnymi możliwościami AIDE możemy pobawić się jego ustawieniami. Trzeba jednak pamiętać, że możemy w ten sposób doprowadzić do przeciążania zasobów serwera ze względu na np. długotrwałą i zbyt szczegółową analizę. Dlatego zaczynamy od absolutnego minimum dla obliczenia sumy kontrolnej:

Checksums = sha512+tiger

I tyle na pierwszy raz wystarczy 🙂 .

Po zapisaniu ustawień możemy zaincjalizować AIDE, co może trochę potrwać w zależności od mocy serwera:

aideinit

Następnie wykonujemy małą sztuczkę upewniając się, że AIDE zadziała z poziomy crona systemowego, czyli:

mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
/etc/cron.daily/aide
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

I to wszystko. Teraz przy odrobinie szczęścia, tzn. jeżeli wszystko poszło zgodnie z oczekiwaniami, będziemy codziennie otrzymywać raport na skrzynkę root z listą zmian w systemie plików w ciągu ostatnich 24 godzin.

MG

Tagi: , , ,

Dell R210 – instalacja sterownika sieciowego a Debian 9.6

15 grudnia, 2018 | Brak Komentarzy | Kategoria: Linux, Porady

Rackowe serwery firmy Dell, nawet te z najniższej serii jak Dell PowerEdge R210 II, wyśmienicie nadają się do tworzenia serwisów internetowych. Mam na myśli usługi takie jak WWW czy FTP. Nie są to super wydajne maszyny do obsługi milionów zgłoszeń w ciągu godziny, ale jako hosty dla małych i średnich przedsiębiorstw jak najbardziej znajdą zastosowanie.

Dell R210 instalacja Debiana

Niedawno miałem okazję przygotowywać taki komputer instalując ostatnią wersję Linuxa – Debian Stretch w wersji 9.6. Ponieważ bardzo lubię prostotę i minimalizm dlatego korzystam zazwyczaj z instalacji w wersji sieciowej, tak aby nie zaśmiecać systemu operacyjnego zbędnymi pakietami. Jak nazwa wskazuje aby wszystko udało się bez problemu potrzebna jest sieć, a w zasadzie działająca karta sieciowa, czyli prawidłowo zainstalowany sterownik. Pomimo iż Dell w serwerach R210 raczej na pewno korzysta ze standardowych rozwiązań – czytaj popularnych kart sieciowych (zbudowanych w oparciu o rozpowszechnione chipsety), to jak się okazuje społeczność Debiana tak bardzo dba o używanie otwartych sterowników, że nie zawsze wychodzi to użytkownikom na dobre.

W opisywanym przypadku serwer wyposażony jest w kartę Broadcom NetXtremeII z dwoma interfejsami sieciowymi. Instalacja pozornie przebiega bez problemów. Karty sieciowe są wykrywane poprawnie. Debian korzysta z wbudowanego sterownika (w poprzednich wersjach trzeba było dodawać zenętrzny zamknięty pakiet oprogramowania). Instalator przechodzi do automatycznej konfiguracji przez DHCP i… naszym oczom ukazuje się komunikat o błędzie. Wygląda to tak jakby winne było wszystko, włącznie z serwerem DHCP, tylko nie instalator Debiana. A prawda jest zupełnie inna.

Okazuje się, że kod sterownika dołączonego standardowo do instalatora zawiera błędy. Karta sieciowa działa, ale nie do końca. W tej sytuacji trzeba wspomóc się kilkoma sztuczkami i dodać ręcznie właściwy sterownik.

  • Po pierwsze pobieramy właściwy (zamknięty) pakiet ze strony https://packages.debian.org/stretch/firmware-bnx2.
  • Następnie za pomocą pendrive’a USB przenosimy go na przygotowywany serwer:
    • uruchamiamy instalator Debiana w wersji tekstowej
    • przechodzimy przez pierwsze kroki instalacji pamiętając, że zanim instalator zacznie wykrywać sprzęt musimy wgrać zamknięty sterownik z USB
    • gdy instalator zatrzyma się na jednym z pytań konfiguracyjnych wciskamy ALT+F2 przechodząc do konsoli tekstowej
    • tworzymy tymczasowy punkt montowania i montujemy pendrive
~$ mkdir /tmp/driver
~$ mount /dev/sda1 /tmp/driver
  • Kolejnym krokiem będzie instalacja właściwego sterownika
~$ apt-get install /tmp/driver/firmware-bnx2_xxx-x_all.deb
  • Ostatnią czynnością jest wciśnięcie kombinacji ALT+F1 co pozwoli wrócic do okienkowej wersji instalatora
  • Tym razem podczas wykrywania sprzętu zostanie zainstalowany odpowiednie oprogramowanie

Dalej wykonujemy standardowe czynności, zgodnie z typową instalacją, ciesząc się działającym połączeniem sieciowym.

MG

Tagi: , , , ,

PHP w dwóch wersjach jednocześnie a serwer Apache

18 listopada, 2018 | Możliwość komentowania PHP w dwóch wersjach jednocześnie a serwer Apache została wyłączona | Kategoria: Linux, Porady

PHP

Dla każdego administratora, który przygotowywał serwis www pojęcie LAMP nie jest obce. W skrócie oznacza, że udało nam się zainstalować trzy podstawowe serwisy tj. Apache, PHP oraz silnik bazy danych np. MySQL. Dzisiaj chciałem skupić się na obsłudze języka PHP. Obecnie ostatnią dostępną wersją jest 7.2. Domyślnie taką właśnie powinniśmy instalować. Jednak jak wiadomo rzeczywistość jest nieco bardziej skomplikowana i na pewno spotkamy się z użytkownikami, którzy z różnych względów bedą chcieli używać starszych wersji jak np. 5.6. Osobiście zalecam jak najszybsze przechodzenie do wersji najnowszych, głównie ze względu na bezpieczeństwo, trzeba jednak pamiętać o różnicach w implemetacji pomiędzy wspomnianymi wersjami, co z kolei przekłada się np. na brak niektórych funkcji, czyli na brak tak zwanej kompatybilności wstecznej. Jest to istotne przy instalacji oprogramowania webowego, które opierając się o starsze wersje PHP może nie funkcjonować w nowszym środowisku. Zatem scenariusz naszej instalacji powinien wyglądać tak, że domyślnie włączony jest PHP7 ale zawsze mamy możliwość cofnięcia wersji dla wybranych serwisów. I o tym właśnie jest dzisiejszy wpis.

Na początek załóżmy, że tradycyjnie używamy Debian Linux w wersji 9.5 Stretch. Ponieważ nie skupiamy się w tym artykule na instalacji samego Apache oraz MySQL (co z resztą jest szeroko opisywane w sieci) przejdźmy od razu do instalacji PHP. Zaczynamy od następujących poleceń:

$ apt-get install ca-certificates apt-transport-https 
$ wget -q https://packages.sury.org/php/apt.gpg -O- →
| sudo apt-key add -
$ echo "deb https://packages.sury.org/php/ stretch main" →
| sudo tee /etc/apt/sources.list.d/php.list

Aby wykorzystywać różne wersje PHP jednocześnie będziemy potrzebowali dwóch interfejsów – PHP FPM oraz FastCGI:

$ apt-get update
$ apt-get install php5.6 php5.6-fpm
$ apt-get install php7.2 php7.2-fpm

I w ten sposób zainstalujemy jednocześnie wersje 5.6 i 7.2. Oczywiście możemy tak zrobić z różnymi wydaniami, to tylko przykład.

Przechodzimy do konfiguracji samego Apache. Przede wszystkim dodajemy wspomniany interfejs:

$ apt-get install libapache2-mod-fcgid

Nastepnie włączamy następujące moduły:

$ a2enmod actions cgid alias proxy_fcgi

I to już już wszystko. Naprawdę możemy korzystać z dwóch bibliotek 🙂 . Niemniej chciałbym zasugerować włączenie domyślnie tej nanowszej. Czyli w konfiguracji głównej hosta wirtualnego (chodzi o plik 000-default.conf) dodanie następujących linijek:

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php7.2-fpm.sock|fcgi://localhost/"
</FilesMatch>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Tym razem, po ponownym uruchomieniu Apache możmy być pewni, że domyślnie używamy najnowszej zainstalowanej wersji:

$ systemctl restart apache2

Jeśli jednak któryś z użytkowników serwera będzie chciał cofnąć się z różnych względów do wersji starszej to wystarczy, że w katalogu głównym swojego serwisu utworzy tekstowy plik .htaccess i doda do niego poniższą zawartość:

<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php5.6-fpm.sock|fcgi://localhost/"
</FilesMatch>

To naprawdę działa.

MG

Tagi: , , , ,

IPv6 w służbie udziałom sieciowym

21 października, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

IPv6Życie lubi często płatać figle. Nierzadko stawia administratorów przed bardzo dziwnymi zadaniami, uwzględniającymi bardzo wydumane ezoteryczne scenariusze działania. Gdybym sam się z tym nie stykał na co dzień, to muszę przyznać, że byłoby mi ciężko uwierzyć. A jednak shit happens jak mawiają.

Dzisiejszy wpis dotyczy sytuacji, w której ktoś postanowił wymienić sprzęt sieciowy, w tym serwery plików NAS (tj. QNAP, Synology) i zastąpić je po prostu udziałami na serwerze plików Windows. Ponieważ nowa polityka bezpiczeństwa nie zakładała wykorzystywania rozwiązań innych niż z systemem Windows, nagle wspomniane wcześniej urządzenia zostały wyłączone. Można powiedzieć – cóż… koszty wdrożenia… ale w ten sposób pozbyto się niemałej przestrzeni dyskowej (chodziło to o kilka, kilkanaście TB), która może być zawsze wykorzystana np. do kopii zapasowych. Nietrudno się domyśleć, że powstał problem jak podłączyć z powrotem urządzenia tak aby nie naruszały zasad bezpieczeństwa. Najlepiej oczywiście lokalnie np. przez port USB, ale po pierwsze nie każde ma taką możliwość, po drugie tracimy w ten sposób masę funkcji, które są wbudowane w gotowce typu NAS. Czyli pozostaje przełożyć dyski do serwerów Windows… otóż nie do końca.

Pierwszą myślą było utworzenie osobnej podsieci lokalnej dla naszego NASa i przygotowanie na wybranym komputerze sieciowego interfejsu wirtualnego tak aby stacja mogła korzystać równocześnie z głównej podsieci i w połączeniu punkt-punkt z dysków NAS (dzięki udziałom SMB). Łatwo powiedzieć i łatwo zrobić jeśli ktoś nie rzuca kłód pod nogi. A tym razem kolejną przeszkodą był fakt, że główny interfejs sieciowy został skonfigurowany do pobierania parametrów IP przez DHCP. Niestety ani Windows 7 ani Windows 10 nie umożliwiają skonfigurowania wirtualnej karty sieciowej jeśli podstawowa korzysta z DHCP. Oczywiście w sieci można znaleźć trochę propozycji rozwiązań, jednak nie działają one wogóle, albo wymagają instalowania dodatkowego oprogramowania. Dodatkowo często po restarcie komputera cała misternie przygotowana konfiguracja idzie w cyfrową niepamięć. I właśnie w tym przypadku przydaje się IPv6.

Wystarczy otworzyć okno właściwości karty sieciowej, żeby zauważyć, że przecież oporócz IPv4 możemy skonfigurować IPv6. Na razie mało kto z tego korzysta, a bywa, że ze względów bezpieczeństwa IPv6 jest wyłączane. Tym razem możemy skonfigurować lokalną sieć IPv6 do połączenia naszego komputera z NASem. Zatem po kolei. Na komputerze Windows dodajemy IPv6 z adresem lokalnym:

fe80::208:9bff:fef9:44f

Lokalny adres IPv6 wygenerujemy przy pomocy strony https://www.ultratools.com/tools/rangeGenerator. Pamiętajmy jednak aby wybrać adres z prefiksem 64. Jest to dosyć często spotykana opcja w gotowcach typu NAS.

Na naszym urządzeniu NAS konfigurujemy IPv6 z tej samej podsieci ale np. z numerem o 1 większym. Czyli uruchamiamy kalkulator z możliwością obliczeń w zapisie szesnastkowym i do wartości 44f dodajemy 1. Powiniśmy otrzymać adres postaci:

fe80::208:9bff:fef9:450

Po restarcie obu urządzeń mamy gotową podsieć lokalną składającą się z komputera Windows i serwera NAS. Musimy tylko wiedzieć jak dostać się do dysków np. z poziomu Eksploratora Plików Windows. Otwieramy zatem eksplorator i w polu adresu wpisujemy:

\\fe80--208-9bff-fef9-450.ipv6-literal.net

Wpisywanie każdorazowo powyższego adresu jest kłopotliwe, można zatem przygotować skrót na Pulpicie albo (jeszcze lepiej) zamontować nasz udział jako lokalny katalog (C:\NAS):

mklink /D C:\NAS \\fe80--208-9bff-fef9-450.ipv6-literal.net\

Pamiętajmy jednak, że montować możemy udział sieciowy (np. \\fe80–208-9bff-fef9-450.ipv6-literal.net\kopie), więc podany przeze mnie przykład nie zadziała 😉 .

MG

 

Tagi: , , , ,

Docker, Portainer i kłopoty z OpenProject

15 września, 2018 | Brak Komentarzy | Kategoria: Felieton, Linux, Porady

Docker

Techniki wirtualizacji są obecnie bardzo popularne. Począwszy od tych dostępnych na wyciągnięcie ręki dla każdego użytkownika, mam na myśli VirtualBox, a skończywszy na bardziej rozbudowanych typu VMware ESXi, czy QEMU. Te ostatnie wymagają już środowiska w pełni serwerowego i trochę zaawansowanej technicznie wiedzy (ale bez przesady). Z drugiej strony prężnie rozwija się technologia kontenerów wirtualizacyjnych typu Docker. Stają się one popularne głównie w środowisku programistów (koderów i developerów) bo pozwalają w łatwy sposób instalować całe środowiska z przygotowanych obrazów. Skraca to bardzo czas rozwoju oprogramowania, bo daje do ręki skonfigurowany gotowiec jak np. LAMP czyli Linux, Apache, MySQL, PHP/Python/Perl.

W tym wpisie chciałem się właśnie skupić się na apliakcji Docker. Wynika to głównie stąd, że jakiś czas temu realizowałem projekt polegający na zainstalowaniu całego środowiska developerskiego. Składały się na nie serwer z Debianem oraz 3 kontenery: GitLab, Nextcloud i OpenProject. Można powiedzieć solidne środowisko do pracy dla programistów. Całość została uruchomiona w sieci lokalnej, a każdy z wymienionych kontenerów był dostępny pod swoim własnym adresem IP oraz wewnętrzną nazwą domenową. Przy tej okazji chciałem podzielić się dwoma spostrzeżeniami, dotyczącymi problemów, których zrozumienie i dla których przygotowanie rozwiązania bardzo ułatwiło mi opracowanie rozwiązań. Jeden będzie dosyć ogólny, drugi zaś to przykład debugowania rozwiązania i zaaplikowania specyficznej łaty. Ale po kolei.

Środowiskiem kontenerów Dockera można zarządzać oczywiście za pomocą linii komend. Jednak jako alternatywe polecam gorąco projekt o nazwie Portainer. Instalowany jako jeden z pierwszych kontenerów naszego Dockera pozwoli w dosyć prosty i elegancki sposób zarządzać całością. Zwolenników aplikacji webowych ucieszy na pewno fakt, że jest to po prostu serwer, który udostępnia interfejs przeglądarkowy. Możemy zarządzać praktycznie wszystkimi potrzebnymi modułami w tym: kontenerami, obrazami, wolumenami i sieciami. Możliwości jest dużo więcej i najlepiej jest zainstalować to oprogramowanie samemu, żeby o tym się przekonać. Tym bardziej, że jest to łatwe jak instalacja każdego kontenera w Dockerze 🙂

Drugim problemem, bardziej złożonym, okazała się isntalacja OpenProject. Chciałbym o tym wspomnieć ponieważ jest to bardzo dobry przykład na to, z jakimi problememi można się spotkać używając Dockera. Sama instalacja z oficjalnego, przygotowanego przez autorów obrazu nie nastręcza większych żadnych trudności. Zaraz po uruchomieniu wszysko działa dobrze. Jednak z czasem, gdy będziemy musieli zrestartować cały serwer, a co za tym idzie swoje kontenery również, może się okazać, że OpenProject odmawia posłuszeństwa. Zamiast głównej strony serwisu natkniemy się na informacje o niedostępności. Po przeprowadzeniu wspomnianego na początku debugowania oraz sprawdzeniu stanu samego kontenera (który zachowuje się jak najbardziej poprawnie, czyli uruchamia się i nie zgłasza żadnych błędów) okazało się, że przyczyną jest zatrzymanie się serwera Apache. Niestety ręczne uruchamianie daemona również nie pomaga. Problem jest nieco głębszy i polega na tym, że w trakcie restartu kontenera zdarza się, że nie jest usuwany plik apache2.pid, co z punktu widzenia systemu oznacza, że Apache jak najbardziej działa cały czas (co nie jest prawdą). Rozwiązanie jest dosyć proste. Plik ten należy usunąć ręcznie, czyli:

  • z poziomu Portainera (omówionego akapit wcześniej) połączyć się z konsolą,
  • usunąć ręcznie plik PID: rm -f /var/run/apache2/apache2.pid,
  • uruchomić Apache: /etc/init.d/apache2 start.

Powyższa sztuczka pokazuje, że pomimo iż oficjalne kontenery Dockera zazwyczaj działają bez zarzutu to czasami wymagana jest głębsza wiedza i grzebanie w czeluściach obrazu.

MG

 

Tagi: , , , , ,

Aktualizacja hosta ESXi

18 sierpnia, 2018 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

VMware ESXiWirtualizacja jest obecnie praktycznie standardem. Jest powszechnie dostępna i łatwo można samemu przygotować własny host maszyn wirtualnych. Od jakiegoś czasu testuje aktualnie kilka instalacji VMware ESXi i muszę przyznać, że jestem zaskoczony wygodą obsługi oraz jak dotąd (odpukać) bezawaryjną pracą. Instalacja jest dosyć łatwa pod warunkiem, że przygotujemy się pod kątem sprzętu. Nie każdy zostanie wykryty przez instalator, ale metodą prób i błedów a także przy wsparciu forów technicznych można rozwiązać większość problemów. Potem jest już z górki. Do czasu. Jak zwykle po jakimś czasie powinniśmy pomyśleć o kwestiach bezpieczeństwa, a co się z tym wiąże aktualizacji naszego hosta.

Jeżeli podobnie jak ja używasz wersji ewaluacyjnej ESXi to znaczy, że najprawdopodobniej korzystasz z trybu standalone server, czyli posiadasz tylko jeden host maszyn wirtulanych. Instalacja tego typu wyróżnia się brakiem wygodnej czytaj graficznej obsługi aktualizacji. Pełna instalacja zarezerwowana jest dla dużych farm hostów, a tak naprawdę trzeba zapłacić za oprogramowanie zarządzające hostami, co na jedno wychodzi. W tym przypadku trzeba sobie radzić za pomocą konsoli tekstowej.  Ale po kolei…

Najpierw należy zalogować się na nasz host używając po prostu przeglądarki internetowej. Z poziomu graficznej konsoli zarządzania trzeba uruchomić usługę SSH. Nie jest ona domyślnie włączona – dla bezpieczeństwa. Wybieramy zatem opcję Manage z okienka Navigator po lewej stronie i w okienku po prawej stronie przechodzimy do zakładki Services. Uruchamiamy usługę TSM-SSH (po zakończeniu aktualizacji warto ją wyłączyć ponownie). Od tej pory możemy połączyć się za pomocą SSH do naszego hosta.

Zaczynamy od sprawdzenia wersji poleceniem:

~ # esxcli system version get
Product: VMware ESXi
Version: 6.7.0
Build: Releasebuild-469512
Update: 0
Patch: 0

Następnie udajemy się na stronę z aktualizacjami dla VMware ESXi i pobieramy właściwą dla naszego systemu. Warto zauważyć, że aktualizacje kumulują się, więc nie ma potrzeby wgrywania wszystkich – wystarczy ostatnia. Dodam, że na pewno trzeba wgrać oznaczone etykietką Critical, reszta według uznania.

Przełączamy host ESXi w tryb Maintenance (za pomocą przeglądarki i strony zarządzającej) i możemy przystąpić do działania. Rozpoczynamy od wyświetlenia listy profili dostępnych w naszym patchu:

~ # esxcli software sources profile list --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip
Name Vendor Acceptance Level
-------------------------------- ------------ ----------------
ESXi-6.7.0-20171002001-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-no-tools VMware, Inc. PartnerSupported
ESXi-6.7.0-20171002001-no-tools VMware, Inc. PartnerSupported

Najbezpieczniej jest skorzystać z profilu standardowego, a więc ESXi-6.7.0-20171002001-standard. Jest to zazwyczaj pierwszy dostępny profil z listy. Nim w następnym kroku przystąpimy do aktualizacji serwera, powinniśmy najpierw sprawdzić jaki będzie wynik tej operacji. Z pomocą przychodzi opcja –dry-run. Wpisujemy plecenie:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--dry-run --profile=ESXi-6.7.0-20131002001-standard
Update Result
Message: Dryrun only, host not changed. The following \
installers will be applied: [BootBankInstaller]
Reboot Required: true
VIBs Installed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.1.11.623860, \
VMware_bootbank_esx-base_5.0.0-3.41.1311175, \
VMware_bootbank_esx-tboot_5.0.0-2.26.914586, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.2.26.914586, \
VMware_bootbank_misc-drivers_5.0.0-3.41.1311175, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.7.515841, \ 
VIBs Removed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.0.0.469512, \ 
VMware_bootbank_esx-base_5.0.0-0.0.469512, \
VMware_bootbank_esx-tboot_5.0.0-0.0.469512, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.0.0.469512, \
VMware_bootbank_misc-drivers_5.0.0-0.0.469512, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.0.469512,

Jeśli nie otrzymaliśmy żadnych komunikatów o błedach możemy śmiało przystąpić do właściwej aktualizacji. Tym razem korzystamy z komendy:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--profile=ESXi-6.7.0-20131002001-standard 
Update Result
Message: The update completed successfully, but the 
system needs to be rebooted for the changes to be effective. \
Reboot Required: true

Na sam koniec nie pozostaje nic innego jak uruchomić ponownie serwer VMware ESXi (skoro sam tego zażądał):

~ # reboot

Po starcie systemu wyłączamy tryb Maintenance i voilá! Prawda, że proste 😉

MG

Tagi: , , , , ,