Bądź na bieżąco - RSS

Mailcow – instalacja i aktualizacja serwera poczty w Dockerze

27 czerwca, 2026 | Brak Komentarzy | Kategoria: Bez kategorii, Linux, Porady

Mailcow instalacja i aktualizacja serwera poczty w DockerzeMailcow 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: , , , ,

Jak zwiększyć rozmiar dysku maszyny wirtualnej w Proxmox – krok po kroku

25 października, 2025 | Brak Komentarzy | Kategoria: Linux, Porady

Interfejs Proxmox z podświetloną opcją zwiększania rozmiaru dysku w maszynie wirtualnej - minimalistyczna grafika wektorowa

Wprowadzenie

Z biegiem czasu nawet najlepiej zaplanowana maszyna wirtualna może zacząć odczuwać brak przestrzeni dyskowej. Rosnące bazy danych, nowe aplikacje, aktualizacje systemowe czy gromadzone logi – wszystko to powoduje, że konieczne staje się zwiększenie rozmiaru dysku w Proxmox. Na szczęście, dzięki elastyczności Proxmox VE, operacja ta jest prosta i bezpieczna – pod warunkiem, że wykonamy ją poprawnie.

W tym poradniku pokazuję jak zwiększyć rozmiar dysku w Proxmox oraz jak rozszerzyć partycję w systemie Linux, aby w pełni wykorzystać nową przestrzeń.

Zwiększanie rozmiaru dysku w Proxmox przez interfejs webowy

Krok 1: Zaloguj się do panelu Proxmox

  1. Otwórz przeglądarkę i wejdź na adres panelu, np. https://twoj-serwer:8006.
  2. W drzewie po lewej wybierz węzeł (node), a następnie właściwą maszynę wirtualną.

Krok 2: Przejdź do zakładki „Hardware”

W ustawieniach VM wybierz zakładkę Hardware. Zobaczysz listę urządzeń przypisanych do maszyny: karty sieciowe, dyski, itp.

Krok 3: Wybierz dysk do powiększenia

  1. Z listy wybierz odpowiedni dysk wirtualny (np. scsi0, virtio0, sata0).
  2. Kliknij Disk Actions (Działania na dysku) → Resize (Zmień rozmiar).

Krok 4: Zwiększ rozmiar dysku

  1. W oknie dialogowym podaj, o ile GB chcesz zwiększyć dysk (np. 20).
  2. Potwierdź zmianę — Proxmox powiększy plik dysku.

Uwaga: Operacja zwiększania jest jednokierunkowa. Zmniejszanie dysków nie jest wspierane – upewnij się co do docelowego rozmiaru.

Krok 5: Uruchom maszynę wirtualną

Jeśli VM była wyłączona, uruchom ją. Hypervisor widzi już nowy rozmiar, ale system gościa musi rozszerzyć partycję, by wykorzystać dodatkowe miejsce.

Rozszerzanie partycji w systemie Linux

Po zwiększeniu dysku w Proxmox wykonujemy trzy kroki w gościu:

  1. Aktualizacja tablicy partycji,
  2. Rozszerzenie partycji,
  3. Powiększenie systemu plików.

Sprawdź aktualny stan dysku

Zaloguj się do VM (SSH lub konsola Proxmox) i sprawdź dyski:

lsblk

Przykładowy wynik:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda      252:0    0   80G  0 disk
└─vda1   252:1    0   40G  0 part /

Widać, że dysk vda ma 80 GB, ale partycja vda1 wciąż 40 GB.

Aktualizacja tablicy partycji i rozszerzenie partycji

Wygodne narzędzie to growpart (pakiet cloud-guest-utils):

sudo apt update && sudo apt install -y cloud-guest-utils
sudo growpart /dev/vda 1

Powyższe rozszerza partycję 1 na dysku /dev/vda do maksymalnego dostępnego rozmiaru.

Alternatywy: fdisk, parted (patrz niżej).

Powiększenie systemu plików

Dla ext4:

sudo resize2fs /dev/vda1

Dla XFS (zakładając, że / jest na XFS):

sudo xfs_growfs /

Sprawdź efekt:

df -h

Zwiększanie rozmiaru dysku w systemach z LVM

Jeśli system korzysta z LVM (Logical Volume Manager), po rozciągnięciu partycji fizycznej wykonaj:

  1. Aktualizacja PV: 
    sudo pvresize /dev/vda3
  2. Rozszerzenie LV (na cały wolny obszar): 
    sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
  3. Powiększenie systemu plików (ext4): 
    sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

Narzędzia do zarządzania partycjami w Linux

  • fdisk – klasyczny, interaktywny edytor tablicy partycji (MBR/GPT).
  • parted – nowocześniejszy, dobrze radzi sobie z GPT i dużymi dyskami.
  • growpart – szybkie rozszerzanie istniejących partycji (często na VM).
  • lvextend – powiększanie logicznych wolumenów w LVM.

Najczęstsze problemy i rozwiązania

1) Proxmox nie pozwala zwiększyć dysku

  • Sprawdź typ kontrolera (VirtIO/SCSI) oraz wersję Proxmox.
  • W starszych wersjach wymagane było wyłączenie VM przed powiększeniem.

2) Linux nie widzi nowego rozmiaru

  • Wymuś ponowne odczytanie tablicy partycji: 
    sudo partprobe
  • Jeśli to nie pomaga – uruchom VM ponownie.

3) Brak growpart

  • Użyj fdisk:
    1. Usuń i utwórz tę samą partycję z tym samym początkiem, ale większym końcem.
    2. Zapisz zmiany i wykonaj resize2fs lub xfs_growfs.

    Bezpieczeństwo: dane pozostają nienaruszone, o ile początek partycji się nie zmieni.

4) Błąd przy resize2fs

  • Upewnij się, że system plików nie jest zamontowany jako tylko do odczytu.
  • W razie potrzeby skorzystaj z trybu awaryjnego (single-user) lub z partycji ratunkowej.

Najlepsze praktyki

  • Backup przed operacją – szczególnie w środowiskach produkcyjnych.
  • Stopniowe powiększanie – dodawaj przestrzeń w rozsądnych krokach.
  • Dokumentacja zmian – przyda się do audytu i odtwarzania konfiguracji.

Podsumowanie

  1. Zaloguj się do Proxmox → Hardware → Disk Actions → Resize.
  2. Uruchom VM i zaloguj się do systemu gościa.
  3. Rozszerz partycję (growpart, fdisk, parted).
  4. Powiększ system plików (resize2fs lub xfs_growfs).

Po tych krokach Twoja maszyna wirtualna w pełni wykorzysta większy dysk.

G

Tagi: , , , ,

Bezpieczny serwer SFTP w 5 minut? To możliwe z Dockerem i atmoz/sftp!

27 września, 2025 | Brak Komentarzy | Kategoria: Linux, Porady
Serwer SFTP atmoz/sftp

Potrzebujesz szybko uruchomić bezpieczny serwer SFTP w odizolowanym środowisku, bez instalacji dodatkowego oprogramowania na serwerze? Dzięki obrazowi Docker atmoz/sftp jest to możliwe w kilka minut. W tym artykule pokażemy, jak skonfigurować taki serwer krok po kroku oraz jak dostosować go do różnych scenariuszy w praktyce.

Dlaczego warto wybrać atmoz/sftp?

Obraz atmoz/sftp to lekka, gotowa do użycia implementacja serwera SFTP, która działa w kontenerze Dockera. Rozwiązuje typowe problemy administratorów:

  • Izolacja: serwer SFTP działa w kontenerze, minimalizując ryzyko wpływu na system hosta.
  • Łatwa konfiguracja: wystarczy kilka zmiennych środowiskowych, by uruchomić gotowy serwer.
  • Bezpieczeństwo: dostęp oparty na SSH i możliwość ograniczenia użytkowników do wybranych katalogów.
  • Szybkość wdrożenia: w kilka minut można uruchomić działający serwer, bez kompilacji czy skomplikowanej konfiguracji.

Instalacja Dockera

Jeśli nie masz jeszcze zainstalowanego Dockera, możesz to zrobić w systemach Linux za pomocą poleceń:

sudo apt update 
sudo apt install docker.io -y 
sudo systemctl enable --now docker

Sprawdź, czy Docker działa poprawnie:

docker --version

Uruchomienie podstawowego serwera SFTP

Poniższe polecenie tworzy prosty serwer SFTP z jednym użytkownikiem:

docker run -p 22:22 -d \ 
-v /host/data:/home/user/upload \ 
-e SFTP_USERS="user:password:::upload" \ 
atmoz/sftp

Wyjaśnienie parametrów:

  • -p 22:22 – mapowanie portu kontenera na port hosta.
  • -v /host/data:/home/user/upload – montowanie katalogu z hosta jako przestrzeni dostępnej dla użytkownika.
  • -e SFTP_USERS – definiuje użytkowników w formacie login:hasło:uid:gid:katalog.

Praktyczne scenariusze konfiguracji

1. Jeden użytkownik z dostępem do katalogu

docker run -p 22:22 -d \ 
-v /srv/sftp/data:/home/alice/data \ 
-e SFTP_USERS="alice:SuperHaslo:::data" \ 
atmoz/sftp

Użytkownik alice może logować się i przesyłać pliki wyłącznie do katalogu /home/alice/data.

2. Wielu użytkowników z różnymi katalogami

docker run -p 22:22 -d \ 
-v /srv/sftp/alice:/home/alice/data \ 
-v /srv/sftp/bob:/home/bob/docs \ 
-e SFTP_USERS="alice:HasloAlice:::data bob:HasloBob:::docs" \ 
atmoz/sftp

Każdy użytkownik ma własny katalog i jest w nim ograniczony (tzw. chroot).

3. Integracja z aplikacją – katalog współdzielony

docker run -p 2222:22 -d \ 
-v /srv/app/uploads:/home/client/shared \ 
-e SFTP_USERS="client:TrudneHaslo:::shared" \ 
--name sftp-server \ 
atmoz/sftp

Taki scenariusz jest często używany do automatycznej wymiany danych między aplikacjami a partnerami biznesowymi.

Bezpieczeństwo i dobre praktyki

  • Używaj silnych haseł lub – lepiej – kluczy SSH.
  • Uruchamiaj kontener z ograniczonymi uprawnieniami i wyłącz dostęp roota.
  • Regularnie aktualizuj obraz atmoz/sftp do najnowszej wersji.
  • Monitoruj logi kontenera za pomocą docker logs.

Zalety wykorzystania Dockera i atmoz/sftp

Uruchomienie serwera SFTP w kontenerze Dockera pozwala na:

  • Szybkie wdrożenie: pełna konfiguracja w kilka minut.
  • Łatwą migrację: kontener można przenieść na inny host bez zmian w konfiguracji.
  • Bezpieczeństwo: odizolowane środowisko minimalizuje ryzyko podatności w systemie hosta.
  • Skalowalność: łatwo uruchomić wiele instancji dla różnych klientów.

Podsumowanie

Obraz atmoz/sftp to idealne rozwiązanie, jeśli potrzebujesz szybko uruchomić bezpieczny serwer SFTP w odizolowanym i łatwym do zarządzania środowisku. Dzięki Dockerowi wdrożenie jest proste, a konfiguracja elastyczna – od prostych jednoużytkownikowych scenariuszy po integrację z aplikacjami biznesowymi.

G

Tagi: , , , ,

Problem z połączeniem HTTP/HTTPS w iDRAC9

1 lipca, 2025 | Brak Komentarzy | Kategoria: Porady
Problem HTTP HTTPS iDRAC9

Wstęp

Wersja firmware 5.10.00.00 dla iDRAC9 przyniosła istotne zmiany w obsłudze protokołów HTTP i HTTPS. Niestety, u części administratorów aktualizacja ta spowodowała niespodziewane błędy połączenia przez FQDN. W tym artykule przedstawiamy, na czym polega problem oraz jak go skutecznie rozwiązać.

Opis problemu technicznego

Po zainstalowaniu firmware w wersji 5.10.00.00 w iDRAC9, wielu użytkowników zauważyło, że nie mogą już łączyć się z interfejsem iDRAC używając pełnej nazwy domenowej (FQDN) przez protokoły HTTP lub HTTPS.

Objawy

  • Brak dostępu do iDRAC przez FQDN (np. https://idrac.serwer.local)
  • Połączenia przez adres IP działają poprawnie
  • W logach brak szczegółowych komunikatów o błędach

Przyczyna

Dell wprowadził aktualizację, która modyfikuje sposób, w jaki iDRAC obsługuje nagłówki żądań HTTP/HTTPS przy użyciu FQDN. Wymagany jest teraz zgodny nagłówek Host zgodny z nazwą DNS, a nie wszystkie konfiguracje lokalne to zapewniają.

Rozwiązanie krok po kroku

Poniżej znajdziesz sposób rozwiązania problemu zgodnie z zaleceniami firmy Dell:

  1. Zaloguj się do iDRAC używając adresu IP (np. https://192.168.0.100)
  2. Przejdź do sekcji: Configuration > Network > Services
  3. W sekcji Web Server, znajdź opcję Enable HTTP host header validation
  4. Odznacz tę opcję
  5. Kliknij Apply i zrestartuj interfejs iDRAC (lub wykonaj pełny reboot serwera, jeśli wymagane)
  6. Po restarcie, przetestuj połączenie przez FQDN

Dodatkowe porady

  • Jeżeli masz wiele serwerów Dell z iDRAC9, warto zautomatyzować tę zmianę poprzez Redfish API lub RACADM.
  • Upewnij się, że wpisy DNS (zarówno A jak i PTR) dla hosta iDRAC są poprawne.
  • Rozważ aktualizację do nowszej wersji firmware, jeśli jest dostępna – może zawierać poprawki rozszerzające kompatybilność.

Podsumowanie

Problem z połączeniem HTTP/HTTPS przez FQDN w iDRAC9 firmware 5.10.00.00 wynika z wprowadzonego wymogu walidacji nagłówka Host. Na szczęście, jego wyłączenie w panelu iDRAC pozwala przywrócić prawidłowe działanie. Zalecamy również monitorowanie aktualizacji iDRAC oraz regularne przeglądanie dokumentacji producenta.

Powiązane artykuły

GR

Tagi: , ,

Jak działa serwerownia? Jeden obraz wart tysiąca słów

26 kwietnia, 2025 | Brak Komentarzy | Kategoria: Porady

Czasem jedno spojrzenie na dobrze przygotowaną grafikę pozwala zrozumieć więcej niż długa lektura. Poniższy obrazek przedstawia podstawowy schemat działania serwerowni – od patch panelu, przez switch i router, aż po serwer.

serwerownia schemat

  • Patch Panel — punkt centralny, do którego doprowadzone są kable z różnych urządzeń sieciowych. Ułatwia zarządzanie okablowaniem.
  • Switch — przełącznik, który przekazuje dane między urządzeniami w sieci lokalnej (LAN).
  • Router — zarządza ruchem sieciowym pomiędzy siecią lokalną a Internetem.
  • Server — główny punkt, który przechowuje dane, udostępnia zasoby oraz obsługuje aplikacje.

Dzięki temu prostemu układowi możliwe jest sprawne zarządzanie nawet dużą ilością urządzeń w firmie. Obraz świetnie ilustruje podstawowe zasady organizacji nowoczesnej sieci IT.

Jeśli dopiero zaczynasz swoją przygodę z serwerowniami lub chcesz uporządkować istniejącą infrastrukturę, ten schemat może być świetnym punktem wyjścia!

G

Tagi: , , ,

Błąd MEM7114 w serwerach Dell – przyczyny i skuteczne rozwiązania

29 marca, 2025 | Brak Komentarzy | Kategoria: Porady


błąd MEM7114Czym jest błąd MEM7114?

Błąd MEM7114 to krytyczne zdarzenie diagnostyczne, które występuje w serwerach Dell, najczęściej z serii PowerEdge. Informuje on o poważnym problemie sprzętowym w module pamięci RAM. Typowy komunikat z iDRAC lub Lifecycle Log wygląda tak:

A critical diagnostic event occurred in the memory device at [slot]. Contact your service provider for assistance in replacing the device. (Extended ID: 0x4E41)

Główne przyczyny błędu MEM7114

1. Uszkodzenie modułu pamięci RAM

Najczęściej błąd spowodowany jest fizycznym uszkodzeniem jednego z modułów RAM. Problem może pojawić się w slotach takich jak B3 czy A6 z powodu starzenia się komponentów, wad fabrycznych lub intensywnego użytkowania.

2. Mieszanie typów pamięci

Stosowanie różnych producentów, modeli lub częstotliwości pamięci w jednym kanale może powodować konflikty i błędy odczytu.

3. Problemy z kontrolerem pamięci

Rzadziej przyczyną są błędy w kontrolerze pamięci, które mogą być związane z przestarzałym firmware lub BIOS-em.

4. Wysoka temperatura pracy

Brak odpowiedniego chłodzenia lub kurz wewnątrz obudowy może powodować przegrzewanie i niestabilność pracy modułów RAM.

Jak rozwiązać błąd MEM7114?

1. Zidentyfikuj wadliwy slot

Wejdź do panelu iDRAC i przejdź do Hardware → Memory, aby zlokalizować uszkodzony slot (np. B3, A6).

2. Zrestartuj serwer

Sprawdź, czy błąd się powtarza po ponownym uruchomieniu. Jeśli tak – przejdź do kolejnych kroków.

3. Wymień moduł RAM

Zaleca się wymianę całego kanału DIMM (np. B3 i B4), aby zapewnić stabilność działania systemu.

4. Zaktualizuj BIOS i iDRAC

Pobierz i zainstaluj najnowsze wersje BIOS, firmware iDRAC oraz Lifecycle Controller ze strony Dell Support.

5. Skontaktuj się z pomocą techniczną Dell

Jeśli serwer objęty jest gwarancją – przygotuj zrzuty logów i zgłoś błąd MEM7114 do Dell Support.

Czy błąd MEM7114 jest niebezpieczny?

Tak – jest to sygnał, że serwer może w każdej chwili doświadczyć awarii systemu lub utraty danych. Szybka reakcja jest kluczowa dla zachowania ciągłości działania.

Podsumowanie

Błąd MEM7114 w serwerach Dell wymaga poważnego potraktowania. Najczęściej wiąże się z uszkodzeniem pamięci RAM, a jego ignorowanie może skutkować poważnymi konsekwencjami. Zalecana jest natychmiastowa diagnostyka, aktualizacja firmware oraz wymiana wadliwego modułu.

G

Tagi: , ,

Jak korzystać z funkcji iDRAC Direct na serwerach Dell PowerEdge

28 grudnia, 2024 | Brak Komentarzy | Kategoria: Porady
iDRAC Direct

Zarządzanie serwerami jest kluczowym elementem wśparcia infrastruktury IT. Jednym z rozwiązań oferowanych przez Dell Technologies jest funkcja iDRAC Direct na serwerach Dell PowerEdge. W tym artykule dowiesz się, czym jest iDRAC Direct, jakie są jej korzyści oraz jak ją skonfigurować i wykorzystać w codziennej pracy.

Czym jest iDRAC Direct?

iDRAC (Integrated Dell Remote Access Controller) to narzędzie umożliwiające zdalne zarządzanie serwerami Dell PowerEdge. Funkcja iDRAC Direct pozwala na bezpośrednie połączenie z iDRAC za pomocą kabla USB lub Ethernet. Dzięki temu administratorzy IT mogą łatwo konfigurować, monitorować i zarządzać serwerami, nawet bez dostępu do sieci firmowej.

Korzyści wynikające z użycia iDRAC Direct

Jeśli interesują Cię inne sposoby zarządzania serwerami, zapoznaj się z naszym artykułem o funkcjach konsoli OpenManage na serwerach Dell PowerEdge.

  1. Bezpośrednie połączenie – umożliwia szybki dostęp do iDRAC bez potrzeby korzystania z sieci korporacyjnej.
  2. Łatwa konfiguracja – proste połączenie za pomocą standardowego kabla USB lub Ethernet.
  3. Oszczędność czasu – minimalizuje czas potrzebny na rozwiązywanie problemów i konfigurację serwera.
  4. Bezpieczeństwo – brak konieczności narażania danych na ryzyko w otwartej sieci.

Jak skonfigurować iDRAC Direct?

Optymalna konfiguracja iDRAC Direct, czyli funkcji pozwalającej na bezpośrednie zarządzanie serwerami, wymaga wykonania kilku prostych kroków. Dowiedz się, jak to zrobić i dlaczego konfiguracja iDRAC Direct może znacznie usprawnić Twoją pracę.

Aby skonfigurować funkcję iDRAC Direct, wykonaj poniższe kroki:

  1. Podłącz kabel:
    • Użyj kabla USB lub Ethernet, aby połączyć komputer z portem iDRAC Direct na serwerze Dell PowerEdge.
  2. Zainstaluj sterowniki:
    • Na komputerze upewnij się, że masz zainstalowane wymagane sterowniki iDRAC. Możesz je pobrać z oficjalnej strony Dell.
  3. Skonfiguruj połączenie sieciowe:
    • Jeśli korzystasz z kabla Ethernet, przypisz statyczny adres IP do karty sieciowej komputera zgodnie z dokumentacją serwera.
    • Dla połączenia USB system powinien automatycznie wykryć urządzenie jako kartę sieciową.
  4. Uzyskaj dostęp do interfejsu iDRAC:
    • Otwórz przeglądarkę internetową i wpisz adres IP iDRAC (np. 169.254.0.1 dla połączenia USB).
    • Zaloguj się używając danych uwierzytelniających iDRAC.

Przykłady zastosowań iDRAC Direct

  • Rozwiązywanie problemów: szybkie diagnozowanie błędów serwera bez potrzeby jego fizycznego demontażu.
  • Aktualizacja oprogramowania: łatwe instalowanie aktualizacji BIOS i firmware.
  • Konfiguracja początkowa: szybkie ustawienie parametrów serwera przed wprowadzeniem go do sieci.

Najczęstsze pytania dotyczące iDRAC Direct

  1. Czy iDRAC Direct wymaga dodatkowego oprogramowania?
    • Połączenie USB zazwyczaj nie wymaga dodatkowego oprogramowania, ale dla Ethernet może być konieczne przypisanie statycznego adresu IP.
  2. Czy można używać iDRAC Direct równocześnie z innymi metodami dostępu?
    • Tak, iDRAC Direct działa niezależnie od innych metod dostępu, takich jak konsola webowa iDRAC czy interfejs Redfish.
  3. Czy iDRAC Direct jest dostępny na wszystkich serwerach PowerEdge?
    • Funkcja ta jest dostępna w większości modeli Dell PowerEdge, jednak zaleca się sprawdzenie dokumentacji konkretnego serwera.

Podsumowanie

Funkcja iDRAC Direct na serwerach Dell PowerEdge to potężne narzędzie, które znacząco ułatwia zarządzanie infrastrukturą IT. Dzięki możliwości bezpośredniego połączenia administratorzy mogą szybko i bezpiecznie diagnozować problemy, konfigurować serwery oraz instalować aktualizacje. To idealne rozwiązanie dla firm, które stawiają na efektywność i bezpieczeństwo swoich zasobów IT.

Jeśli chcesz dowiedzieć się więcej o funkcji iDRAC Direct, odwiedź oficjalną stronę wsparcia Dell.

G

Tagi: , , ,

vCenter Converter powraca!

27 listopada, 2022 | Brak Komentarzy | Kategoria: Felieton, Linux, Windows
vCenter Converter

VMware ogłasza powrót jednego z najpopularniejszych produktów w katalogu – vCenter Converter. Wydano nową i ulepszoną wersję produktu, kompatybilną z vSphere 7.0 i ESXi 7.0. Opublikowana wersja koncentruje się głównie na poprawie stabilności i standardów bezpieczeństwa Konwertera oraz zachowaniu istniejącej funkcjonalności.

VMware vCenter Converter zachęca do wysłania informacji o chęci dołączenia do programu vCenter Converter Beta. Można skorzystać z tej możliwości, aby wpływać na przyszły kierunek rozwoju produktu. Jeśli nie masz dostępu do społeczności Beta, wystarczy, że odwiedzisz stronę rejestracji vCenter Converter BETA i przejdziesz do wypełnienia oraz wysłania formularza.

vCenter Converter jest bezpłatnym narzędziem zapewniającym możliwość konwersji maszyn wirtualnych działających na hiperwizorach innych dostawców oraz maszyn fizycznych na maszyny wirtualne VMware. Mowa wersja vCenter Converter obsługuje konwersję rozwiązań opartych na MS Hyper-V, konwersję pomiędzy formatami wirtualnymi VMware (Workstation, Fusion) oraz rekonfigurację maszyn wirtualnych VMware. vCenter Converter wspiera wirtualne stacje robocze działające pod kontrolą systemów Windows, Linux Ubuntu, CentOS, Red Hat Enterprise Linux.

Kolejne wydania będą wzbogacać listę obsługiwanych hyperwizorów, wersji vSphere, systemów operacyjnych i wirtualnych wersji sprzętu.

Link do oryginalnego komunikatu: https://blogs.vmware.com/code/2022/09/15/vcenter-converter-is-back/

MG

Tagi: , , , ,

Gmail SPF – jak ułatwić sobie życie

27 marca, 2022 | Brak Komentarzy | Kategoria: Porady
Gmail i rekord SPF

Jak powiadają rasowi sysadmini nie poznał życia kto nie administrował serwerem poczty – niezależnie czy sam czy za pomocą dużego dostawcy – wszędzie czekają pułapki jak chociażby rekord Gmail SPF. Całkiem niedawno oznaczało to budowanie serwera od podstaw. Można w tym celu bawić się Linuksem i rozwiązaniami typu iRedMail, które zdecydowanie polecam jako wieloletni użytkownik. Nie ma przeszkód aby bardzo ułatwić sobie zadanie i w oparciu o kontenery Dockera zainstalować mailcow. Można wreszcie skorzystać z Microsoft Exchange. Dla każdego coś się znajdzie.

Po instalacji serwera pocztowego dla wybranej domeny trzeba skonfigurować serwer DNS. Oprócz obligatoryjnych rekordów MX wskazujących podstawowy serwer pocztowy a także zapasowe jeśli jest taka potrzeba i możliwość warto pamiętać o kilku dodatkowych. We współczesnym świecie liczą się wszelkiego rodzaju zabezpieczenia.

Rekordem który chciałbym krótko opisać jest TXT pozwalający na zdefiniowanie protokołu SPF – Sender Policy Framework. Obecnie wiele serwerów sprawdza jego wartość i nie pozwala przyjąć wiadomości w przypadku błędów bądź braku tego wpisu. Generalnie nie jest to specjalnie trudna rzecz a w sieci można znaleźć dużo poradników na ten temat, czy nawet generatorów znacznie upraszczających sprawę.

Co jednak zrobić gdy zdecydowaliśmy się na skorzystanie z dużego dostawcy usług a nie budowanie własnego serwera? Czy mocny gracz na rynku zawsze będzie pamiętał o wszystkich szczegółach? W kontekście ustawień DNS niekoniecznie. Zwłaszcza jeżeli serwer nazw nie został zrealizowany za pomocą jego zasobów. Weźmy jako przykład usługi pocztowe Google.

Samo wykupienie skrzynek pocztowych Gmail dla naszej domeny firmowej lub jakiejkolwiek innej nie załatwi nam wspomnianych wpisów DNS, w szczególności Gmail SPF. Może się wydawać, że jest to dosyć niespotykany scenariusz użycia. W rzeczywistości jednak nierzadko firma posiada najpierw własny serwer pocztowy i własny serwer DNS a potem przenosi tylko usługę email na zewnątrz. Jeśli mamy do czynienia z taką sytuacją należy pamiętać aby zdefiniować koniecznie rekord TXT postaci

v=spf1 include:_spf.google.com ~all

Aż tyle i tylko tyle…. aby nie otrzymywać niespodziewanych telefonów od użytkowników z uwagami typu ”moja poczta nie dochodzi” a przecież o to w praktyce chodzi 🙂

MG

Tagi: , ,

VMware, converter, 97% error

28 listopada, 2021 | Brak Komentarzy | Kategoria: Linux, Porady
VMware

Wirtualizacja w wydaniu VMware jest bardzo popularnym rozwiązaniem. Żeby uruchomić pełnoprawny serwer z maszynami wirtualnymi wystarczy średniej klasy sprzęt oraz konto na platformie VMware. Oprogramowanie ESXi (co prawda w ograniczeniami, które dotyczą przede wszystkim limitu rdzeni na jednostkę) jest dostępne jako wersja ewaluacyjna do pobrania. Wygodny interfejs webowy pozwala nawet niezaawansowanemu użytkownikowi na zarządzanie swoim środowiskiem.

Gdy przekonamy się do zalet wirtualizacji może pojawić się konieczność przeniesienia fizycznych serwerów do Vmware. Również w tym przypadku firma udostępnia narzędzie Vmware Standalone Converter (VCS), aby za jego pomocą automatycznie przeprowadzić proces migracji. I tutaj zaczynają się schody. Wspomniana aplikacja, która adresowana jest dla systemów Windows jest po prostu przestarzała. Owszem obsługuje większość systemów operacyjnych, ale nie wszystkie do końca prawidłowo.

Pierwsze kłopoty pojawiają się w momencie konwersji systemów linuksowych z macierzą RAID zrealizowaną programowo. Ze względu na ogólnodostępne informacje na ten temat nie skupie się dalej na tym problemie. Następne w przypadku nowszych wersji Linuksów. W artykule opisuje proces na przykładzie Debiana w wersji 10. VSC nie potrafi sobie poradzić z przeniesieniem GRUB, czyli zainstalowaniem bootloadera. Konwersja zatrzymuje się na 97% i pojawia się komunikat o błędzie.

Jest on mylący ponieważ sugeruje nieukończenie konwersji, która w rzeczywistości dobiegła do końca etapu klonowania danych i jedyną operacją niesfinalizowaną jest wspomniana wcześniej instalacja GRUB.

Możemy (a raczej powinniśmy) ręcznie naprawić sytuację. Na hoście maszyn wirtualnych wyszukujemy zduplikowany serwer (w tym przypadku jego kopie). Następnie edytujemy jego ustawienia i wskazujemy obraz ISO z wersją instalacyjną Debian 10 jako źródło dla danych w napędzie DVD. Trzeba jednak pamiętać o włączeniu opóźnienia w bootowaniu systemu (opcja ukryta w menu Edit) tak aby możliwe było wyświetlenie menu wyboru źródła systemu za pomocą klawisza ESC podczas uruchamiania maszyny.

Po starcie systemu z płyty instalacyjnej wybieramy Rescue Mode. Następnie powinniśmy uruchomić konsolę tekstową i wywołać polecenie blkid. Jest to konieczne, gdyż musimy poznać nowe identyfikatory dysków twardych UUID, które zmieniają się podczas klonowania.

Następny krok to pracowita edycja pliku /etc/fstab, aby poprawić identyfikatory, o których wspomniałem powyżej. Możemy to zrobić za pomocą edytora vi lub nano, w zależności od tego, który będzie dostępny.

W ostatnim kroku korzystamy z dwóch komend, instalując (i naprawiając przy okazji) GRUB:

grub-install /dev/sda
update-grub

W miejsce przykładowej /dev/sda powinniśmy wstawić docelową partycję dla bootloadera (prawdopodobnie w 90% przypadków nie trzeba tego zmieniać).

Ostatnią czynnością będzie ręczne zrestartowanie maszyny wirtualnej – korzystamy z funkcji ESXi. Przy odrobinie szczęścia okaże się, że jednak maszyna została przeniesiona prawidłowo.

MG

Tagi: , , , ,
« Starsze Wpisy