Spamassassin

Instalar software em Linux ainda continua a ser um desafio. A maior parte dos pacotes até se instala facilmente com um

./configure
make
make install

Mas o Spamassassin não. Precisa de uma série de módulos do Perl, e do próprio Perl para correr. E, depois, tem uma série de detalhes estranhos associados.

Para poder instalar os módulos obrigatórios e opcionais seguintes

cpan install HTML::Parser
cpan install Net::DNS
cpan install NetAddr::IP

cpan install Digest::SHA1
cpan install Mail::SPF
cpan install GeoIP2::Database::Reader
cpan install Geo::IP
cpan install IP::Country::DB_File
cpan install IO::Socket::INET6
cpan install Encode::Detect::Detector
cpan install Net::Patricia
cpan install Net::DNS::Nameserver
cpan install BSD::Resource
cpan install Archive::Zip
cpan install IO::String

tive que configurar o CPAN, como referido no artigo anterior.

Para instalar o Spamassassin, usei os comandos indicados no ficheiro INSTALL, que vem na raiz do ficheiro bz2.

	perl -MCPAN -e shell                    [as root]
	o conf prerequisites_policy ask
	install Mail::SpamAssassin
	quit

Depois, atualizei as regras com o comando sa-update.

Mas ainda assim, o spamd não arrancava. No ficheiro /var/log/maillog escrevia o erro:

spamc[13023]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused

Para resolver isto, criei o ficheiro /etc/mail/spamassassin/spamc.conf e coloquei lá dentro a linha

-d 127.0.0.1

Continuava a não arrancar. E produzia uma mensagem de conflito de versões:

spamassassin script is v3.003000, but using modules v3.004000

Descobri, então, que o comando /usr/bin/spamd era um link simbólico a apontar para uma versão antiga:

/usr/bin/spamd -> /root/.cpan/build/Mail-SpamAssassin-3.3.2-X536zH/spamd/spamd

Removi todas as versões antigas que estavam na diretoria /root/.cpan/build/ e atualizei o link simbólico.

Agora já corre!

Perl, essa geringonça

Hoje, a tentar instalar o Spam Assassin, do Apache, para filtrar o spam do Postfix, deparei-me com uma dificuldade: a instalação precisa do Perl e de alguns módulos que eu não tinha instalados.

Tentei instalar esses módulos, mas os mirrors do CPAN (que estavam configurados na minha máquina) estavam todos em baixo. Será por ser Natal?

Fui então à procura de outros mirrors que me pareceram de confiança, e inseri-os à cabeça da lista de mirrors no ficheiros de configuração

vi /root/.cpan/CPAN/MyConfig.pm

‘urllist’ => [q[http://cpan.perl.pt/], q[http://mirrors.up.pt/CPAN/], q[http://cpan.mirror.iphh.net/], q[http://artfiles.org/cpan.org/], q[http://ftp-stud.hs-esslingen.de/pub/Mirrors/CPAN/], q[http://cpan.metacpan.org/], q[http://mirrors.dotsrc.org/cpan/], q[http://cpan.inode.at/], q[http://mirror.kumi.systems/cpan/], q[http://mirror.easyname.at/cpan/], q[http://ftp.belnet.be/mirror/ftp.cpan.org/], q[http://ftp.igh.cnrs.fr/pub/CPAN/], q[http://cpan.mirrors.ovh.net/ftp.cpan.org/], …]

VirtualBox e máquina inacessível

Tinha algumas máquinas virtuais inacessíveis, máquinas que removi por deixarem de ser úteis, mas que continuavam a aparecer na lista do VirtualBox.

O comando VBoxManage list vms dava o resultado seguinte:

"bd" {6bf7c5c8-2d6e-435a-8025-da2c90f42b1e}
"java" {d1100632-04f6-46db-8f54-64e0494e9080}
"grafo" {c77f7a84-4040-456e-932d-a5689653ada6}
"<inaccessible>" {252949ba-b87b-4eb4-b648-28ee3d86d32b}
"<inaccessible>" {a7689028-bd41-4692-9385-407a4665097d}

Para remover as máquinas inacessíveis, usei os comandos seguintes:

VBoxManage unregistervm 252949ba-b87b-4eb4-b648-28ee3d86d32b
VBoxManage unregistervm a7689028-bd41-4692-9385-407a4665097d

UEFI e VirtualBox – II

Afinal o problema era mesmo do VirtualBox. O VirtualBox antes da versão 6.1.0 era incompatível com o kernel 5.4 do Linux. [1]

Esse problema foi corrigido na versão 6.1.0 do VirtualBox, que só saiu já depois do problema que detetei e reportei no artigo anterior.

Cores no vi

Estou a desenvolver umas aplicações num servidor que tem o Ubuntu, e onde o vi arranca com letras às cores.

Sou parcialmente daltónico, não consigo ver vermelho ou azul sobre preto, e, por isso, tinha que escrever o comando :syntax off sempre que entrava num ficheiro novo. Era uma perda de tempo.

Já tinha feito pesquisas à procura de soluções para isto, para tentar configurar o vi para arrancar sempre com o parâmetro syntax off selecionado à partida. Hoje, encontrei a solução. É relativamente simples.

No ficheiro de configuração do vi ~/.vimrc, colocar a linha syntax off.

UEFI e VirtualBox

Atualizei os hosts das máquinas virtuais para o Kernel 5.0.2 e o VirtualBox deixou de funcionar.

Passei a receber uma mansagem a dizer que, para carregar o /sbin/vboxconfig, era necessário assinar uma série de módulos.

Fui jantar.

Quando voltei, ainda não me tinha decidido sobre o que fazer. Talvez o melhor fosse mesmo assinar os módulos de que ele se queixava. Mas o que eu fiz foi o seguinte:

========================================================
# ver: 
https://www.linuxquestions.org/questions/slackware-14/safely-downgrade-slackware-kernel-4175604442/
========================================================

cd /tmp/4.19.62/
cd modules/
upgradepkg *.txz
cd ..
cd headers/
upgradepkg *.txz
cd ..
cd source/
upgradepkg *.txz


lilo


========================================================
ATENÇÃO: NA DIRETORIA /tmp/4.19.62 ESTÁ:
========================================================

Na diretoria /tmp/4.19.62/ colocar os ficheiros

root@tao:/tmp/4.19.62# ls -l *
headers:
total 908
-rw-r--r-- 1 root root    332 Jul 28 23:37 kernel-headers-4.19.62-x86-1.txt
-rw-r--r-- 1 root root 915476 Jul 28 23:37 kernel-headers-4.19.62-x86-1.txz
-rw-r--r-- 1 root root    163 Jul 28 23:37 kernel-headers-4.19.62-x86-1.txz.asc

modules:
total 133876
-rw-r--r-- 1 root root      422 Jul 26 19:37 kernel-firmware-20190726_dff98c6-noarch-1.txt
-rw-r--r-- 1 root root 82019836 Jul 26 19:37 kernel-firmware-20190726_dff98c6-noarch-1.txz
-rw-r--r-- 1 root root      163 Jul 26 19:37 kernel-firmware-20190726_dff98c6-noarch-1.txz.asc
-rw-r--r-- 1 root root      624 Jul 28 23:18 kernel-generic-4.19.62-x86_64-1.txt
-rw-r--r-- 1 root root  6450504 Jul 28 23:18 kernel-generic-4.19.62-x86_64-1.txz
-rw-r--r-- 1 root root      163 Jul 28 23:18 kernel-generic-4.19.62-x86_64-1.txz.asc
-rw-r--r-- 1 root root      636 Jul 28 23:17 kernel-huge-4.19.62-x86_64-1.txt
-rw-r--r-- 1 root root 10143888 Jul 28 23:17 kernel-huge-4.19.62-x86_64-1.txz
-rw-r--r-- 1 root root      163 Jul 28 23:17 kernel-huge-4.19.62-x86_64-1.txz.asc
-rw-r--r-- 1 root root      567 Jul 28 23:37 kernel-modules-4.19.62-x86_64-1.txt
-rw-r--r-- 1 root root 38274660 Jul 28 23:37 kernel-modules-4.19.62-x86_64-1.txz
-rw-r--r-- 1 root root      163 Jul 28 23:37 kernel-modules-4.19.62-x86_64-1.txz.asc

source:
total 101404
-rw-r--r-- 1 root root      2897 Jun 24  2009 install-packages
-rw-r--r-- 1 root root       446 Sep 18  2006 install.end
-rw-r--r-- 1 root root       317 Jul 28 23:12 kernel-source-4.19.62-noarch-1.txt
-rw-r--r-- 1 root root 103701504 Jul 28 23:12 kernel-source-4.19.62-noarch-1.txz
-rw-r--r-- 1 root root       163 Jul 28 23:12 kernel-source-4.19.62-noarch-1.txz.asc
-rw-r--r-- 1 root root      1171 Jul 29 03:08 maketag
-rw-r--r-- 1 root root      1171 Jul 29 03:08 maketag.ez
-rw-r--r-- 1 root root        18 Jul 29 03:08 tagfile

Kernel 5.4.1

Boas novas!

O Slackware já está a usar o kernel 5.4.1 na versão current. Mas talvez ainda seja boa ideia esperar uns dias, até que os pacotes mais importantes sejam atualizados para tirar partido desta nova versão do kernel.

Daqui a uns dias, testo este novo kernel e do feedback por aqui.

Kernel 5.4.0

O Slackware current já contém, na diretoria testing, o kernel 5.4.0_rc8.

É muito provável que o Patrick se esteja a preparar para lançar o Slackware 15 com a primeira versão estável deste novo kernel.

Aguardemos.

Postfix e Dovecot

Desde que o Slackware começou a usar o Postfix e o Dovecot como servidores de email e imap, que tem sido uma dor de cabeça tentar configurá-los.

Ontem voltei a tentar e já tenho um servidor a funcionar minimamente.

Os sites que usei para ver como configurar o Postfix foram [1], [2] e [3].
Para o Dovecot usei o site [1]. Estou a ler também [2] para tentar configurar o IMAPS.

Para o Postfix, editei o ficheiro /etc/postfix/main.cf e adicionei as linhas seguintes:

mydomain = myserver.pt
myorigin = $mydomain
inet_interfaces = all
mydestination = localhost.$mydomain, localhost, $mydomain
mynetworks = 192.168.0.0/16, 127.0.0.0/8
relay_domains = $mydestination
relayhost = [my-relay-server.pt]

smtpd_recipient_restrictions =
    reject_unauth_destination
    reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
    reject_rbl_client b.barracudacentral.org=127.0.0.2

Para o Dovecot, editei o ficheiro /etc/dovecot/dovecot.conf e adicionei as linhas seguintes:

protocols = imap
listen = *, ::
login_trusted_networks = 192.168.0.0/16

Depois, na diretoria /etc/dovecot/conf.d:

Editei o ficheiro 10-logging.conf e adicionei as linhas seguintes:

log_path = /var/log/dovecot/dovecot.log

Editei o ficheiro 10-mail.conf e adicionei as linhas seguintes:

mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u
mail_access_groups = mail

A configuração anterior mail_access_groups = mail é perigosa, pois permite que utilizadores com shell no login, tenham acesso às caixas de correio dos outros. Havia uma outra alternativa para resolver um erro que o Dovecot dava, mas não a compreendi.

Sem esta configuração, o erro que surgia no ficheiro de log era:

Error: fchown(/home/user/mail/.imap/INBOX, group=12(mail)) failed: 
Operation not permitted (egid=1000(user), group based on 
/var/spool/mail/user - 
see http://wiki2.dovecot.org/Errors/ChgrpNoPerm)

Editei o ficheiro 10-ssl.conf e adicionei as linhas seguintes:

ssl = no

E comentei também as linhas seguintes, enquanto não configuro o IMAPS.

#ssl_cert = </etc/ssl/certs/dovecot.pem
#ssl_key = </etc/ssl/private/dovecot.pem

Para testar se o dovecot está a funcionar bem, executei o comando seguinte:

mutt -f imap://user@myserver.pt

Vou começar por configurar as máquinas mais simples, e mudá-las do sendmail/imapd para o postfix/dovecot. Quando estiver tudo a funcionar, vou tentar configurar também a máquina mais complexa, que serve de relay às outras.