K-NET s.c.

Zarządzanie czasem pracy zdalnej: wprowadzenie do Kimai i Docker

Praca zdalna i prawo: efektywne monitorowanie czasu pracy

W Polsce, w obliczu nowych przepisów prawnych oraz rosnącej popularności pracy zdalnej, pojawiła się pilna potrzeba znalezienia skutecznych metod monitorowania czasu pracy. Zmiana ta wynika z konieczności dostosowania się do przepisów prawa pracy, które wymagają od pracodawców dokładnego rejestrowania czasu pracy pracowników, niezależnie od ich lokalizacji. Rozwiązanie ma na celu zapewnienie ochrony praw pracowniczych i przestrzegania norm dotyczących czasu pracy, co jest szczególnie ważne w modelu pracy zdalnej, gdzie tradycyjne metody rejestracji czasu pracy mogą być nieefektywne lub niewystarczające. Dlatego pojawiła się potrzeba wdrożenia narzędzi umożliwiających efektywne i zgodne z prawem zarządzanie czasem pracy zdalnej. Jednym z proponowanych jest bezpłatna platforma Kimai, która oferuje funkcjonalności konkurencyjne w stosunku do płatnych rozwiązań, takich jak TimeCamp czy Toggl, dostarczając równie efektywnych narzędzi do monitorowania czasu pracy, lecz bez dodatkowych kosztów dla organizacji.

Konteneryzacja Docker: efektywność i bezpieczeństwo

Konteneryzacja za pomocą Dockera stanowi jedną z najbardziej efektywnych metod wdrażania i zarządzania aplikacjami, oferując szereg zalet zarówno na systemach Windows, jak i Linux. Jedną z głównych zalet jest zdolność do szybkiego tworzenia gotowych do użycia serwerów w ciągu zaledwie kilku minut. Docker pozwala na izolację aplikacji w kontenerach, co zapewnia spójność środowiska między różnymi systemami operacyjnymi, eliminując typowe problemy związane z różnicami w konfiguracji. Co więcej, konteneryzacja ułatwia zarządzanie zasobami, umożliwiając efektywniejsze wykorzystanie dostępnej infrastruktury. Istotnym aspektem bezpieczeństwa jest możliwość korzystania z dobrze utrzymywanych i regularnie aktualizowanych obrazów kontenerów, co minimalizuje ryzyko eksploatacji znanych luk bezpieczeństwa. Dzięki temu, wybierając Docker, użytkownicy otrzymują nie tylko szybkie i elastyczne rozwiązanie do wdrażania aplikacji, ale także system, który przy odpowiednim zarządzaniu i wyborze źródeł może oferować wysoki poziom bezpieczeństwa.

Docker-compose: uproszczenie zarządzania wieloma kontenerami

Pakiet docker-compose jest narzędziem ułatwiającym zarządzanie wielokontenerowymi aplikacjami Docker. Pozwala on na definiowanie i uruchamianie aplikacji składających się z wielu kontenerów za pomocą jednego pliku konfiguracyjnego, zwanego docker-compose.yml. Dzięki temu, zamiast uruchamiać każdy kontener osobno i ręcznie zarządzać ich zależnościami oraz siecią, użytkownicy mogą wykorzystać docker-compose do automatyzacji tego procesu. Narzędzie to znacznie upraszcza proces konfiguracji środowiska, zwłaszcza w przypadku skomplikowanych aplikacji, gdzie interakcje między kontenerami są kluczowe. Ważne jest, że docker-compose nie jest domyślnie dołączony w instalacji standardowej wersji Docker i wymaga osobnego zainstalowania w systemie. Jest on dostępny zarówno dla systemów operacyjnych Windows, jak i Linux, a jego instalacja znacząco rozszerza możliwości zarządzania kontenerami Docker, ułatwiając pracę deweloperów i administratorów systemów. W systemie Windows docker-compose jest zwykle instalowany automatycznie wraz z Docker Desktop, a jego aktualizacja odbywa się poprzez aktualizację całego pakietu Docker Desktop.

Instalacja Kimai: konfiguracja via docker-compose

Aby rozpocząć instalację Kimai, pierwszym krokiem jest przygotowanie niezbędnego środowiska, a następnie utworzenie nowego folderu, w którym należy zapisać plik z poniższego przykładu. Jest on kluczowy dla procesu instalacji, gdyż zawiera konfigurację niezbędną do uruchomienia i zarządzania Kimai przy użyciu Docker-compose.

version: '3.5'
services:
  sqldb:
    image: mysql:5.7
    environment:
      - MYSQL_DATABASE=kimai
      - MYSQL_USER=kimai
      - MYSQL_PASSWORD=kimai
      - MYSQL_ROOT_PASSWORD=kimai
    volumes:
      - ./kimai2_db:/var/lib/mysql
    command: --default-storage-engine innodb
    restart: unless-stopped
  nginx:
    image: tobybatch/nginx-fpm-reverse-proxy
    ports:
      - 8080:80
    volumes:
      - public:/opt/kimai/public:ro
    restart: unless-stopped
    depends_on:
      - kimai
  kimai:
    image: kimai/kimai2:latest
    environment:
      - APP_ENV=prod
      - TRUSTED_HOSTS=localhost
      - ADMINMAIL=admin@example.me
      - ADMINPASS=changemeplease
      - DATABASE_URL=mysql://kimai:kimai@sqldb/kimai
      - TRUSTED_HOSTS=nginx,localhost,127.0.0.1
    volumes:
      - public:/opt/kimai/public
    restart: unless-stopped
volumes:
    public:

Żeby spersonalizować konfigurację trzeba zmienić dwa ustawienia zanaczone pogrubioną czcionką. W przypadku adresu e-mail będzie to zarazem nazwa konta do pierwszego logowania. W ostatnim kroku aby uruchomić swoją instancję Kimai i rozpocząć śledzenie czasu otwórz terminal, przejdź do folderu, w którym przechowywany jest powyższy plik, i wykonaj polecenie:

 docker-compose up -d

Po pomyślnym wykonaniu polecenia możesz otworzyć swoją instancję do śledzenia czasu Kimai w preferowanej przeglądarce internetowej i zalogować się przy użyciu danych uwierzytelniających z pliku docker.

G

Tagi: Docker, Kimai, Linux, Windows

Reset hasła administratora – Portainer

Konteneryzacja przy użyciu Dockera jest obecnie jednym z absolutnie topowych tematów. Świat zmierza w kierunku upraszczania i przyspieszania wszelkich operacji więc nikogo nie zdziwi, że do zarządzania Dockerem najłatwiej i najszybciej jest użyć nakładki o nazwie Portainer. Niestety zawodna pamięć ludzka (oraz brak dobrych nawyków) często prowadzą nas na manowce. W konsekwencji może zdarzyć się, że hasło administracyjne do tego ostatniego po prostu nam umknie. Co wtedy zrobić?

Po pierwsze musimy zmierzyć się z konsolą serwera i zatrzymać kontener Portainer:

docker stop "id-kontenera-portainera"

W drugim kroku przystępujemy do właściwej operacji pobierając odpowiednie narzędzie z repozytorium:

docker pull portainer/helper-reset-password

Ostatecznie możemy zeresetować hasło dla konta admin:

docker run --rm -v portainer_data:/data portainer/helper-reset-password

W wyniku działania powyższej komendy powinniśmy otrzymać zestaw niezbędnych informacji:

... Password succesfully updated for user: admin
... Use the following password to login: ****

Zwróćmy uwagę na wyświetlane hasło, które trzeba zapamiętać. Najprawdopodobniej zmienimy je przy pierwszej okazji ale na razie będzie nam potrzebne.

Na koniec używamy poniższego polecenia, aby ponownie uruchomić kontener z Portainerem, a następnie zalogować się przy użyciu nowego hasła.

docker start "id-kontenera-portainera"

Jak wspomniałem podejrzewam, że pierwszą czynnością będzie zmiana hasła i cały cykl znowu może się powtórzyć. 😉

Tagi: Docker, konteryzacja, Portainer

Kopie zapasowe Docker

Ten temat pojawiał się wielokrotnie we wpisach. Chodzi oczywiście o kopie zapasowe. Ludzie dzielą się na dwie kategorie tych, którzy je robią i tych, którzy je będą robili (truizm, ale trzeba go powtarzać do znudzenia). Tym razem, ponieważ od jakiegoś czasu bardzo popularne są rozwiązania oparte o konteneryzację, parę słów jak to zrobić gdy używamy środowiska Docker.

Oczywiście metodę, o której będzie za chwilę można również stosować np. do migracji całych kontenerów na nowe serwery.

Cała procedura składa się z kilku dosyć prostych kroków. Jedynym wymaganiem jest posiadanie dostępu w wiersza poleceń (konsola). Inna sprawa to mała sugestia, że najlepiej będzie skorzystać ze środowiska Linux (Debian, Ubuntu itp.) do budowy swojego serwera. Jednak w przypadku Windowsów również wszystko powinno działać.

Krok pierwszy to zatrzymanie kontenera, dla którego będziemy tworzyć kopię zapasową:

docker stop nazwa_kontenera

Jeżeli nie wiemy jakiej nazwy użyć lub po prostu otrzymujemy komunikat o błędzie wystarczy sprawdzić wszystkie dostępne kontenery:

docker container ls

W drugim kroku tworzymy obraz naszego kontenera:

docker commit nazwa_kontenera nazwa_kontenera

Ostatni parametr to tak naprawdę nazwa obrazu ale dla uproszczenia przyjmijmy, że jest ona taka sama jak nazwa kontenera.

Trzeci krok to zapisanie obrazu do pliku.

docker save nazwa_kontenera

W tym miejscu należy wspomnieć, że do tego momentu udało się zapisać stan kontenera. Jeśli instalacje, dla których robimy kopie mają zdefiniowane zewnętrzne wolumeny to należy skopiować ich zawartość oddzielnie. Generalnie można to zrobić ręcznie, ale dużo wygodniej będzie skorzystać z gotowego rozwiązania. Warto polecić skrypt docker-volumes.sh. Za jego pomocą dosyć łatwo można zapisać wszystkie stałe dane do jednego archiwum:

docker-volumes.sh nazwa_kontenera \ 
save nazwa_kontenera_wolumeny.tar.gz

Mając kopie zapasową w postaci dwóch plików tj. obrazu kontenera oraz wolumenów jesteśmy zabezpieczeni. Jeśli chcielibyśmy przenieść dane na inne sewery wystarczy skopiować je do nowej lokalizacji.

Ostatecznie na nowym serwerze, po przygotowaniu środowiska Docker, wykonujemy trzy polecenia.

Tworzymy kontener z wykorzystaniem skopiowanego obrazu:

docker create --name nazwa_kontenera \
{zestaw_opcji_uruchomieniowych} nazwa_kontenera

Przywracamy wolumeny:

docker-volumes.sh nazwa_kontenera load nazwa_kontenera_wolumeny.tar.gz

Uruchamiamy kopie kontenera:

docker start nazwa_kontenera

Przy odrobinie szczęścia, w tym momencie powinniśmy cieszyć się kolejną, nową instancją naszej usługi.

MG

Tagi: Docker, konfiguracja, kopie zapasowe

OpenVAS, GVM na Dockerze

OpenVAS należący do znanego projektu o nazwie GVM zalicza się do zestawu narzędzi typu trzeba mieć dla każdego współczesnego administratora, lub jak ktoś woli devopsa (prawda, że od razu brzmi lepiej?). Czy ktoś chce czy nie, temat cyberbezpieczeństwa stał się na tyle modny/istotny, że trzeba zawsze poważnie podchodzić do swoich zadań z tego zakresu. Aby zatem ustrzec się przed włamaniem najlepiej jest samemu sprawdzać swoje sieci, nawet za pomocą podstawowego zbioru wektorów, pod kątem podatności na ataki. Tak zwane testy penetracyjne (powszechnie określane jako pentesty) są tutaj bardzo pożądanym działaniem. I właśnie wspomniany na początku OpenVAS jest jednym z najlepszych środków dla zebzpieczenia się dzięki sprawdzeniu jake luki może posiadać sieć, którą się opiekujemy.

Istalacja OpenVAS od podstaw jest jak najbardziej możliwa, wymaga jednak umięjętnego poruszania się w środowisku Linuksa, oraz co najmniej średniego stopnia zaawansowania biorąc pod uwagę kompilacje kodu źródłowego. Aby w pełni uruchomić i dostroić pakiet trzeba skonfigurować poprawnie dużą liczbę zależności oraz dodatków, bez których aplikacja nie stanie się pełnowartościowym produktem.

Druga, nie mniej istotna sprawa to aktualizowanie definicji wektorów ataku, które przecież w dzisiejszych czasach zmieniają się dość gwałtownie. Jest to również proces, nad którym trzeba zapanować. Używanie do pentestów OpenVAS z niektualnymi zbiorami podatności mija się po prostu z celem.

Aby przyspieszyć proces wdrażania opisywanego narzędzia można skorzystać z kontenerów Docker. Jest to dobra wiadomość, w szczególności dla niezaawansowanych użytkowników. Niemniej próżno szukać oficjalnego źródła na portalach w rodzaju Docker Hub. Dlatego chciałem się podzielić konfiguracją, z kórej sam korzystam. Jest ona sprawdzona o tyle, że przekonałem się, iż jak na razie jest aktulizowana przez autora. Poza tym, aby pobrać najnowsze wektory wystarczy uruchomić ponownie kontener. W trakcie startu zostaną uruchomione skrypty, które zadbają o sprawdzenie stanu definicji i w przypadku konieczności zmiany wersji na nowszą wykonają to za nas.

Co zatem należy zrobić? Zakładając, że na przykład mamy już zainstalowany Docker wraz z docker-compose, oraz dla wygody środowisko graficzne do zarządzania kontenerami Portainer, przechodzimy do zakładki Stacks i budujemy nową konfigurację korzystając z poniższego kodu.

version: "3"
services:
openvas:
ports:
- "8080:9392"
environment:
- "PASSWORD=admin"
- "USERNAME=admin"
- "RELAYHOST=172.17.0.1"
- "SMTPPORT=25"
- "REDISDBS=512" # number of Redis DBs to use
- "QUIET=false" # dump feed sync noise to /dev/null
- "NEWDB=false" # only use this for creating a blank DB
- "SKIPSYNC=false" # Skips the feed sync on startup.
- "RESTORE=false" # This probably not be used from compose… see docs.
- "DEBUG=false" # This will cause the container to stop and not actually start gvmd
- "HTTPS=false" # wether to use HTTPS or not
volumes:
- "openvas:/data"
container_name: openvas
image: immauss/openvas
volumes:
openvas:

Więcej szczegółów można znaleźć na stronie https://github.com/immauss/openvas . Miłej zabawy.

MG

Tagi: Docker, komendy, konfiguracja, Linux

Portainer – aktualizacja

Portainer to jedna z najlepiej znanych i powszechnie stosowanych platform do wygodnego zarządzania kontenerami Dockera. Zamiast koncentrować się na zapamiętaniu komend linii poleceń możemy przez interfejs graficzny wyklikać praktycznie wszystko. Oczywiście, że zawsze znajdą się zwolennicy „czarnego ekranu”, przyznam że rówież często korzystam z tej metody, ale przy dużej liczbie zarządzanych kontenerów wygodniej jest po prostu skorzystać z przeglądarki.

Od czasu do czasu, w dolnym lewym rogu ekranu powitalnego Portainera pojawia się jednak informacja o dostępności nowej wersji. I w tym przypadku, nie ma już wyjścia, musimy posilić się bezpośrednio terminalem tekstowym. Poniżej zamieściłem podstawowe komendy, których użycie pozwoli zaktualizować Portainer. Oczywiście założyłem, że środowiskiem uruchomieniowym naszego Dockera jest Linux. W moim przypadku, bez wyjątku to któraś wersja pochodna z gałęzi Dabiana. Należy również wspomnieć, że jak będziemy już mieć najnowszy Portainer, to z jego poziomu możemy aktualizować inne kontenery, nie używając linii poleceń.

Zaczynamy od wpisania dwóch poleceń aby zatrzymać i usunąć kontener Portainera:

docker stop portainer
docker rm portainer

Następnie usuwamy obraz Portainera z lokalnego repozytorium:

docker images
docker rmi [IMAGE ID]

Pierwsze polecenie pokaże nam listę wszystkich obrazów. W kolejnym staramy się usunąć wybrany poprzez wskazanie jego ID.

Teraz czas na pobranie najnowszego obrazu Poratinera:

docker pull portainer/portainer-ce

I wreszcie możemy zainstalować nową wersję platformy:

docker run -d -p 8000:8000 -p 9000:9000 —name=portainer /
—restart=always -v /var/run/docker.sock:/var/run/docker.sock /
-v portainer_data:/data portainer/portainer-ce

Dobrze jest pamiętać aby nie zmieniać wartości parametru portainer_data, dzięki czemu nie stracimy ustawień konfiguracyjnych pomiędzy kolejnymi aktualizacjami.

I to wszystko. Teraz można przystąpić do testowania.

MG

Tagi: Docker, linia poleceń, Linux, Portainer, wirtualizacja

Apache Guacomole

Wakacje dobiegają końca. Będąc cały czas na urlopie zastanawiałem się czym mógłbym się podzielić. Zależało mi na czyś w miarę świeżym, ale jednocześnie lekkim do przyswojenia. Wybór padł na dwa tematy tj. platforma TP-Link Omada oraz bramka Apache Guacamole. Ten pierwszy jest dużym zagadnieniem, chociaż wielu użytkowników dowiaduje się o produkcie TP-Link przy okazji budowy zarządzanych centralnie sieci bezprzewodowych. Zapewniam jednak, że Omada to dużo więcej. Cóż, właśnie poznaję ten system, zatem dzisiaj parę, wakacyjnych jeszcze, zdań o bardzo przyjemnym wynalazku jakim jest Guacamole (nieco przewrotnie).

Na pewno każdy zajmujący się zagadnieniami sieciowymi czytelnik napotkał problem związany z uzyskaniem dostępu do zdalnych lokalizacji. Czy to będą sieci firmowe, czy też całkiem prywatne, zazwyczaj kończy się na uruchomieniu VPN. Wielokrotnie wspominałem, że najbardziej lubię tandem sprzętowo-programowy czyli router Mikrotika plus L2TP VPN. Główną przyczyną jest klient L2TP VPN, który został wbudowany w większość systemów operacyjnych, a Windows 10, po ostatnich aktualizacjach prowadzi wręcz za rękę jeśli chcemy z niego skorzystać.

Innym rozwiązaniem jest tzw. poor man’s VPN, czyli serwer SSH wraz z tunelowaniem i przekierowywaniem portów. Zalętą rozwiązania jest konieczność posiadania tylko jednego otwartego portu TCP na firewallu. Zaś wadą instalowanie użytkownikom klientów SSH, w tym najbardziej popularnego dla Windows PuTTY. Ich obsługa nie jest prosta dla przeciętnej osoby. Jak zauważyłem, mnogość opcji, która mnie osobiście przypadła do gustu stanowi problem dla innych. Jak dostać się do zdalnego pulpitu RDP w firmie za pomocą tunelu SSH, zdecydowanie nie należy do kwestii łatwych do wyjaśnienia.

Jeszcze inną kwestią pozostają klienty do obsługi wszelkich zdalnych dostępów, które muszą być bezpieczne i jednocześnie w prosty sposób dawać możliwość pracy ze zdalnymi zasobami. Czy można jednak pominąć jakiekolwiek instalacje i jednocześnie zabezpieczyć swój dostęp?

Okazuje się, że odpowiedzią na tak postawione pytanie jest bramka Apache Guacamole. Produkt ten cyt. jest aplikacją webową HTML5, która zapewnia dostęp do środowisk pulpitu za pomocą zdalnych protokołów (takich jak VNC lub RDP). Guacamole jest również projektem, który tworzy tę aplikację internetową i dostarcza API, które ją napędza. API może być używane do zasilania innych podobnych aplikacji lub usług. Tyle od autorów projektu.

Ponieważ wpis miał być wakacyjny, a to oznacza, że nie będę rozwodził się nad technikaliami, chciałbym natomiast zachęcić do wypróbowania. W tym miejscu zaoszczędzę Wam czasu i napiszę, że najprzyjemniejszą metodą instalacji Guacamole będzie kontener Dockera. Aby zrobiło się jeszcze łatwiej dodam, że można użyć platformy Portainer. Poniżej załączam plik dla docker-compose, co jak mam nadzieję spowoduje, że cała instalacja będzie trwała tylko parę minut (sekcja Stacks w Portainer). Resztę pozostawiam na letni wieczór, mamy końcówkę sierpnia, zatem ciemno robi się już dosyć wcześnie, a nic lepiej nie nastraja do zabawy z nowym oprogramowaniem.

version: "2"
services:
guacamole:
image: oznu/guacamole
container_name: guacamole
volumes:
- postgres:/config
ports:
- 8080:8080
volumes:
postgres:
driver: local

MG

Tagi: Docker, konfiguracja, serwer

Konteneryzacja – error while removing network

Konteneryzacja jest obecnie bardziej modna niż wirtualizacja. Świadomie zaryzykuję takie stwierdzenie choć wiem, że wielu mogłoby się oburzyć. Nie obecnie, tylko od kilku lat, oraz wirtualizacja nadal ma się dobrze. Trzeba jednak przyznać, że lista aplikacji, które zostają zwirtualizowane do formy kontenera np. typu Docker, wydłuża się z każdym rokiem wykładniczo. Dlatego jako fanatyk klasycznej wirtualizacji również musiałem zmierzyć się z tym zagadnieniem. Początki były trudne i nie była to miłość od pierwszego wejrzenia. Jednak z czasem powoli przekonywałem się, chociaż do dzisiaj gnębi mnie myśl o bezpieczeństwie w kontekście aktualizacji gotowych kontenerów dostępnych chociażby przez stronę Docker Hub. Jest to jednak historia na inną opowieść.

Wracając do tematu, skoro przekonałem się do świata kontenerów to zacząłem niemal masowo testować nowe rozwiązania, aplikacje itd. Taki jest los neofity, ale co na to poradzić. Będąc jednocześnie zagorzałym zwolennikiem minimalizmu, wymyśliłem sobie implementację minimalnego serwera w oparciu o Debian Buster (coś w rodzaju bare metal) gdzie jedynym większym softem będzie właśnie paczka docker. W miarę przybywania aplikacji w moim testowym środowisku zacząłem szukać nakładki graficznej do zarządzania. Z pomocą przyszedł pakiet Portainer ze środowiskiem graficznym do zarządzania całą wirtualizacją wraz z prawie jej wszystkimi elementami. Brnąłem dalej. Wiadomo jednak, że im dalej w las tym więcej drzew. Zaczęły się pojawiać problemy. Co gorsza czasami były to w zasadzie dość zasadnicze usterki Dockera. Jedną z nich okazały się hmm… nieścisłości dotyczące definiowania sieci przydzielanych poszczególnym aplikacjom.

Jedną z opcji dostępnych z poziomu Dockera jest tworzenie tzw. macvlan. Jest to sieć kontenerów, które są wystawione poza natowaną warstwą sieciową chronioną przez natywną wirtualizację, co zapewnia oczywiście separowanie aplikacji, a więc odpowiedni poziom bezpieczeństwa, ale uniemożliwia z kolei przydzielanie adresów IP na poziomie równorzędnym z hostem dockera. Czasami potrzebujemy właśnie takiego rozwiązania aby uzyskać efekt podobny do interfejsu typu bridge z klasycznej wirtualizacji (VMware czy KVM). Niestety moim zdaniem obsługa macvlan jest po prostu źle napisana. W wyniku eksperymentowania z sieciami tego typu często dochodzi do sytuacji, w której w systemie pozostają sieci macvlan zachowujące się jak zombie tzn. takie, które do niczego nam się nie przydają (chcieliśmy akurat coś przetestować) a nie można ich usunąć bo otrzymujemy błąd:

“Error response from daemon: error while removing network: configuration network “…. macvlan x.x.x.x” is in use”

W sieci można znaleźć bardzo dużo informacji na ten temat oraz niemal tyle samo propozycji rozwiązania. Ja natomiast chciałem zaproponować jedno z nich, wybrane przeze mnie i myślę, że niezawodne. Zaznaczam od razu, że dotyczy ono hostów typu Linux i wymaga minimalnej znajomości konsoli systemowej. Cały przepis wygląda mniej więcej tak:

• Zaloguj się do swojego hosta za pomocą połączenia SSH.
• Zmień konto na root (o ile już nie zalogowałeś się jako root, ale w tym przypadku poważnie zastanowiłbym się nad zabezpieczeniami Twojego systemu)
• Usuń ręcznie plik local-kv.db

rm /var/lib/docker/network/files/local-kv.db

Tyle w temacie. Rozwiązanie ma tylko taką wadę, że usuwa wszystkie zdefiniowane przez nas sieci ze środowiska konteryzacji. Pozostawia oczywiście tylko te standardowe tj. tworzone na początku instalacji Dockera. Ale porządek na pewno zostanie przywrócony. 🙂

MG

Tagi: Docker, linia poleceń, Linux

Problem wyciekania danych

Problem wyciekania danych z naszych komputerów jest jednym z najczęściej omawianych zagadnień przez ostatnie miesiące a nawet lata. Skądinąd wiadomo, że wszyscy wielcy gracze na rynku ogólnie pojętych usług internetowych starają się pozyskiwać wszelkie możliwe informacje niezależnie od tego czy wyrażamy na to zgodę czy nie. A ponieważ nawet Ci, którzy dotychczas nie korzystali z usług rozporoszonych, na przykład w architekturze klient-serwer, opracowali nowe wersje swoich produktów, które po prostu wymagają Internetu pod pozorem chociażby aktualizacji, to praktycznie każdy chce stosować telemetrię. Jest to oczywiście dość łagodne określenie dla ciągłej obserwacji użytkownika, uczenia się jego nawyków itp.

Żeby walczyć z podobnymi praktykami można zastosować kilka różnych podejść. Pierwszym, które wydaje się być dosyć oczywiste jest zainstalowanie odpowiedniej aplikacji. Często funkcje nadzorowania połączeń wychodzących z komputera mają wszelkiej maści programy antywirusowe. Ale uwaga – bywa, że same lubią nas podglądać. Poza tym wiele aplikacji potrafi wykryć działanie tychże i na przykład prosić użytkownika o wyłączenie zapory pod pozorem odmowy świadczenia dalej usługi.

Kolejnym jest zainstalowanie w przeglądarce internetowej odpowiednich dodatków. Dotyczy to oczywiście korzystania z samej przeglądarki i nie zabezpiecza przed innym rodzajem użytkowania. Nie mniej wtyczki takie jak AdBlock czy Ghostery są bardzo popularne. Ponadto producenci samych przeglądarek dodają w ich najnowszych wersjach blokowanie reklam itd. Z drugiej strony czy można im wierzyć do końca? To pytanie retoryczne. Jedno jest pewne – ta metoda również ma wiele wad.

Trzecim rozwiązaniem będzie skorzystanie z połączenia VPN z funkcją blokowania dla wycieku danych z naszych komputerów. Wymaga to najczęściej zastosowania dodatkowej aplikacji, która będzie w stanie wygenerować wspomniane połączenie VPN, za co nierzadko trzeba zapłacić. Tutaj prym wiedzie usługa o nazwie Internet Private Access. Posiada bardzo szerokie możliwości konfiguracji oraz aplikacje w wersji instalacyjnej dla niemalże każdego systemu operacyjnego. Do równie ciekawych rozwiązań, które zdążyły już zdobyć pewną sławę w kręgach deweloperów należy ProtonVPN. Lista dostawców jest naprawdę długa i nietrudno jest wyszukać odpowiedniego dla siebie.

Na sam koniec zostawiłem rozwiązanie, które moim zdaniem jest najlepsze. Jest ono lekkie bo nie wymaga instalowania żadnego dodatkowego oprogramowania. Ciężko jest je wykryć (mam na myśli aplikacje czy systemy korzystające z telemetrii) bo ingeruje w jeden z podstawowych protokółów sieciowych jakim jest DNS. Jest w stanie zmienić zachowanie absolutnie każdego programu, który tylko będzie chciał nawiązać komunikację przez sieć Internet. Co więcej, całkiem prawdopodobne, że przyspieszy oraz poprawi funkcjonowanie naszych końcówek sieciowych, bo znacznie ograniczy niepotrzebny ruch. Mowa oczywiście o serwerze DNS, który będzie miał odpowiednio skonfigurowane reguły rozwiązywania nazw, tak aby po prostu zablokować wszystkie podejrzane odwołania.

W wersji dla leniwych można po prostu skorzystać z bezpłatnego (będzie miał wyłączone niektóre funkcje ale na początek powinno wystarczyć) gotowca. Jest nim na przykład serwis OpenDNS. Przyznam, że korzystałem z niego przez wiele lat z dużym powodzeniem. Po zarejestrowaniu konta użytkownika oraz skonfigurowaniu serwerów DNS, czyli podaniu poniższych wartości w ustawieniach karty sieciowej system startował bez zarzutu.

208.67.222.222
208.67.220.220

W wersji dla zuchwałych trzeba samemu lokalnie przygotować serwer DSN, który będzie mógł obsługiwać ruch sieciowy. Bardzo dobrym rozwiązaniem jest w tym przypadku Pi-hole. Społeczność użytkowników i programistów przygotowała kompletny system, gotowy do użycia “po wypakowaniu z pudełka”. Można go zastosować na mikrokomputerze Raspberry Pi – jest to jeszcze jedno jego doskonałe zastosowanie. Można również, do czego zachęcam, skorzystać z kontenerów Docker i w zasadzie jednym poleceniem postawić cały serwer.

docker-compose up --detach

Szczegółowy opis jak zainstalować całość jest dostępny na GitHubie – https://github.com/pi-hole/docker-pi-hole.

Na zakończenie warto zadać ponownie pytanie – problem wyciekania danych, czy można skutecznie przeciwdziałać? Odpowiedzią niech będzie prosty raport z dnia dzisiejszego dla mojej domowej sieci.

MG

Tagi: Docker, konfiguracja, serwer

Docker, Portainer i kłopoty z OpenProject

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: Docker, komendy, konfiguracja, linia poleceń, serwer, wirtualizacja