K-NET s.c.

Mailcow – instalacja i aktualizacja serwera poczty w Dockerze

Mailcow to jedno z ciekawszych rozwiązań dla osób, które chcą uruchomić własny serwer poczty bez ręcznego składania Postfixa, Dovecota, Rspamd, SOGo, antywirusa, webmaila i całej reszty usług. Wszystko działa w kontenerach Dockera, a administracja odbywa się z poziomu wygodnego panelu WWW.

W tym artykule pokażę praktyczną instalację Mailcow na serwerze Linux z Dockerem oraz bezpieczną procedurę aktualizacji. Nie będzie to opis „kliknij i zapomnij”, bo serwer poczty wymaga poprawnego DNS, portów, certyfikatów i kopii zapasowych. Będzie za to prosta checklista, która pozwala uniknąć typowych błędów.

W artykule pokażę:

• co sprawdzić przed instalacją Mailcow,
• jak przygotować system i Dockera,
• jak pobrać i uruchomić Mailcow,
• jakie rekordy DNS są potrzebne,
• jak zrobić backup,
• jak bezpiecznie wykonać aktualizację.

Uwaga: własny serwer poczty to nie tylko kontener Docker. Najważniejsze są: poprawny DNS, rekord PTR, otwarty port 25, reputacja adresu IP oraz regularne aktualizacje.

Dlaczego Mailcow?

Mailcow jest wygodny, bo zbiera w jednym projekcie większość elementów potrzebnych do uruchomienia pełnego serwera poczty. W praktyce dostajemy gotowy zestaw usług: SMTP, IMAP, webmail, filtrowanie spamu, obsługę domen, skrzynek, aliasów, certyfikatów oraz panel administracyjny.

Dla małej firmy, laboratorium, homelabu albo środowiska testowego jest to dużo prostsze niż ręczna konfiguracja każdego komponentu osobno. Nadal jednak trzeba pamiętać, że poczta elektroniczna jest wrażliwa na błędy konfiguracyjne. Źle ustawiony DNS albo zablokowany port 25 potrafi sprawić, że technicznie wszystko działa, ale poczta nie dochodzi albo trafia do spamu.

Zanim zaczniesz

Przed instalacją warto przygotować kilka rzeczy:

• serwer VPS lub maszynę wirtualną z publicznym adresem IP,
• pełną wirtualizację, np. KVM, ESXi, Hyper-V lub podobne rozwiązanie,
• system Debian albo Ubuntu,
• minimum 6 GB RAM oraz dodatkowy swap,
• wolne porty usług pocztowych i WWW,
• domenę, którą będziesz obsługiwać w Mailcow,
• możliwość ustawienia rekordu PTR/reverse DNS u operatora serwera.

Ważne: Mailcow nie powinien być uruchamiany w LXC/OpenVZ. To rozwiązanie najlepiej traktować jako usługę dla normalnej maszyny wirtualnej lub serwera fizycznego.

Porty, które muszą być wolne

Na początku sprawdź, czy na serwerze nie działa już inny serwer WWW albo inny MTA, np. Exim, Postfix z systemu albo stary kontener pocztowy.

ss -tlpn | grep -E -w '25|80|110|143|443|465|587|993|995|4190'

Najważniejsze porty dla Mailcow to:

• 25/tcp – SMTP, odbieranie poczty z Internetu,
• 465/tcp – SMTPS,
• 587/tcp – Submission, wysyłka poczty przez użytkowników,
• 143/tcp i 993/tcp – IMAP i IMAPS,
• 110/tcp i 995/tcp – POP3 i POP3S,
• 4190/tcp – ManageSieve,
• 80/tcp i 443/tcp – panel WWW, webmail i certyfikaty.

Jeżeli któryś z tych portów jest już zajęty, instalacja może się uruchomić częściowo albo zakończyć błędem. Warto rozwiązać ten problem przed startem kontenerów, a nie dopiero po fakcie.

DNS – najważniejszy element całej instalacji

Dla przykładu przyjmijmy, że serwer Mailcow będzie działał pod adresem:

mail.example.pl

Minimalnie warto przygotować:

• rekord A dla mail.example.pl wskazujący na publiczny adres IPv4 serwera,
• opcjonalnie rekord AAAA, jeśli używasz IPv6,
• rekord MX domeny wskazujący na mail.example.pl,
• rekord PTR dla adresu IP, również wskazujący na mail.example.pl,
• rekordy SPF, DKIM i DMARC – część z nich Mailcow podpowie po dodaniu domeny w panelu.

Praktyczna rada: bez poprawnego PTR poczta może działać technicznie, ale z dużym ryzykiem problemów z dostarczalnością. W przypadku VPS rekord PTR zwykle ustawia się w panelu operatora.

Instalacja Mailcow krok po kroku

Krok 1: Aktualizacja systemu

Na początku aktualizujemy system i instalujemy podstawowe narzędzia wymagane przez instalator.

apt update
apt upgrade -y
apt install -y git openssl curl gawk coreutils grep jq

Krok 2: Instalacja Dockera

Mailcow zaleca używanie aktualnego Dockera, a nie bardzo starej wersji z repozytorium dystrybucji. Najprostsza metoda instalacji na Debianie/Ubuntu wygląda tak:

curl -sSL https://get.docker.com/ | CHANNEL=stable sh
systemctl enable --now docker

Po instalacji sprawdź wersję:

docker version

Krok 3: Instalacja Docker Compose jako plugin

W nowych instalacjach najwygodniej używać składni docker compose, czyli bez myślnika.

apt update
apt install -y docker-compose-plugin

Sprawdzenie wersji:

docker compose version

Krok 4: Pobranie Mailcow

Przechodzimy do katalogu /opt, pobieramy oficjalne repozytorium i uruchamiamy generator konfiguracji.

cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh

Podczas generowania konfiguracji podaj pełną nazwę hosta, np.:

mail.example.pl

Po wygenerowaniu konfiguracji warto zajrzeć do pliku:

nano mailcow.conf

Na tym etapie można sprawdzić m.in. nazwę hosta, ustawienia IPv6, porty oraz ewentualne dodatkowe parametry.

Krok 5: Uruchomienie Mailcow

Gdy konfiguracja jest gotowa, pobieramy obrazy i uruchamiamy kontenery:

docker compose pull
docker compose up -d

Pierwsze pobieranie obrazów może potrwać dłuższą chwilę. Po starcie sprawdź stan kontenerów:

docker compose ps

Logi można podejrzeć poleceniem:

docker compose logs --tail=100

Pierwsze logowanie

Panel administracyjny powinien być dostępny pod adresem:

https://mail.example.pl/admin

Domyślne dane logowania to:

login: admin
hasło: moohoo

Uwaga: hasło administratora należy zmienić od razu po pierwszym logowaniu. Warto też włączyć dodatkowe zabezpieczenia konta administracyjnego.

Dodanie domeny i rekordów DNS

Po zalogowaniu dodaj domenę pocztową, np. example.pl. Mailcow podpowie rekordy DNS, które należy ustawić u operatora domeny. Szczególnie ważne są:

• MX – wskazanie serwera poczty,
• SPF – informacja, kto może wysyłać pocztę z domeny,
• DKIM – podpisywanie poczty kluczem domeny,
• DMARC – polityka obsługi wiadomości, które nie przejdą SPF/DKIM.

Po zmianach DNS trzeba odczekać na propagację rekordów. W praktyce część zmian działa po kilku minutach, ale pełna propagacja może potrwać dłużej.

Backup Mailcow

Przed każdą większą zmianą i przed aktualizacją warto wykonać backup. Mailcow dostarcza do tego gotowy skrypt:

cd /opt/mailcow-dockerized
./helper-scripts/backup_and_restore.sh backup all --delete-days 14

Można też wskazać katalog backupu przez zmienną środowiskową:

MAILCOW_BACKUP_LOCATION=/mnt/backup/mailcow \
./helper-scripts/backup_and_restore.sh backup all --delete-days 14

W środowisku produkcyjnym warto dodatkowo wykonywać snapshot maszyny wirtualnej albo kopię katalogów na zewnętrzny system backupu. Sam fakt, że usługa działa w Dockerze, nie zastępuje kopii zapasowej.

Moja zasada: najpierw backup, potem aktualizacja. Nigdy odwrotnie.

Aktualizacja Mailcow

Aktualizacja Mailcow jest bardzo prosta, ale nie należy jej wykonywać „w ciemno”. Najpierw warto sprawdzić, czy aktualizacja jest dostępna:

cd /opt/mailcow-dockerized
./update.sh --check

Jeżeli wszystko wygląda poprawnie, wykonujemy backup:

./helper-scripts/backup_and_restore.sh backup all --delete-days 14

Dopiero po backupie uruchamiamy właściwą aktualizację:

./update.sh

Skrypt sam pobierze zmiany, obrazy kontenerów i w razie potrzeby zada dodatkowe pytania. Po aktualizacji sprawdzamy stan usług:

docker compose ps
docker compose logs --tail=100

Jeżeli chcesz tylko posprzątać stare obrazy po aktualizacjach, można użyć:

./update.sh --gc

Co sprawdzić po aktualizacji?

Po aktualizacji warto wykonać krótką checklistę:

• czy wszystkie kontenery są uruchomione,
• czy panel administracyjny działa,
• czy webmail SOGo działa,
• czy można wysłać wiadomość na zewnątrz,
• czy można odebrać wiadomość z zewnątrz,
• czy certyfikat TLS jest poprawny,
• czy w logach nie ma powtarzających się błędów.

Przydatne polecenia:

docker compose ps
docker compose logs --tail=200 -f
ss -tlpn | grep -E -w '25|80|110|143|443|465|587|993|995|4190'

Najczęstsze problemy

Port 25 jest zablokowany

To jeden z najczęstszych problemów. Wielu operatorów VPS blokuje port 25 wychodzący lub przychodzący, szczególnie na nowych kontach. Bez portu 25 serwer poczty nie będzie poprawnie wymieniał wiadomości z Internetem.

Brak rekordu PTR

Jeżeli adres IP nie ma poprawnego reverse DNS, część serwerów może odrzucać pocztę albo traktować ją jako podejrzaną. PTR powinien wskazywać na nazwę hosta Mailcow, np. mail.example.pl.

Inna usługa zajmuje port 80 lub 443

Jeżeli na serwerze działa już Apache, Nginx albo inny reverse proxy, Mailcow może nie wystartować poprawnie. Wtedy trzeba zdecydować, czy Mailcow ma używać tych portów bezpośrednio, czy ma działać za istniejącym reverse proxy.

Instalacja w LXC

Mailcow nie jest dobrym kandydatem do LXC. Jeżeli używasz Proxmoxa, najbezpieczniej przygotować normalną maszynę wirtualną, a nie kontener LXC.

Brak backupu przed aktualizacją

Aktualizacja zwykle przebiega bezproblemowo, ale serwer poczty przechowuje ważne dane: skrzynki, konfigurację domen, klucze DKIM, bazę SQL, Redis, ustawienia Rspamd. Backup przed aktualizacją powinien być standardem.

Podsumowanie

Mailcow bardzo ułatwia uruchomienie własnego serwera poczty, bo większość trudnych elementów jest gotowa w jednym projekcie. Nie zwalnia to jednak administratora z myślenia o DNS, portach, certyfikatach, backupach i aktualizacjach.

Najbezpieczniejsza procedura wygląda tak:

1. przygotuj poprawny DNS i PTR,
2. sprawdź porty,
3. zainstaluj aktualnego Dockera i Docker Compose,
4. wygeneruj konfigurację Mailcow,
5. uruchom kontenery,
6. dodaj domenę i rekordy SPF/DKIM/DMARC,
7. regularnie wykonuj backup,
8. aktualizuj przez ./update.sh.

Mailcow jest świetnym narzędziem, ale wymaga porządku administracyjnego. Jeśli potraktujesz go jak normalną usługę produkcyjną, z backupem i checklistą aktualizacji, potrafi odwdzięczyć się stabilną pracą.

Twoja kolej

Masz własne doświadczenia z Mailcow? Udało Ci się uruchomić go w homelabie, firmie albo na VPS? A może największym problemem okazał się DNS, port 25 albo reputacja adresu IP?

Daj znać w komentarzu. Takie praktyczne uwagi są często bardziej wartościowe niż sama dokumentacja.

G

Tagi: Docker, e-mail, Linux, serwer, webmail

Wirtualizacja KVM – przekierowanie ruchu

Wielokrotnie pisałem o mojej ulubionej wirtualizacji czyli środowisku VMware. Pomimo doświadczeń z innymi rodzajami hostów nadal uważam, że jest to naprawdę bardzo dobrze zrównoważone rozwiązanie. Drugą istotną cechą jest wsparcie techniczne, które pod postacią dokumentacji elektronicznej oraz komentarzy użytkowników jest uporządkowane i pieczołowicie utrzymywane przez samego producenta. Wszystko to sprawia, że nawet jeżeli spotka nas jakiś ezoteryczny problem to od razu wiadomo gdzie szukać rozwiązania.

Jednak jak zwykle życie wymusza często zmiany w rozwiązaniach i ostatnio zmierzyłem się z maszynami wirtualnymi KVM. Posiadając działający i w pełni skonfigurowany serwer zbudowany na bazie np. Debiana, nie ma raczej innego wyjścia chociaż można spróbować tzw. poor man virtualization czyli Virtualbox w trybie headless. Przyznam, że do tej pory mam pod opieką jeden taki wynalazek. Wracając do KVM to warto zaznaczyć, że nawet jeżeli nie lubisz konfiguracji z użyciem komend to możesz zaistalować chociażby pakiet Cockpit i uzyskać tym samym zarządzanie przez webinterface.

Niezależnie w jaki sposób będziemy korzystać z KVM warto zadbać o bezpieczeństwo konfigurując swoje węzły wirtualne w dedykowanej wirtulanej sieci za NATem. W ten sposób odetniemy możliwość bezpośredniego atakowania usług sieciowych. Z kolei na potrzeby chociażby testowania mamy wygodne rozwiązanie na kształt prywatnej sieci lokalnej z dostępem do Internetu.

Załóżmy następnie, że będziemy chcieli wystawić wybraną usługę, może to być np. serwer www na zewnątrz sieci LAN. Powinniśmy użyć mechanizmu forwardowania pakietów pod wskazany wewnętrzny adres IP, na wskazany port. Jest to powszechnie wykorzystywana metoda w wielu domowych (i nie tylko) routerach z firewallem. W tym miejscu dochodzimy do głównego wyzwania bo przecież interfejs sieciowy KVM oraz interfejs fizyczny nie są ze sobą wprost związane. Żeby przekazywać komunikację między jednym a drugim trzeba skorzystać z dodatkowej konfiguracji za pomocą iptables.

Biorąc za przykład przekazywanie ruchu do serwera www (via HTTPS) będą potrzebne dwie reguły:

iptables -t nat -I PREROUTING -p tcp -d 1.2.3.4 --dport 443 / 
-j DNAT --to-destination 10.0.0.1:443
iptables -I FORWARD -m state -d 10.0.0.1/24 /
--state NEW,RELATED,ESTABLISHED -j ACCEPT

Domyślny konfiguracja KVM NAT zapewnia regułę podobną do drugiej linijki, ale pomija stan NEW, który jest niezbędny do akceptacji połączeń przychodzących. W przykładzie 1.2.3.4 jest adresem publicznym (zewnętrznym) zaś 10.0.0.1 adresem prywatnym. Należy je zmienić według potrzeb i konfiguracji własnej sieci.

Dopiero wpisanie z linii poleceń powyższych dwóch komend pozwoli nam skomunikować się z maszyną wirtualną KVM. Jako zadanie domowe polecam sprawdzenie jak można dodoac reguły do konfiguracji tak aby nie trzeb było ich za każdym razem ręcznie podawać po starcie systemu.

MG

Tagi: iptables, KVM, Linux, wirtualizacja

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

Jak naprawić URL po przeniesieniu witryny WordPress pod nowy adres

WordPress jest jednym z najbardziej popularnych systemów zarządzania treścią tzw. CMS. Sam używam wyłącznie WordPressa i wysoko go sobie cenie. Nie chciałbym rozpisywać się o zaletach tego oprogramowania, jak również tworzyć kolejnego poradnika instalacji czy konfiguracji. Materiałów w sieci jest wystarczająco dużo. Tym razem chciałbym pokazać jak rozwiązać bardzo konkretny problem, związany z przenoszeniem, tworzeniem kopii testowych itp. witryn utworzonych za pomocą opisywanego CMSa.

Generalnie, wykonywanie kopii witryn WordPressa to przede wszystkim:

• kopiowanie i przenoszenie bazy danych oraz
• kopiowanie i przenoszenie całej struktury katalogów i plików

Niemniej, nawet jeżeli całkiem nieźle radzimy sobie z powyższymi zadaniami to trzeba pamiętać, że nasza strona WordPress jest widoczna jako adres URL w sieci np. 'www.strona-wp.pl’. Tworząc jej kopie albo przenosząc pod nowy adres trzeba pamiętać o uaktualnieniu bazy danych. WordPress zapisuje bowiem wyświetlane elementy typu grafiki, dokumenty itp. za pomocą ich adresu URL. Często, przeniesiona strona, właśnie z tego powodu nie chce wyswietlać żadnych grafik bądź innych obiektów. Co możemy zrobić? Wykonać trzy polecenia UPDATE w środowisku bazy danych:

1. UPDATE wp_options SET option_value = replace(option_value, →
   'http://www.stary-adres.pl', 'http://www.nowy-adres.pl') →
   WHERE option_name = 'home' OR option_name = 'siteurl';

2. UPDATE wp_posts SET guid = replace(guid, →
   'http://www.stary-adres.pl','http://www.nowy-adres.pl');

3. UPDATE wp_posts SET post_content = replace(post_content, →
   'http://www.stary-adres.pl', 'http://www.nowy-adres.pl');

Reszte poprawek musimy wykonać ręcznie, edytując konfiguracje witryny. Niemniej przytoczone polecenia pozwolą na pewno zaoszczędzić mnóstwo czasu.

MG

Tagi: Linux, serwer, Windows, WordPress

Serwer NTP w systemie Windows Server 2008 R2

Problem synchronizacji czasu w sieci lokalnej bywa często pomijany. W sieciach z jednorodnym środowiskiem np. Linux czy Windows nie stanowi dużego wyzwania. Jednak co zrobić gdy mamy ekosystem (popularny ostatnio termin) mieszany. Stacje robocze Windows są od razu wyposażone w klienta synchronizacji czasu. Nie chce on jednak współpracować z bardzo dobrym oprogramowaniem, serwerem NTP, na Linuxie. Chyba jeszcze nikomu nie udało się zmusić do poprawnej współpracy wspomnianych systemów. Nie pozostaje zatem nic innego jak przygotwać serwer NTP w środowisku Windows. Nasz bohater, Windows Serwer 2008 R2 posiada taką usługę, jednak myli się ten, kto myśli, że jego konfiguracja polega wyłącznie na tzw. 'wyklikaniu’.

Z drugiej strony wystarczy, że spełnimy 3 warunki:

1. Utworzymy regułę zapory systemowej dla ruchu przychodzącego, dla portu 123 i protokołu UDP
2. Upewnimy się, że usługa 'Czas systemu Windows’ jest skonfigurowana jako uruchomienie automatyczne
3. Znamy pewne 'magiczne’ polecenie…

W zasadzie wszystko sprowadza się do punktu 3 a komenda wygląda tak:

w32tm /config /syncfromflags:manual →
/manualpeerlist:europe.pool.ntp.org → 
/reliable:yes /update

Cały proces kończymy poleceniem:

w32tm /resync

Od tego momentu możemy konfigurować stacje robocze wskazując powyższy serwer jako źródło czasu.

Na koniec wypada dodać, że w Internecie można znaleźć dużo materiałów, oficjalnych bądź nie, na ten temat. Jednak przytoczona tutaj metoda jest sprawdzona i skuteczna.

MG

Tagi: NTP, serwer, Windows

Rola rekordu SRV w konfiguracji MS Exchange

Microsoft Exchange Server jest obecnie jednym z popularnych serwerów pracy grupowej w firmach. Nie jest to rozwiązanie tanie. Szczególnie jeśli uwzględnimy koszt budowy infrastruktury zgodnie z zaleceniami Microsfotu, koszt licencji dostępowych CAL itd. Tak czy inaczej jeżeli zdecydowaliśmy się już na zakup oprogramowania i nie mamy kilku serwerów do wykorzystania musimy liczyć się z koniecznością gruntownego zabezpieczenia naszego głównego serwera Exchange. Konfiguracja, o której mówie zakłada zainstalowanie 3 głównych ról serwera (Hub Transport Server, Mailbox Server oraz CAS – Client Access Server) na jednym serwerze. W omawianym przypadku nie zajmujemy się serwerem brzegowym (Edge Transport Server).

Ponieważ na wspomnianym serwerze instalujemy usługi dostępowe CAS (w tym dla klientów mobilnych, z poza sieci firmowej) należy zabezpieczyć go wszelkimi możliwymi środkami. Najprostszym i najtańszym rozwiązaniem jest zorganizowanie komunikacji z wykorzystaniem protokołu HTTPS (port 443). Klient poczty Microsoft Outlook posiada możliwość połączenia się z serwerem Exchange za pomocą tandemu RTP over HTTPS. Można zatem łatwo dodać regułę na firewallu firmowym, umożliwiącą komunikację z zewnątrz z serwerem Exchange na porcie 443.

Niestety Outlook wykorzystuje często funkcje autokonfiguracji działającą w oparciu o usługę Autodiscover. W tym miejscu dochodzimy do sedna problemu opisywanego w tym artykule. Jeżeli domena Active Directory (np. corp.firma.com) różni się od domeny internetowej (np. firma.com) to Outlook będzie zasypywał nas komunikatami o błędach. Istnieje wiele sposobów zapobiegania takim sytuacjom. Jednym z najbardziej skutecznych jest wykorzystanie rekordu SVR na zewnętrznych serwerach nazw. W ten sposób Outlook z każdego miejsca w internecie będzie mógł połączyć się z naszym serwerem Exchange. Rekord SRV dla Exchange będzie miał następującą postać (użyłem przykładu dla popularnego serwera bind):

_autodiscover._tcp.firma.com. IN SRV 0 5 443 server.corp.firma.com.

Musimy jeszcze pamiętać o rekordzie A dla domeny z przykładu – firma.com:

server.corp IN A 1.2.3.4

Takie rozwiązanie pozwoli uniknąć w przyszłości chóru narzekających użytkowników. I o to w zasadzie w tym wszystkim chodzi…

MG

Tagi: Active Directory, MS Exchange, poczta elektroniczna, Windows

Jednorazowe korzystanie z Proxy podczas aktualizacji

Jednym z wielu zadań należących do administratora systemu Linux Debian jest wykonywanie aktualizacji. Funkcjonuje nawet anegdota, że użytkownika Debiana można rozpoznać po tym, iż każdy dzień rozpoczyna od komendy:

apt-get update

Tak czy inaczej czasami zdarza się, że aktualizacje ciągną się w nieskończoność a szybkość połączenia pozostawia wiele do życzenia. Nie są to niestety sporadyczne przypadki. Dodatkowo jeżeli mamy do czynienia z kilkoma serwerami w sieci, które powinniśmy zaktualizować sytuacja może być irytująca. Rozwiązaniem w tym przypadku jest serwer proxy. Co zrobić jednak, gdy chcemy z niego skorzystać tylko jednorazowo na czas aktualizacji? Rozwiązanie jest bardzo proste i wymaga jedynie dostępu do konsoli. Wydajemy polecenie:

http_proxy='http://adres_serwera_proxy:port'

co pozwoli nam na wykorzystanie proxy ad-hoc bez rekonfiguracji ustawień systemowych.

MG

 

Tagi: Debian, Linux, serwer

Termometr IP dla ochrony serwerowni – część II

Jakiś czas temu opisywałem rozwiązanie polegające na zdalnym pomiarze parametrów pracy pomieszczenia (np. serwerowni). Przez ten czas zmieniła się konfiguracja obserwowanej serwerowni i pojawiły się nowe urządzenia. Pomyślałem zatem o scentralizowanym rozwiązaniu, które umożliwi obserwacje stanu większej ilości czujników a przy tym pozwoli na generację alarmów w sytuacjach krytycznych. Konfigurowanie pojedynczo każdego nowego czujnika IP jest pracochłonne i nie daje możliwości budowania złożonych akcji (alarmów), które polegają na analizie stanu kilku czujników.

Producent termometru IP udostępnił na swojej stronie darmową wersję aplikacji Wix, która umożliwia m.in.

• obserwację pomiarów z kilku urządzeń
• wykreślanie historii pomiarów
• budowanie akcji z prostą logiką warunków
• wysyłanie wiadomości alarmowych via e-mail, SMS

W tej wersji aplikacja Wix nie jest być może szczególnie zaawansowana ale oferowała funkcjonalność, której poszukiwałem. Jeśli ktoś poszukuje lekkiego i prostego w konfiguracji rozwiązania można ją śmiało polecić. Dla bardziej wymagających pozostaje zabawa z oprogramowaniem urządzeń firmy Papouch za pomocą API udostępnionego na stronie producenta.

MG

Tagi: monitoring, urządzenia

Jak dodać obsługę SVN do XAMPPa

XAMPP jest bardzo wygodnym zestawem typu Apache+PHP+MySQL. Moim zdaniem jego przewaga nad podobnymi rozwiązaniami wynika z dopracowanego projektu oraz możliwości instalacji przez rozpakowanie archiwum do katalogu '/opt’. Wykonywanie kopii zapasowych oraz przenoszenie całego serwisu z serwera na serwer jest również bardzo proste, wystarczy bowiem zatrzymać usługę, zrobić kopię (np. za pomocą tar) i przenieść na inny komputer.

XAMPP nie jest jednak pozbawiony drobnych wad. Jedną z nich jest brak wbudowanej obsługi systemu kontroli wersji SVN. Taka właściwość jest bardzo przydatna jeśli chcemy utworzyć np. repozytorium dokumentów za pomocą WebDAV (odpowiedni moduł jest standardowo wbudowany w XAMPP).

Instalację SVN zaczynamy od instalacji odpowiednich pakietów z repozytorium:

apt-get install subversion libapache2-svn

Następnie przygotowywujemy katalog dla repozytorium SVN np. '/var/svn’:

mkdir /var/svn/

Zakładamy pzrykładowy projekt o nazwie test:

svnadmin create --fs-type fsfs /var/svn/test

Potem dodajemy użytkownika (np. marcin) z uprawnieniami do naszego projektu. Dwa pierwsze wiersze kodu poniżej wykonujemy jednorazowo:

rm -f /var/svn/test/conf/passwd
touch /var/svn/test/conf/passwd
htpasswd /var/svn/test/conf/passwd marcin

Tworzymy grupę subversion i ustawiamy uprawnienia dla katalogu '/svn’:

groupadd subversion
chmod -R 777 /var/svn/*

Żeby XAMPP mógł obsłużyć SVN konieczne są dwie biblioteki mod_authz_svn.so oraz mod_dav_svn.so. Możemy je np. skopiować z katalogu Apache, pod warunkiem, że zainstalowaliśmy wcześniej pakiet apache2:

cp /usr/lib/apache2/modules/mod_authz_svn.so /opt/lampp/modules/
cp /usr/lib/apache2/modules/mod_dav_svn.so /opt/lampp/modules/

Teraz możemy wyedytować plik '/opt/lampp/etc/httpd.conf”, żeby najpierw pod linią zawierającą wpis LoadModule ssl_module modules/mod_ssl.so umieścić fragment:

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

a następnie na końcu pliku dodać:

# Subversion repositories

<Location /test>
DAV svn
SVNPath /var/svn/test
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /var/svn/test/conf/passwd
Require valid-user
SSLRequireSSL
</Location>

Po zatrzymaniu i ponownym uruchomieniu XAMPPa, możemy rozpocząć testowanie opisanego rozwiązania.

MG

Tagi: Linux, SVN, XAMPP