K-NET s.c.

Zewnętrzny numer IP?

Numer IP – bardzo często bywa tak, że z jakichś powodów chcielibyśmy uzyskać informację na ten temat (zwłaszcza jeśli chodzi o zewnętrzny numer IP). Jak zauważyłem problem ten dotyczy nie tylko sytuacji, w której po prostu sprawdzamy czy operator przydzielił nam właściwy adres IP, ale również coraz częściej jeśli chcemy np. sprawdzić czy zadziałało połączenie prywatne VPN. Zauważyłem, że powoli stają się one standardem (i bardzo dobrze), warto zatem czasami upewnić się, że nasz ruch przechodzi przez odpowiedni router.

Do tej pory można to było zrobić na kilka, mniej lub bardziej eleganckich sposobów. Dla mniej wprawnych zawsze pozostaje np. serwis https://www.whatismyip.com. Ta metoda wymaga jednak posiadania interfejsu graficznego czyli GUI. A jak zrobić to samo na serwerze, który posiada tylko czystą konsolę tekstową?

Tutaj również mamy do dyspozycji wiele metod. Szczególnie jeżeli używamy mojego ulubionego rozwiązania czyli Linuxa. Od lat korzystałem w tym celu z dobrze znanego polecenia wget, które pozwala na sparsowanie wyjścia i tą nieco pokrętną metodą uzyskanie odpowiedzi na pytanie postawione w tytule artykułu:

/usr/local/bin/wget -qO - http://ipinfo.io/ip

Świat idzie jednak do przodu (i bardzo dobrze). wget powoli jest zastępowany przez nowe polecenie (a w zasadzie rozbudowane narzędzie) czyli curl. W takim wydaniu uzyskanie informacji jaki jest zewnętrzny numer IP jest jeszcze prostsze:

curl http://icanhazip.com

I o to przecież wszystkim chodzi 🙂

MG

Tagi: komendy, konfiguracja, linia poleceń, Linux

Eksport i import LDAP

Przez ostanich parę lat serwery poczty e-mail przeszły niemałą rewolucję. Jak dobrze pamiętam, kiedyś postawienie własnego MXa wiązało się z konkretną pracą. Mówiąc precyzyjniej zabezpieczeniem takiego serwera tak, aby nie był open-relayem, włączeniem wszystkich autoryzacji i np. przygotowaniem skrzynek z obsługą IMAP, LDAP itp. Obecnie można w miarę łatwo osiągnąć ten cel stosując dopracowane i wygodne w użyciu platformy, jak chociażby iRedMail. Jest to prawdą w odniesieniu do standardowych konfiguracji. Nie po to jednak mamy Linuxa aby zostawić rzeczy samym sobie i nie próbować zmieniać czy poprawiać konfiguracji, czytaj – dostosowywać do swoich potrzeb.

Przy rozbudowanych systemach, z obsługą dużej liczby skrzynek pocztowych, wygodną metodą jest przechowywanie konfiguracji w bazie danych. Osobiście preferuję w tym celu usługi katalogowe LDAP. Moim zdaniem są szybkie i niezawodne, a odpowiednio skonfigurowane bezpieczne. Wspomniany iRedMail pozwala na organizowanie warstwy logiki serwera pocztowego za pomocą LDAPa.

Świat nie stoi w miejscu i nawet jeżeli jako administratorzy mamy względny spokój, bo nikt od nas nie wymaga przenoszenia usługi pocztowej do nowego dostawcy lub na nowe serwery, to zawsze może się zdarzyć, że sami zostaniemy do tego zmuszeni, bo np. chcemy wymienić sprzęt (lub fizycznie nawet cały serwer). Oczywiście w najprostszym scenariuszu będzie się to wiązało z wykonaniem kopii zapasowej bazy LDAP a potem odtworzeniem jej na nowym węźle. No właśnie – w najprostszym, co się jednak stanie jeżeli musimy zmienić co nieco w naszej usłudze katalogowej.

Przykładem takiej ingerencji może być wymuszenie zmiany atrybutu Distinguished Name – DN. Dzieje się tak, gdy przenosimy jedną z obsługiwanych domen emailowych do całkowicie nowej struktury LDAP. W tym miejscu okazuje się jak wygodny i zarazem niewygodny potrafi być LDAP. Otóż dla jego doświadczonego użytkownika sprawa jest prosta i realizowana w 3 krokach:

• wyeksportuj starą bazę LDAP do pliku LDIF (format tekstowy, bez kompresji)
• wyedytuj dowolnym edytorem plik LDIF i wprowadź potrzebne zmiany
• zaimportuj plik LDIF do nowej bazy LDAP

I wszystko byłoby dobrze gdyby nie fakt, że w trakcie eksportu każdy wiersz pliku LDIF jest obcinany do 76 znaków a część nadmiarowa przenoszona ze spacją do nowej linii. Bardzo to utrudnia zastosowanie popularnej metody edycji Search and Replace, ponieważ wzorzec wyszukiwania nie jest jednoznaczny. Należy po prostu inteligentnie usunąć wszystkie miejsca łamiania wiersza.

Jeżeli dysponujemy Linuxem z jego wszelkiemi udogodnieniami i narzędziami to przepis jak to zrobić będzie prosty:

awk 'NR>1 && !sub(/^ /,""){print s; s=""} \ 
{s = s $0} END{print s}' stary.ldif > nowy.ldif

Potem pozostaje już tylko import atrybutów z wartościami do nowej bazy LDAP.

MG

Tagi: konfiguracja, ldap, Linux, poczta elektroniczna

DNSBL i Postfix

RBL, DNSBL o co w tym chodzi? Chociaż czasami poczta elektroniczna nie jest łatwa w konfiguracji to do tej pory, przynajmniej moim zdaniem, nie wymyślono lepszego zamiennika. Szczególnie jeśli mowa np. o korespondencji firmowej, oficjalnej itp. Będąc administratorem firmowego serwera pocztowego na pewno nie unikniemy walki ze spamem i temu chciałbym poświęcić ten wpis.

Wydawać by się mogło, że temat jest ponad miarę wyeksploatowany i w zasadzie nie ma nad czym się rozwodzić. Dlatego nie chcę się skupiać na instalacji i zabezpieczeniu serwera w całości. W końcu można do tego użyć chociażby pakietu iRedMail, który naprawdę polecam. Tym razem chcę pokazać jak ubić spam na wejściu, czyli na poziomie Postfixa, a jeszcze precyzyjniej na poziomie demona systemowego nierozerwalnie z nim związanego – mowa o Postscreen. Zwróćmy od razu uwagę, że taka konfiguracja nie wymaga instalacji np. Amavis i Spamassasin, co bywa pewnym wyzwaniem, zwłaszcza dla początkujących użtkowników.

Podstawą dla przytaczanego tutaj rozwiązania jest DNSBL, czyli czarna lista tworzona z pomocą DNS. Nie musimy tworzyć jej sami, możemy wykorzystać ogólnodostępne serwisy, które robią to dla nas. Z Postfixem bardzo dobrze komponują się dwa z nich – Spamhaus oraz BarracudaCentral. W tym miejscu należy wspomnieć, że Spamhaus ma ograniczenie do 100.000 połączeń na dzień. Zakładam jednak, że mówimy o normalnym serwerze pocztowym dla średniej firmy, więc raczej nie powinniśmy przekroczyć 100.000 maili przychodzących z zewnątrz dziennie.

Ostatecznie uzbrojenie w powyższą wiedzę możemy przystąpić do konfiguracji Postfixa, która jak zwykla jest dosyć prosta. 🙂

Skonfigurowanie obsługi DNSBL wymaga wyedytowania pliku /etc/postfix/main.cf i dodaniu parametrów do opcji postscreen_dnsbl_sites:

postscreen_dnsbl_sites =
  zen.spamhaus.org*2
  b.barracudacentral.org*2

Liczba na końcu parametru jest wagą, która powoduje podbicie punktacji.

Sugerowaną konfiguracją jest również korzystanie z lokalnego serwera cache DNS. Może to być dowolny pakiet. Przy dużym natężeniu ruchu przychodzącego zdecydowanie przyspiesza działanie usługi pocztowej:

postscreen_dnsbl_sites =
  zen.spamhaus.org=127.0.0.[2..11]*2
  b.barracudacentral.org=127.0.0.2*2

Ostanim parametrem, którego wartość warto rozważyć jest postscreen_dnsbl_action. Zazwyczaj jest ona ustawiona na enforce, co oznacza przekazanie do dalszego przetwarzania. Czasami jednak warto jest ubić wszystkie niechciane połączenia:

postscreen_dnsbl_action = drop

Po zapisaniu nowej konfiguracji Postfixa, musimy ponwnie uruchomić serwis.

MG

Tagi: konfiguracja, Linux, poczta elektroniczna, Postfix

OpenVAS – testy penetracyjne

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: Debian, konfiguracja, linia poleceń, Linux, serwer

Hasło root – jak je odzyskać?

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: Debian, konfiguracja, Linux, polecenia

AIDE – wykrywanie zmian w systemie plików

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 AIDE – Advanced 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: Debian, konfiguracja, Linux, serwer

xsibackup – ręczne kopie zapasowe VMware ESXi

Wirtualizacja jest obecnie bardzo modnym i nośnym tematem. Oferta dotycząca rozmaitych wersji maszyn wirtualnych oferowanych w ramach usług dostępnych u dostawców jest olbrzymia. Oprócz możliwości wykupienia takiej usługi – z czego przyznam sam korzystam i mogę polecić np. DigitalOcean – istnieje wiele rozwiązań dla użytkowników końcowych, którzy sami chcą się pobawić w administrowanie. W końcu będzie to zawsze jeszcze jedna ciekawa umiejętność, a jak za chwilę postaram się wyjasnić może przydać się w różnych scenariuszach użycia. Rozwiązania pokroju Oracle Virtualbox, chyba najbardziej popularne i łatwe w utrzymaniu, wprowadzają łagodnie w świat wirtualizacji. Potem z reguły przychodzi kolej na rozwiązania niższego poziomu jak VMware ESXi czy KVM. Mowa tu o korzystaniu z własnych hostów maszyn wirtualnych. Wbrew pozorom nie jest to specjalnie trudne i jeżeli tylko korzystamy ze standardowego sprzętu serwerowego to instalacja np. VMware ESXi jest praktycznie bezbolesna.

W momencie gdy jesteśmy już dumnymi właścicielami małej wirtualnej infrastruktury, nawet jeżeli jest to tylko jeden serwer, możemy rozpocząć budowanie własnej sieci serwerów wirtualnych. Zazwyczaj zaczyna się od jednej jednostki ale apetyt bardzo szybko rośnie w miarę jedzenia i z czasem przybywa nam umiętności, pewności siebie oraz oczywiście nowych węzłów sieciowych. Przenoszenie na platformę wirtualizacyjną serwerów Windows czy Linux jest bardzo łatwe. Naprawdę warto zastanowić się nad tego typu wdrożeniami bo można szybko przekonać się o zaletach rozwiązania. Jednak jak zwykle wraz ze wzrostem apetytu zaczynamy również odkrywać powoli minusy. W moim przypadku był to brak pewnych narzędzi administracyjnych wynikający głównie z korzystania z wersji niekomercyjnej VMware ESXi. Mowa tu o automatycznych kopiach zapasowych maszyn wirtualnych, które byłyby wykonywane w locie, czyli bez zatrzymywania usług.

Krótkie badanie rynku komercyjnych aplikacji do wykonywania kopii zapasowych VMware pokazało, że rozwiązań jest bardzo dużo. Niestety większość ma istotne ograniczenia w wersjach demonstracyjnych. Inne z kolei nie integrują się bezpośrednio z hostem maszyn wirtulanych i wymagają stosowania zewnętrznego komputera z aplikacją. Po jakimś czasie trafiłem w końcu na stronę 33hops.com, gdzie znalazłem ciekawe narzędzie o nazwie xsibackup. Był to strzał w dziesiątke, okazało się bowiem, że istnieje nieodpłatne narzędzie linii poleceń, które pzowala wykonać ręcznie i automatycznie kopie zapasowe.

Na wspomnianej stronie, po podaniu adresu email, możemy pobrać oprogramowanie do instalacji. W wiadomości od producenta otrzymamy również bardzo precyzyjną i szczegółową instrukcję instalacji. Koniec końców cały proces sprowadza się do przygotowania komendy (narzędzia), która pozwoli na zrzucenie ad-hoc kopii maszyn wirtulanych. Ogólnie mówiąc, po zalogowaniu się na konsolę naszego hosta możemy rozpocząć całą zabawę. Poniżej zamieściłem dwa przykłady użycia bazując na własnych doświadczeniach.

Aby sprawdzić poprawność instalacji i wykonać test kopiowania maszyn wirtualnych użyjemy polecenia:

./xsibackup --backup-point=/vmfs/volumes/backup /
--backup-type=running --test-mode=true

Opcja test-mode=true spowoduje, że żadne kopie nie zostaną uruchomione, ale będziemy mogli przetestować poprawność polecenia. Z kolei backup-type=running mówi, że skopiowane mają zostać wszystkie uruchomione maszyny wirtualne – bez ich zatrzymywania (sic!).

Drugim poleceniem jest już komenda służąca wykonania kopii wybranej maszyny:

./xsibackup --backup-point=/vmfs/volumes/backup /
--backup-vms="Nazwa maszyny wirtualnej" /
--backup-type=custom

W tym przypadku warto zwrócić uwagę, że ponieważ wskazujemy, którą maszynę wirtualną chcemy skopiować to należy użyć opcji backup-type=custom.

Mam nadzieję, że te dwa przykładowe polecenia zachęcą zainteresowanych do korzystania i używania kopii zapasowych za pomocą xsibackup. W końcu kopie zapasowe to podstawa i nie trzeba chyba tego nikomu powtarzać 😉 .

MG

Tagi: komendy, kopie zapasowe, Linux, serwer, Windows

Dell R210 – instalacja sterownika sieciowego a Debian 9.6

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.

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: Debian, instalacja, komendy, konfiguracja, Linux

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

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: Debian, komendy, konfiguracja, Linux, polecenia

Aktualizacja hosta ESXi

Wirtualizacja 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: aktualizacja, konfiguracja, Linux, serwer, VMWare, Windows