Bądź na bieżąco - RSS

Zewnętrzny numer IP?

31 maja, 2020 | Możliwość komentowania Zewnętrzny numer IP? została wyłączona | Kategoria: Linux, Porady, Windows
Numer IP? Jak uzyskać informacje na ten temat?

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: , , ,

ESXi – dostrajamy xsibackup

29 marca, 2020 | Brak Komentarzy | Kategoria: Porady
ESXi - narzędzia

WMware ESXi jest naprawdę bardzo przydatnym rozwiązaniem dla wirtualizacji całych systemów. Ponad rok temu pisałem o narzędziu xsibackup, które w wersji nieodpłatnej pozwala wykonywać kopie zapasowe maszyn wirtualnych. Zrobienie kopii to jedna sprawa, czym innym jest przywrócenie z niej systemu. Oczywiście wersja bezpłatna nie ma takiej opcji. Jak sprawdziłem plik z kopią bardzo dobrze nadaje się do wykorzystania przez inne narzędzie,
VMware vCenter Converter Standalone. W ten sposób można cieszyć się całkiem sprawnym systemem zapisywania i odtwarzania maszyn wirtualnych w przypadku awarii. Nawet totalnej katastrofy. Wielu administratorom zapewnia to spokojny sen.

Skoro już mowa o tym czego brakuje w wolnej wersji xsibackup, to tydzień temu natrafiłem na jeszcze jedno ograniczenie. Przy wykonywaniu kopii zapasowych potrzebne jest miejsce nie tylko na samą kopie ale także na operacje związane z buforowaniem i danymi tymczasowymi tworzonymi podczas całego procesu.

Korzystając z przykładu – kupiłem 2 dyski dodatkowe dyski do serwera, tego samego rozmiaru. Pomijając przyczynę nie mogłem dodać ich do macierzy RAID. Postanowiłem na pierwszym utworzyć maszynę wirtualną a na drugi zrzucać codziennie pełną kopię/duplikat tejże. Oczywiście zostawiłem nieco miejsca na pierwszym dysku. Jak się okazało było go zdecydowanie za mało na drugim (tam gdzie docelowo miała być kopia). Zaraz, zaraz możecie zapytać, coś się tutaj nie zgadza. I rzeczywiście za pierwszym razem xsibackup tworzył pierwszą kopię. Jednak zdecydowanie nie chciał wykonać jej po raz drugi jeżeli w tym miejscu znajdowała się kopia z poprzedniego dnia. Niby sprawa jest prosta bo przecież nasuwa się od razu rozwiązanie. Polega ono na usuwaniu za każdym razem istniejącej kopii przed wykonaniem kolejnej. Przecież każdy program do backupów ma coś takiego. Niestety xsibackup w wersji darmowej nie ma!

W tym momencie rozpoczęła się przygoda z ESXi. Usunięcie danych z katalogu w systemie Linux to nic trudnego:

rm -R /scieka_do_katalogu/*

Ponieważ WMware ESXi to tak naprawdę Linux (no może to nie całkiem prawda), można zatem skorzystać właśnie z tej komendy. Należałoby dopisać ją do crona systemowego, tuż przed wykonywaniem kopii zapasowej xsibackup, która już się tam znajduje. I właśnie dostrajanie po swojemu ESXi na tym poziomie jest delikatnie mówiąc kłopotliwe. Dlatego wpadłem na pomysł, żeby zastosować pewną sztuczkę.

xsibackup ma już gotowy zestaw skryptów pozwalający na dodawanie zadań systemowych wg z góry zdefiniowanego harmonogramu. Zadania są umieszczane w jego katalogu instalacyjnym zgodnie z narzuconą konwencją. Pierwsze zadanie znajduje się w pliku:

../xsibackup/jobs/001

Drugie będzie miało nazwę 002 itd. Dlaczego zatem nie dodać w tym miejscu wspomnianej wcześniej komendy – właśnie jako kolejnego zadania? Czyli zawartość pliku 002 powinna wyglądać jak nasza komenda:

„rm -R /sciezka_do_katalogu/*”

Teraz należ jeszcze pamiętać o dodaniu zadanie do crona. Robimy to tak jak w typowym systemie linuksowym, z tym że tutaj edytujemy plik:

../xsibackup/conf/root-crontab

Aby ostatecznie zatwierdzić wszystkie zmiany wywołujemy polecenie

./xsibackup —update-cron

Jeśli nie zostaliśmy ostrzeżeni komunikatami o błędach to znaczy, że udało się. Teraz wystarczy poczekać dzień, dwa aby przekonać się czy nasz backup zadziała poprawnie.

MG

Tagi: ,

Karta SD – formatowanie w Mac OS

29 grudnia, 2019 | Brak Komentarzy | Kategoria: MacOS, Porady
karta SD

Karta SD i jej formatowanie w Mac OS może być źródłem problemów. Sam kilka razy miałem kłopoty. Oczywiście jeśli stosujemy standardowe rozwiązania i mamy kartę sformatowaną dla systemu MS-DOS (FAT), tudzież dla typowego Mac OS Extended (Journaled) to raczej nie napotkamy na żadne przeszkody. Czasami jednak, zwłaszcza gdy zamierzamy testować np. Raspberry Pi, musimy zmierzyć się z innymi systemami plików. I nie chodzi w tym przypadku o zakładanie i konfigurowanie tychże, ale o przygotowanie karty do pracy, czyli usunięcie w pierwszym kroku wszystkich partycji z dostępnej przestrzeni. Niestety, bez tego często nie jesteśmy w stanie korzystać z SD. Wiem, że brzmi to co najmniej dziwnie, ale sam miałem takie problemy.

Jak sprawdziłem najszybszą niezawodną metodą jest skorzystanie z wbudowanych narzędzi systemowych. A więc czas uruchomić terminal. 😉

Jednym z najbardziej pożytecznych i skutecznych narzędzi jest diskutil. Program ten pozwoli nam na wyświetlenie zawartości karty SD:

$ diskutil list

Otrzymamy nazwy urządzeń (np. disk2 lub disk3) z przypisanymi partycjami. Z wyświetlonych informacji można łatwo wywnioskować, które urządzenie to karta SD. Zakładając, że jest np. disk2, możemy przygotować kartę do pracy z Raspberry Pi:

$ diskutil eraseDisk FAT32 RASPBIAN MBRFormat disk2

Na tym jednak nie koniec. Wracając do głównego wątku, możemy również dosłownie wyzerować kartę SD. W tym celu najpierw powinniśmy odmontować urządzenie:

$ diskutil unmountDisk disk2

A potem usunąć jej zawartość:

$ diskutil zeroDisk disk2

Lub inną metodą:

$ diskutil randomDisk disk2

Warto wspomnieć, że opisana komenda sprawdza się również w przypadku pamięci USB, dysków twardych itd. Trzeba jej jednak używać bardzo ostrożnie, i chyba nie muszę tłumaczyć dlaczego.

To tyle w tym ostatnim tegorocznym wpisie.

MG

Tagi: , ,

Czyszczenie dysków twardych na zdalnym serwerze

24 listopada, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Odkurzacz, czyszczenie

Czasami zdarza się sytuacja, która zmusza nas do zrównania serwera z ziemią – mam na myśli czyszczenie dysków twardych. Powodów może być wiele, np. zwrot do dostawcy wynajmowanego zdalnego serwera fizycznego itp. Tak czy inaczej lepiej nie oddawać swoich danych. O danych innych użytkowników, ze względu na przepisy RODO, mogę nawet nie wspominać.

Jeśli sprzęt stoi pod ręką to zwykle nie problemu – chociażby ze sformatowaniem dysków. Możemy je nawet wyjąć i zabezpieczyć. Co zrobić jednak kiedy nasze zasoby są zainstalowane w centrum danych a jedyną możliwością jest połączenie zdalne. Nie ma nawet dostępu do konsoli. Wiem, że wielu osobom może wydawać się prawie niemożliwe, ale jednak tak bywa. Nawet w dzisiejszych czasach. Uściślając jedyną metodą dostępu pozostaje terminal SSH.

Po zabezpieczeniu/skopiowaniu danych, o czym musimy zawsze pamiętać, możemy przystąpić do dzieła zniszczenia, chodzi o czyszczenie dysku twardego. Na początek warto wspomnieć, że większość systemów linuksowych w lokalizacji:

/dev/shm

udostępnia dysk RAM. Jest to dobre miejsce na skopiowanie narzędzi, do których nie będziemy mieć dostępu po skasowaniu danych np. ls. Następnie powinniśmy zabezpieczyć dostęp do procesów czyli wykonać następujące komendy:

mkdir /dev/shm/proc
mount -t proc proc /dev/shm/proc

Tak przygotowani przystępujemy do ostatniego nieodwracalnego zestawu kroków.

Najpierw odmontowywujemy wszystkie niepotrzebne partycje. Potem, jeżeli używamy macierzy RAID, to powinniśmy odmontować wszystkie dyski poza bieżącym (de facto należy je wyczyścić oddzielnie). Wreszcie zmieniamy katalog na dysk RAM i wpisujemy:

shred -n2 -z -v /dev/sda

W wyniku działania aplikacji shred usuniemy zawartość dysku sda. Komenda zapisuje losowo bity na /dev/sda, w dwóch pełnych przebiegach (-n2), a następnie wykonuje końcowy przebieg zerami, dzięki czemu dysk wygląda na idealnie czysty (-z). Ostatnia opcja (-v) posłuży do zwiększenia poziomu szczegółowości logów wyświetlanych na ekranie podczas wykonywania polecenia.

MG

Tagi: , ,

Telnet w Windows czyli wakacje 2019

25 sierpnia, 2019 | Brak Komentarzy | Kategoria: Porady, Windows
Putty telnet

Po raz pierwszy od 3 miesięcy postanowiłem napisać krótki wakacyjny wpis jako podsumowanie letniego okresu. Chociaż podsumowanie nie będzie tu najlepszym określeniem. Chciałem po prostu zamieścić przynajmniej jeden wpis podczas wakacji 2019 (np. dotyczący popularnej komendy telnet).

Ponieważ nie można tak od razu rzucić się na pracę, tym razem kilka krótkich akapitów o narzędziu telnet. Już ponad 20 lat używam go w codziennej pracy. Powszechnie wiadomo – jest niebezpieczne, powinniśmy go unikać jak tylko można, ale w zasadzie do sprawdzania otwartych portów na zdalnych hostach jest najszybsze. Zapewne większość administratorów używała nie raz polecenia:

telnet host.remote.net 80

żeby sprawdzić czy działa serwer stron www. Komenda ta zadziała nawet jeżeli firewall blokuje pakiety ICMP czyli jeżeli w wyniku:

ping host.remote.net

otrzymamy odpowiedź typu „host jest nieosiągalny”.

W najnowszych wersjach systemów Windows a dotyczy to zarówno stacji roboczych jak i serwerów, ze wspomnianych względów bezpieczeństwa nie ma już komendy telnet. Można ją oczywiście różnymi sposobami doinstalować, jest nawet całkiem sporo poradników typu how-to w sieci. Jednak skoro Microsoft zadecydował, że coś jest niebezpieczne to może znajdzie się alternatywa.

Okazuje się, że wraz z rozwojem środowiska PowerShell, Microsoft dorzuca nam z każdą wersją ciekawe narzędzia. Jednym z nich jest program Test-NetworkConnection. Jeżeli uruchomimy PowerShell w naszym systemie to całkiem spokojnie możemy go wypróbować. A ponieważ parę akapitów wcześniej wspominałem o telnet, to spróbujmy użyć TNC właśnie w taki sposób:

tnc host.remote.net -port 80

Wynikiem będzie raport z ostanią linijką zatytułowaną TcpTestSucceeded. Parametr ten przyjmuje wartości true/false i funkcjonalnie odpowiada staremu dobremu połączeniu za pomocą telnet. TNC ma oczywiście multum innych opcji i serdecznie zachęcam do zapoznania się z dokumentacją.

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: , , ,

xsibackup – ręczne kopie zapasowe VMware ESXi

26 stycznia, 2019 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

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.

Zapisz kopie xsibackup na streamerze.

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: , , , ,

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: , , , ,

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: , , , , ,