Bądź na bieżąco - RSS

Dell R210 – instalacja sterownika sieciowego a Debian 9.6

Grudzień 15th, 2018 | Brak Komentarzy | Kategoria: Linux, Porady

Rackowe serwery firmy Dell, nawet te z najniższej serii jak Dell PowerEdge R210 II, wyśmienicie nadają się do tworzenia serwisów internetowych. Mam na myśli usługi takie jak WWW czy FTP. Nie są to super wydajne maszyny do obsługi milionów zgłoszeń w ciągu godziny, ale jako hosty dla małych i średnich przedsiębiorstw jak najbardziej znajdą zastosowanie.

Dell R210 instalacja Debiana

Niedawno miałem okazję przygotowywać taki komputer instalując ostatnią wersję Linuxa – Debian Stretch w wersji 9.6. Ponieważ bardzo lubię prostotę i minimalizm dlatego korzystam zazwyczaj z instalacji w wersji sieciowej, tak aby nie zaśmiecać systemu operacyjnego zbędnymi pakietami. Jak nazwa wskazuje aby wszystko udało się bez problemu potrzebna jest sieć, a w zasadzie działająca karta sieciowa, czyli prawidłowo zainstalowany sterownik. Pomimo iż Dell w serwerach R210 raczej na pewno korzysta ze standardowych rozwiązań – czytaj popularnych kart sieciowych (zbudowanych w oparciu o rozpowszechnione chipsety), to jak się okazuje społeczność Debiana tak bardzo dba o używanie otwartych sterowników, że nie zawsze wychodzi to użytkownikom na dobre.

W opisywanym przypadku serwer wyposażony jest w kartę Broadcom NetXtremeII z dwoma interfejsami sieciowymi. Instalacja pozornie przebiega bez problemów. Karty sieciowe są wykrywane poprawnie. Debian korzysta z wbudowanego sterownika (w poprzednich wersjach trzeba było dodawać zenętrzny zamknięty pakiet oprogramowania). Instalator przechodzi do automatycznej konfiguracji przez DHCP i… naszym oczom ukazuje się komunikat o błędzie. Wygląda to tak jakby winne było wszystko, włącznie z serwerem DHCP, tylko nie instalator Debiana. A prawda jest zupełnie inna.

Okazuje się, że kod sterownika dołączonego standardowo do instalatora zawiera błędy. Karta sieciowa działa, ale nie do końca. W tej sytuacji trzeba wspomóc się kilkoma sztuczkami i dodać ręcznie właściwy sterownik.

  • Po pierwsze pobieramy właściwy (zamknięty) pakiet ze strony https://packages.debian.org/stretch/firmware-bnx2.
  • Następnie za pomocą pendrive’a USB przenosimy go na przygotowywany serwer:
    • uruchamiamy instalator Debiana w wersji tekstowej
    • przechodzimy przez pierwsze kroki instalacji pamiętając, że zanim instalator zacznie wykrywać sprzęt musimy wgrać zamknięty sterownik z USB
    • gdy instalator zatrzyma się na jednym z pytań konfiguracyjnych wciskamy ALT+F2 przechodząc do konsoli tekstowej
    • tworzymy tymczasowy punkt montowania i montujemy pendrive
~$ mkdir /tmp/driver
~$ mount /dev/sda1 /tmp/driver
  • Kolejnym krokiem będzie instalacja właściwego sterownika
~$ apt-get install /tmp/driver/firmware-bnx2_xxx-x_all.deb
  • Ostatnią czynnością jest wciśnięcie kombinacji ALT+F1 co pozwoli wrócic do okienkowej wersji instalatora
  • Tym razem podczas wykrywania sprzętu zostanie zainstalowany odpowiednie oprogramowanie

Dalej wykonujemy standardowe czynności, zgodnie z typową instalacją, ciesząc się działającym połączeniem sieciowym.

MG

Tagi: , , , ,

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

Listopad 18th, 2018 | Możliwość komentowania PHP w dwóch wersjach jednocześnie a serwer Apache została wyłączona | Kategoria: Linux, Porady

PHP

Dla każdego administratora, który przygotowywał serwis www pojęcie LAMP nie jest obce. W skrócie oznacza, że udało nam się zainstalować trzy podstawowe serwisy tj. Apache, PHP oraz silnik bazy danych np. MySQL. Dzisiaj chciałem skupić się na obsłudze języka PHP. Obecnie ostatnią dostępną wersją jest 7.2. Domyślnie taką właśnie powinniśmy instalować. Jednak jak wiadomo rzeczywistość jest nieco bardziej skomplikowana i na pewno spotkamy się z użytkownikami, którzy z różnych względów bedą chcieli używać starszych wersji jak np. 5.6. Osobiście zalecam jak najszybsze przechodzenie do wersji najnowszych, głównie ze względu na bezpieczeństwo, trzeba jednak pamiętać o różnicach w implemetacji pomiędzy wspomnianymi wersjami, co z kolei przekłada się np. na brak niektórych funkcji, czyli na brak tak zwanej kompatybilności wstecznej. Jest to istotne przy instalacji oprogramowania webowego, które opierając się o starsze wersje PHP może nie funkcjonować w nowszym środowisku. Zatem scenariusz naszej instalacji powinien wyglądać tak, że domyślnie włączony jest PHP7 ale zawsze mamy możliwość cofnięcia wersji dla wybranych serwisów. I o tym właśnie jest dzisiejszy wpis.

Na początek załóżmy, że tradycyjnie używamy Debian Linux w wersji 9.5 Stretch. Ponieważ nie skupiamy się w tym artykule na instalacji samego Apache oraz MySQL (co z resztą jest szeroko opisywane w sieci) przejdźmy od razu do instalacji PHP. Zaczynamy od następujących poleceń:

$ apt-get install ca-certificates apt-transport-https 
$ wget -q https://packages.sury.org/php/apt.gpg -O- →
| sudo apt-key add -
$ echo "deb https://packages.sury.org/php/ stretch main" →
| sudo tee /etc/apt/sources.list.d/php.list

Aby wykorzystywać różne wersje PHP jednocześnie będziemy potrzebowali dwóch interfejsów – PHP FPM oraz FastCGI:

$ apt-get update
$ apt-get install php5.6 php5.6-fpm
$ apt-get install php7.2 php7.2-fpm

I w ten sposób zainstalujemy jednocześnie wersje 5.6 i 7.2. Oczywiście możemy tak zrobić z różnymi wydaniami, to tylko przykład.

Przechodzimy do konfiguracji samego Apache. Przede wszystkim dodajemy wspomniany interfejs:

$ apt-get install libapache2-mod-fcgid

Nastepnie włączamy następujące moduły:

$ a2enmod actions cgid alias proxy_fcgi

I to już już wszystko. Naprawdę możemy korzystać z dwóch bibliotek 🙂 . Niemniej chciałbym zasugerować włączenie domyślnie tej nanowszej. Czyli w konfiguracji głównej hosta wirtualnego (chodzi o plik 000-default.conf) dodanie następujących linijek:

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php7.2-fpm.sock|fcgi://localhost/"
</FilesMatch>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Tym razem, po ponownym uruchomieniu Apache możmy być pewni, że domyślnie używamy najnowszej zainstalowanej wersji:

$ systemctl restart apache2

Jeśli jednak któryś z użytkowników serwera będzie chciał cofnąć się z różnych względów do wersji starszej to wystarczy, że w katalogu głównym swojego serwisu utworzy tekstowy plik .htaccess i doda do niego poniższą zawartość:

<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php5.6-fpm.sock|fcgi://localhost/"
</FilesMatch>

To naprawdę działa.

MG

Tagi: , , , ,

Logcheck, systemd – zaśmiecone logi

Kwiecień 21st, 2018 | Brak Komentarzy | Kategoria: Linux, Porady

logcheck, systemdWśród administratorów Linuksa, od wielu lat prym wiedzie mały ale bardzo poręczny pakiet logcheck. Narzędzie to wykonuje niezwykle żmudną, ale bardzo potrzebną pracę, polegającą na przeszukiwaniu logów systemowych pod kątem wszelkich anomalii. Skonfigurowane według standardowych zaleceń potrafi być bardzo krzykliwe zasypując nas stosem maili informujących w wykrytych, podejrzanych odstępstwach od prawidłowej pracy systemu operacyjnego. Co prawda zwalnia nas ono z konieczności codziennego przeglądania raportów o systemie, jednak nawet najbardziej usłużne narzędzie będzie bezlitosne jeśli nie zajmiemy się filtrowaniem generowanych komunikatów.

W przypadku logcheck cała sztuka polega na odpowiednim definiowaniu filtrów w katalogach:

/etc/logcheck/ignore.d.{paranoid;server;workstation}

Zazwyczaj wystarczy korzystać ze ścieżki /etc/logcheck/ignore.d.server, wpisując w plikach testowych wyrażenia regularne. logcheck porównuje wyrażenie z wyszukanym rezultatem i w przypadku zgodności zapobiega generowaniu monitu. Budowanie wyrażeń regularnych samo w sobie jest małą sztuką. Czasami niektórzy wpisują po prostu wzorce na sztywno np.

Reloading web server: apache2.

co zapobiegnie periodycznym informacjom o restartowaniu naszego serwera www. Inni zaś potrafią zbudować naprawde wyrafinowane wyrażenia.

W wydaniu 8 Debiana o nazwie Jessie pojawił się jednak pewien błąd, który bardzo utrudnia życie. Dotyczy właśnie filtrowania za pomocą logcheck i demona systemowego systemd. Dotąd nie było żadnych problemów, jednak właśnie Jessie zaczął zasypywać nas komunikatami, które wydają się nie mieć końca. Co ważniejsze żadne filtry wpisane na sztywno nie pomagają, bowiem reguły systemd są bardzo obszerne i groźne byłoby wycięcie informacji, które mogą okazać się istotne z punktu widzienia administrowania naszym serwerem.

W tym przypadku z pomocą przychodzi strona Debian Wiki i gotowy zestaw wyrażeń przygotowanych przez jej użytkowników. Wystarczy skopiować je do pliku tekstowego we wspomnianym wcześniej katalogu i gotowe. Wszytskie aktualne reguły można pobrać, a w zasadzie skopiować pod adresem:

https://wiki.debian.org/systemd/logcheck

Zapraszam 🙂

MG

Tagi: , ,

Macierz RAID1 i problemy z GRUB2

Luty 18th, 2017 | Brak Komentarzy | Kategoria: Linux, Porady

RAID1Powszechnie wiadomo, że nie jest szczególnie trudno zbudować macierz programową RAID1 używając systemu operacyjnego Debian. Przy instalacji jest to jedna z najczęściej wybieranych opcji, w celu zabezpieczenia się przed niespodziewaną utratą danych. Większość tak zwanych software’owych raidów, oferowanych przez producentów płyt głównych, opiera się właśnie o pakiet mdadm, czyli w zasadzie jest to dokładnie takie samo rozwiązanie jak w przypadku zwyczajnej instalacji. Przyznam się, że często wyłączam raid na płycie głównej, bo wolę panować do końca nad systemem, i po prostu instaluję oprogramowanie ręcznie. I wszystko było by dobrze gdyby nie jeden, nie zrozumiały przeze mnie fakt. Otóż do tej pory, przy składaniu raidu, instalator modyfikuje konfigurację bootloadera grub tylko dla pierwszego dysku (np. /dev/sda). Co oznacza, że w przypadku uszkodzenia drugiego dysku (np. /dev/sdb) twardego komputer przeżyje awarię, jednak jeżeli zostanie uszkodzony pierwszy dysk można mieć sporo kłopotów z jego uruchomieniem. Internet jest pełen takich historii, jak również mnóstwo jest porad jak zapobiegać lub usunąć ten błąd. Ja gorąco będę namawiał do przygotowania się zawczasu i skonfigurowania prawidłowo systemu na samym początku. W tym celu zaraz po instalacji systemy wystarczy skorzystać z trzech prostych poleceń (wydawanych z konta root)):

mv /boot/grub/device.map /boot/grub/device.map.old
grub-mkdevicemap
update-grub2 && grub-install /dev/sda && grub-install /dev/sd

Czasami naprawdę niewiele wystarczy, żeby zabezpieczyć się na przyszłość.

MG

Tagi: , , , ,

Debian Jessie – sshd i obsługa PAM

Styczeń 21st, 2017 | Brak Komentarzy | Kategoria: Linux, Porady

Debian PAMW najnowszej wersji Debiana (Jessie), nie wiedzieć skąd pojawił się błąd związany z obsługą sesji SSH. Do tej pory, wykonując typowe prace administracyjne takie jak aktualizacje, w szczególności wymianę jądra systemu na nowszą wersję, nie było żadnego problemu kiedy trzeba było wydać polecenie reboot. Serwer prawidłowo kończył sesję SSH i po krótkiej chwili można było znowu się połączyć. O ile oczywiście dał radę podnieść się po naszych zabiegach. Tym razem jest inaczej. Krótko mówiąć sesja SSH zawiesza się i bez siłowego zamknięcia terminala nie ma mowy o kontynuowaniu pracy. Związane jest to z obsługą biblioteki PAM. Żeby pozbyć się opisanej niedogodności konieczna jest instalacja dodatkowych bibliotek, które nie są dostarczane w standarowej wersji:

apt-get install libpam-systemd dbus

Na tym nie koniec. Musimy upewnić się, że nasz daemon sshd ma włączoną obsługę PAM. Tak inaczej wystarczy wydać polecenie:

 grep -i UsePAM /etc/ssh/sshd_config

i ewentualnie odkomentować w pliku /etc/ssh/sshd_config wspomnianą linię. Na koniec restartujemy sshd:

/etc/init.d/ssh restart

MG

Tagi: , , ,

Time has been changed – co oznacza ten komunikat

Grudzień 17th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

Time has been changedJednym z problemów w administracji serwerami (nie tylko inuxowymi) jest synchronizacja czasu. Praktycznie każda usługa systemowa może odmówić posłuszeństwa jeżeli nie zadbamy o prawidłową podstawę czasu. Z pozoru zadanie to jest dość proste. Wystarczy zainstalować pakiet ntp:

 

 

apt-get install ntp

i od razu wszystko powinno działać. Osobiście polecam takie rozwiązanie na każdym sewerze z Linuxem aby właśnie zadbać o zsynchronizowanie naszej skali czasu z serwerami źródłowymi dostępnymi w Internecie. Musimy jednak pamiętać, że oprócz zegara systemowego, każdy komputer wyposażony jest w zegar sprzętowy. Funkcjonowanie tego ostatniego, a raczej jego zła praca, na pewno będzie miała wpływ na stabilność zegara systemowego. Są to bardzo rzadkie przypadki ale zdarzają się. Np. w Debianie Jessie aby zrealizować synchornizację wykorzystywane są kolejno usługi i funkcje systemd, swdate i w konsekwencji Slow Clock Adjuster. Co w moim przypadku, przy korzystaniu z maszyny VirtualBox, i zapewne błędnej obsłudze czasu przez środowisko wirtualne, zaowocowało komunikatami systemowymi (rsyslogd):

host systemd[1]: Time has been changed

Jak wspomniałem, jest to błąd oprogramowania i aby pozbyć się powyższych komunikatów trzeba je po prostu odfiltorwać na poziomie logu systemowego. W tym celu logujemy do konsoli roota i zakładmy plik time_msgs.conf:

touch /etc/rsyslog.d/time_msgs.conf

Następnie edytujemy plik:

vi /etc/rsyslog.d/time_msgs.conf

i dodajemu linijkę:

:msg, contains, "Time has been changed" stop

Po wszystkim musimy ponownie uruchomić usługę:

/etc/init.d/rsyslog stop
/etc/init.d/rsyslog start

Tym samym pozbyliśmy się niepotrzebnych komunikatów z logów systemowych.

MG

Tagi: , , , , ,

Jak dodać białą listę dla RBL na poziomie Postfixa

Wrzesień 17th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

White list

Czasami tak się zdarza, że używając do ograniczenia niechcianej poczty przychodzącej (czyli po prostu spamu) list RBL wytniemy coś niepotrzebnie. Sytuacja ta dotyczy w szczególności konfiguracji, w której używamy w tym celu np. Postfixa, definiując w pliku main.cf z jakich list chcemy skorzystać. Takie rozwiązanie jest dosyć skuteczne, ubijamy pocztę bowiem od razu na samym początku łańcucha przetwarzania, nie obciążając zbytecznie np. demona amavisd. Jednak z drugiej strony możemy stanąć przed dylematem jak utworzyć białą listę hostów nie wyłączająć całej listy RBL. Jak się okazuje w Postfixie nie jest to problem. Poniżej krótka instrukcja:

[1] W katalogu /etc/postfix tworzymy plik rbl_override (nazwa przykładowa):

touch /etc/postfix/rbl_override

[2] Edytujemy jego zawartość:

nano /etc/postfix/rbl_override

dodając wyjątki z białej listy:

1.2.3.4    OK
3.4.5.6    OK

[3] Tworzymy bazę dla Postfixa za pomocą polecenia postmap:

postmap /etc/postfix/rbl_override

[4] Na koniec edytujemy plik main.cf:

nano /etc/postfix/main.cf

i dodajemy odpowiednią linijkę w sekcji smtpd_recipient_restrictions bezpośrednio po komendzie reject_unauth_destination ale przed pierwsza czarną listą reject_rbl_client:

[...]
    smtpd_recipient_restrictions = ...
        ...
        reject_unauth_destination,
        check_client_access hash:/etc/postfix/rbl_override,
        reject_rbl_client multi.uribl.com,
        ...
[...]

Trzeba oczywiście pamiętać o zrestartowaniu daemona postfix po wszystkim…

MG

Tagi: , , , ,

Postfix – jak usunąć wybrany email z kolejki pocztowej

Sierpień 20th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

Ruch pocztowy a obsługa kolejkiKażdy kto zajmował się administrowaniem serwerem poczty na pewno zetknął się z sytuacją, w której kolejka wiadomości na serwerze zaczyna powoli się wydłużać i po pewnym czasie może dojść do małej awarii usługi. Sytuacje takie zdarzają się najczęściej w przypadku zapętlonych emaili ale również gdy jesteśmy celem ataku DoS lub po prostu ktoś z naszych klientów padł ofiarą wirusa wykorzystującego czytnik poczty do rozsyłania spamu. Ponieważ w każdym przypadku są to sytuacje niepożądane a bywa, że niebezpieczne, zazwyczaj należy się tym szybko zająć. Jeżeli korzystamy z serwera Postfix to po wydaniu polecenia:

postqueue -p

powinniśmy zobaczyć co dzieje się z naszą kolejką. Jeśli rzeczywiście zobaczymy, że jest ona przepełniona bo np. na naszym serwerze czeka kilka tysięcy emaili do wysłania (tak, miewałem takie sytuacje) to zasadniczo mamy dwie możliwości. Pierwsza, nazwałbym ją drastyczną, to usunięcie całej kolejki emaili:

postsuper -d ALL

Trzeba pamiętać jednak, że wraz z niepotrzebnymi wiadomościami możemy usunąć te, na których może nam bardzo zależeć (lub klientowi rzecz jasna). Dlatego czasami warto się przyjrzeć kolejce po to aby upewnić się czy przypadkiem ruch emailowy nie wychodzi z jednego z naszych kont pocztowych a wtedy warto rozważyć usunięcie jedynie wybranych emaili. Można to zrobić za pomocą komendy:

postqueue -p | tail -n +2 | awk 'BEGIN { RS = "" } / →
konto@domena\.net/ { print $1 }' | tr -d '*!' | postsuper -d -

która spowoduje usnięcie wiadomości od (lub do) użytkownika konto@domena.net. Ta prosta linijka pozwala czasami ustrzec się bardzo poważnych konsekwencji.

MG

Tagi: , , , ,

Budowa serwera SFTP na bazie SSH i Debiana

Maj 21st, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

SFTPJak powszechnie wiadomo nie wynaleziono jeszcze bardziej popularnej usługi do transferu plików niż FTP. Być może większość administratorów wolałaby korzystać z innych rozwiązań ale tak się składa, że znają prawie wszyscy użytkownicy i to oni z reguły wymuszają stosowanie FTP. Podstawowy problem w tym przypadku to brak szyfrowania transmisji co przede wszystkim oznacza przesyłanie haseł jawnym tekstem. Jednak mając gotowy serwer z Linuxem oraz dostępem zdalnym po SSH można pokusić się o przygotowanie serwera SFTP, który zachowując większość funkcji FTP będzie zabezpieczał odpowiednio nasze połączenia. Co więcej jeśli ktoś dotychczas korzystał z bardzo popularnych programów typu WinSCP czy FileZilla to zasadniczo nie powinien mieć żadnych problemów z korzystaniem z SFTP bowiem obsługa tego ostatniego została już zaimplementowana w tych windowsowych klientach. Zatem do dzieła.

Po pierwsze sprawdzamy czy obsługa SFTP została włączona w konfiguracji serwera OpenSSH. Plik /etc/ssh/sshd_config powinien zawierać wpis:

Subsystem sftp internal-sftp

Teraz, na końcu pliku możemy dodać sekcje dla nowego konta z dostępem SFTP:

Match User KontoSFTP
  ChrootDirectory /home
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand internal-sftp

Oczywiście zakładam, że wcześniej założyliśmy sobie takie konto w systemie. Po ponownym uruchomieniu serwera SSH wszystko powinno zacząć działać… oprócz dwóch drobnostek.

Na pewno warto zadbać aby użytkownik KontoSFTP nie miał dostępu shellowego do systemu. W tym celu musimy zmienić mu domyślny shell. Najpierw sprawdzamy czy możemy użyć shella typu sftp-server:

cat /etc/shells

Jeśli nie zostanie wyświetlona nazwa sftp-server powinniśmy użyć polecenia:

echo '/usr/lib/openssh/sftp-server' >> /etc/shells

Teraz możemy już zmodyfikować konto naszego użytkownika:

usermod -s /usr/lib/openssh/sftp-server KontoSFTP

Druga sprawa to powinniśmy zmienić prawa dostępu do tych podkatalogów w /home, do których chcemy zabezpieczyć dostęp. W ten sposób nasz użytkownik nie będzie mógł zwiedzać innych podkatalogów. Dla każdego z zabezpieczanych katalogów należy wydać polecenie:

chmod 700 /home/NazwaZabezpieczanegoKatalogu

Po wykonaniu powyższych czynności możemy cieszyć się nowym serwerem SFTP. Powyższe uwagi dotyczą rzecz jasna mojego ulubionego Debiana.

MG

Tagi: , , , , ,

ClamAV-clamd av-scanner FAILED

Kwiecień 16th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

AntywirusCałkiem niedawno instalowałem po raz kolejny serwer poczty dla klienta. Niestety wsparcie dla mojego ulubionego Debiana Squeeze skończyło się w kwietniu tego roku dlatego postanowiłem od razu pominąć dystrybucje Wheezy i skorzystać z Jessie. W jednym ze wcześniejszych wpisów podałem adres bardzo dobrego poradnika, który omawiał jak niewielkim kosztem przygotować bardzo wydajną i sprawną bramkę mailową typu Antivirus/Antispam. Świat idzie szybko do przodu i okazało się, że poradnik już nie jest dostępny. Co więcej autor poleca skorzystanie ze skryptów iRedMail. Skrypty skryptami, niby rozwiązanie wygodne i szybkie ale co ma zrobić administrator przyzwyczajony do konfigurowania wszystkiego ręcznie? Przez wiele lat nagromadziłem własne gotowe pliki konfiguracyjne i nie bardzo uśmiechało mi się przeglądanie gotowców z iRedMail. Dlatego postanowiłem sprawdzić co pozmieniało się w stosunku do informacji (konfiguracji) które już posiadam i jednak zbudować serwer poczty od początku na własną ręke. Musze przyznać, że zmian było stosunkowo niewiele. Oczywiście niektóre repozytoria wygasły a w ich miejsce pojawiły się inne. Miłą niespodzianką okazała się na przykład dostępność w podstawowym repo pakietu clamav-unofficial-sigs, o czy zupełnie nie wiedziałem i zawsze instalowałem „z palca”. W trakcie instalacji trafiłem jednak na spory problem. Coś co do tej pory działało niezawodnie, nagle w Jessie przestało funkcjonować prawidłowo. Chodzi o pakiet Clamav, który zaczał zgłaszać błędy:

... run_av (ClamAV-clamd) FAILED ...
... ClamAV-clamd av-scanner FAILED ...
... WARN: all primary virus scanners failed, considering backups...

Sprawa wyglądała dość poważnie bo dotyczyła jednego z kluczowych elementów każdego systemu pocztowego. Jak zwykle w takich sytuacjach rozwiązanie okazało się dość banalne. W pliku konfiguracyjnym /etc/clamav/clamd.conf, w dystrybucji Jessie zmieniła się jedna linijka. Wygląda ona obecnie tak:

AllowSupplementaryGroups false

a powinna wyglądać jak w poprzednich dystrybucjach, czyli:

AllowSupplementaryGroups true

I to wszystko.

MG

Tagi: , , ,