Configurazione di un webserver Debian Sarge
Da Faber Libertatis.
Questa guida tratta della configurazione di un webserver con installato il sistema operativo Debian GNU/Linux "Sarge".
Il webserver trattato ha la peculiarità d'essere quello che ospita, tra le altre cose, il sito dell'Associazione, con tutti i vari servizi (database, posta elettronica, ecc.): naturalmente quanto qui riportato può essere utile come esempio reale da applicare in altri casi.
Indice della pagina |
Visione d'insieme
Il server è una macchina virtuale acquistata presso VPScube, con 10GB di disco fisso, 256 MB di RAM e due indirizzi IP. Il software di virtualizzazione utilizzato dal provider è Xen.
Il server è di proprietà di alcuni soci, che l'utilizzano per dei propri scopi privati. All'Associazione è stato però donato dello spazio, sufficiente per allestire il sito nonché tutti i servizi correlati.
Configurazione del sistema operativo
Questa sezione tratta della configurazione del sistema operativo in generale, con il tuning necessario per renderlo sicuro e correttamente utilizzabile.
Utenti
La configurazione standard del server rilasciato da VPScube non prevede un utente diverso da root, per cui la prima attività riguarda la creazione di un utente non di sistema:
# adduser nomeutente
Da segnalare come questo server verrà utilizzato da più persone, per cui progressivamente verranno aggiunti i vari utenti corrispondenti.
Rete
Alla macchina virtuale che ospita il sito dell'Associazione sono stati assegnati due indirizzi IP. Il primo viene attivato in automatico direttamente dal software di virtualizzazione, Xen, mentre il secondo è stato attivato modificando opportunamente il file /etc/network/interfaces:
auto eth0:0 iface eth0:0 inet static address 194.177.96.xxx netmask 255.255.254.0
Da notare come il secondo indirizzo IP sia stato definito su un alias, eth0:0, dell'interfaccia di rete primaria, che invece è semplicemente eth0.
Per evitare problemi con i vari programmi, è utile sincerarsi che esista l'opportuna voce relativa all'indirizzo di loopback (il famoso 127.0.0.1 che si riferisce alla macchina stessa):
auto lo iface lo inet loopback
Se la voce precedente è assente, si provveda ad inserirla, riavviando la rete con
# /etc/init.d/networking restart
Accesso remoto (ssh)
Inizialmente, come detto, è attivo solo l'utente root e pertanto è possibile collegarsi alla macchina utilizzando ssh solo come root. Una volta aggiunto un utente, però, è conveniente disabilitare l'accesso per root, modificando opportunamente il file /etc/ssh/sshd_config affinché vi si trovi scritto:
PermitRootLogin no
Se si suppone inoltre che in futuro servirà poter accedere a delle applicazioni grafiche via tunnel ssh, dev'essere presente nel file citato la seguente riga:
X11Forwarding yes
Ovviamente bisogna poi riavviare ssh, col comando
/etc/init.d/ssh restart
A questo punto l'accesso come root è impedito, mentre è consentito l'accesso all'utente.
Come ulteriore configurazione per ssh, per quanto non propriamente di sistema, è possibile fare in modo che sia possibile accedere ad un dato utente via chiave: l'utente sul server, cioè, deve disporre della chiave pubblica di un client, su cui questa verrà generata nel seguente modo:
ssh-keygen -t dsa -N ''
Questo comando genererà una coppia di chiavi, ~/.ssh/id_dsa (chiave privata) e ~/.ssh/id_dsa.pub (chiave pubblica), con la seconda che dovrà essere integralmente copiata nel file ~/.ssh/authorized_keys2 dell'utente prescelto sul server. Si tenga presente che lo switch -N '' genera una chiave senza password, ma come ulteriore sicurezza è possibile immettere una password, possibilmente diversa da quella dell'utente sul server.
Applicazioni
Bind9
Bind9 è un server DNS molto utilizzato, tuttavia la configurazione predefinita non è sufficientemente sicura, per cui bisogna chrootare il DNS. Si sono utilizzati i consigli presenti sul Bind-Chroot-Howto per Debian.
Installazione di Bind9
Per prima cosa bisogna installare il software necessario:
apt-get install bind9-host bind9 dnsutils
La procedura d'installazione andrà ad aggiungere utente e gruppo bind e ad avviare il servizio named.
Creazione del chroot
Per prima cosa, si spenga il servizio named già attivo:
/etc/init.d/bind9 stop
Il chroot si creerà in /var/lib/named e bind9 dev'essere istruito ad utilizzare questa directory. Per far questo, si provvede a modificare il file /etc/default/bind9 provvedendo ad inserire quanto segue:
OPTIONS="-u bind -t /var/lib/named"
Successivamente si deve creare l'intero albero di directory necessario per il chroot:
mkdir -p /var/lib/named/etc mkdir /var/lib/named/dev mkdir -p /var/lib/named/var/cache/bind mkdir -p /var/lib/named/var/run/bind/run
I file di configurazione generati dall'installazione di default di bind9 devono essere spostati nel chroot:
mv /etc/bind /var/lib/named/etc
Per evitare successivi problemi, si deve creare un link simbolico dalla nuova collocazione verso la vecchia:
ln -s /var/lib/named/etc/bind /etc/bind
Devono essere inoltre creati dei file speciali:
mknod /var/lib/named/dev/null c 1 3 mknod /var/lib/named/dev/random c 1 8
Si devono naturalmente sistemare i permessi delle directory e dei file appena creati:
chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random chown -R bind:bind /var/lib/named/var/* chown -R bind:bind /var/lib/named/etc/bind
Infine, affinché vengano intercettati dei messaggi importanti dal logger di sistema, si deve modificare il file /etc/init.d/sysklogd, modificando una riga già esistente affinché riporti:
SYSLOGD="-a /var/lib/named/dev/log"
A questo punto, si può riavviare syslogd e bind9, con quest'ultimo che utilizzerà il chroot:
/etc/init.d/sysklogd restart /etc/init.d/bind9 start
Definizione delle zone
La configurazione di bind9 è un po' cervellotica, perché fa delle assunzioni un po' strane e, inoltre, i suoi file di configurazione utilizzano delle convenzioni non standard; tuttavia, con un po' di studio e soprattutto di pratica, è possibile configurare a puntino il DNS.
Attenzione: al momento (05/11/2006) le configurazioni seguenti non sono ancora presenti!
Per prima cosa bisogna modificare il file /var/lib/named/etc/bind/named.conf.local affinché includa gli opportuni richiami ai file delle cosidette zone, come da esempio:
zone "faberlibertatis.org" {
type master;
file "/etc/bind/faberlibertatis.org";
};
zone "96.177.194" {
type master;
file "/etc/bind/96.177.194";
};
Le due zone precedenti sono necessarie allo stesso modo (per quanto la seconda zona, quella numerica, sia utile più che altro per il reverse DNS); si ricordi inoltre che bind è chrootato, per cui dove si legge /etc/bin/nomefile, in verità si deve leggere /var/lib/named/etc/bind/nomefile!
Il primo file di zona, /var/lib/named/etc/bind/faberlibertatis.org, ha la seguente struttura:
$TTL 3D
@ IN SOA 205-96-177-194.servervirtuali.vpscube.it. root.205-96-177-194.servervirtuali.vpscube.it. (
200611051 ; serial
86400 ; refresh
3600 ; retry
604800 ; expire
86400 ) ; minimum
NS ns1.sevagram.org.
MX 10 mail.faberlibertatis.org.
TXT "Faber Libertatis"
localhost A 127.0.0.1
mail A 194.177.96.205
www A 194.177.96.205
old A 194.177.96.205
faberlibertatis.org. A 194.177.96.205
Si rimanda ovviamente all'opportuna documentazione di bind9 per i dettagli del file, comunque i punti salienti, quelli che successivamente potranno essere variati più di frequente, sono:
- il serial, ovvero un numero composto da anno (2006), mese (11), giorno (05) e un progressivo (1) in modo da determinare quali informazioni sono quelle correttamente aggiornate;
- il record NS, che indica il DNS server di riferimento;
- il recordo MX, che indica il mail server di riferimento, cui mandare le mail quando queste sono indirizzate a (esempio) pippo@faberlibertatis.org;
- i vari record A, ovvero l'associazione tra un nome quale www.faberlibertatis.org ed un indirizzo IP, 194.177.96.205.
Si ricordi che nei file di configurazione di bind quando si deve scrivere un indirizzo completo di dominio bisogna terminare la stringa con un . (ad esempio, faberlibertatis.org.), mentre invece quando si vuole che il nome venga composto col dominio basta evitare di aggiungere il . finale (ad esempio www che viene completato automaticamente in www.faberlibertatis.org).
L'altro file di zona, /var/lib/named/etc/bind/96.177.194, riporta invece le associazioni tra indirizzo IP numerico e indirizzo mnemonico: si noti infatti che il nome del file è il rovesciamento di 194.177.96, ovvero i primi tre segmenti dell'indirizzo IP del server.
$TTL 3D
@ IN SOA 205-96-177-194.servervirtuali.vpscube.it. root.205-96-177-194.servervirtuali.vpscube.it. (
200611051 ; serial
86400 ; refresh
3600 ; retry
604800 ; expire
86400 ) ; minimum
NS ns1.sevagram.org.
MX 10 mail.sevagram.org.
TXT "Sevagram"
205 PTR ns1.sevagram.org.
205 PTR vps.sevagram.org.
205 PTR mail.sevagram.org.
205 PTR faberlibertatis.org.
205 PTR www.faberlibertatis.org.
205 PTR mail.faberlibertatis.org.
205 PTR old.faberlibertatis.org.
Questo file è molto simile a quello precedente, infatti le uniche vere differenze sono i tipi di record, in questo caso PTR, che fanno sì che esista anche l'associazione inversa tra l'IP 194.177.96.205 e l'indirizzo mnemonico a scelta.
Ovviamente, alla fine della configurazione delle zone, deve essere riavviato bind col comando:
/etc/init.d/bind9 restart
MySQL
MySQL è uno dei principali database relazionali open source disponibili al momento sul mercato.
Il suo utilizzo in questo caso sarà per due scopi:
- gestione delle utenze locali (soprattutto per il mail server);
- database per i siti (un database per dominio).
Ovviamente si cercherà di fare in modo che l'installazione MySQL (e soprattutto i dati contenuti nei database) sia sicura.
Installazione di MySQL
L'installazione di MySQL richiede la presenza di un SMTP server, per cui si installerà postfix, per l'appunto un server di posta, la cui installazione e configurazione verrà spiegata più in dettaglio successivamente.
Il comando per procedere con l'installazione è il seguente:
apt-get install mysql-server-4.1 mysql-client-4.1
Ovviamente verranno scaricate anche tutte le dipendenze necessarie. Il server verrà avviato in automatico alla conclusione dell'installazione, eventualmente se serve riavviare si può dare il comando
# /etc/init.d/mysql restart
Inizialmente il server è configurato in un modo poco sicuro, senza alcuna password preimpostata per l'utente amministratore. Per prima cosa bisogna pertanto impostarne una:
# /usr/bin/mysqladmin -u root password 'passwordsegretissima'
quindi è necessario ricaricare le tabelle dei permessi
# /usr/bin/mysqladmin -u root -p reload
A questo punto, dando il comando
# mysql -p
e immettendo la password appena impostata, si dovrebbe accedere al prompt di MySQL.
È possibile configurare un file locale, ~/.my.cnf, affinché sia possibile accedere senza immettere ogni volta la password; il file dovrà avere permessi in lettura e scrittura solo per il proprietario del file. Il contenuto del file è il seguente:
[mysql] user=root password=passwordsegretissima
Si dia quindi un
chmod 600 .my.cnf
A questo punto MySQL è praticamente pronto, ci si sinceri che sia in ascolto solo in locale, che è poi l'impostazione predefinita:
netstat -autn | grep LIST | grep 3306 tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
Si può ora inizia a creare i database necessari.
Postfix
Postfix è uno dei più utilizzati SMTP server, ovvero quel tipo di software indispensabile per l'invio della posta elettronica. Postfix è molto apprezzato per la sua sicurezza, per la potenza, per la facilità di configurazione e, non ultimo, per l'abbondanza di documentazione ed esempi che lo vedono protagonista.
Installazione di Postfix
L'installazione iniziale di Postfix è banale:
apt-get install postfix
A questo punto verranno richieste un po' di informazioni all'utente:
- si indichi come tipo di configurazione Internet Site;
- si indichi il nome dell'utente che deve ricevere le e-mail di root;
- si indichi il nome con cui il server dev'essere conosciuto (la parte dopo nomeutente@ dell'indirizzo e-mail), ad esempio vps.sevagram.org;
- si indichino le destinazioni del server (in questo caso e momentaneamente vps.sevagram.org, sevagram.org, faberlibertatis.org, localhost);
- si lasci in stato off l'aggiornamento sincrono della coda di posta.
A questo punto si deve procedere con un po' di tuning.
Configurazione post-installazione di Postfix
La configurazione predefinita di Postfix è abbastanza ben fatta, per cui il tuning da fare è minimo. In particolare, vanno aggiunte le seguenti configurazioni al file /etc/postfix/main.cf:
mailbox_command = procmail -a "$EXTENSION"
Questo permette l'utilizzo dell'utilissimo procmail per lo smistamento della posta degli utenti locali. Si installi quindi procmail e si riavvi Postfix
apt-get install procmail /etc/init.d/postfix restart
e si facciano dei test d'invio della posta agli utenti locali:
telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 vps.sevagram.org ESMTP Postfix (Debian/GNU) helo test 250 vps.sevagram.org mail from: root@localhost 250 Ok rcpt to: root@localhost 250 Ok data 354 End data with <CR><LF>.<CR><LF> Subject: prova ciao! . quit 250 Ok: queued as A3A9AC254 221 Bye Connection closed by foreign host.
Per controllare la posta ricevuta localmente, s'è installato il magnifico client Mutt:
apt-get install mutt
Lanciando mutt l'utente locale destinatario della posta di root potrà leggere, se non vi sono stati problemi, la mail sopra inviata.
Integrazione di Postfix con MySQL
Normalmente, nei piccoli sistemi, per gestire l'invio della posta è sufficiente modificare opportunamente il file /etc/aliases, con l'unica avvertenza di dare i comandi
postalias /etc/aliases /etc/init.d/postfix reload
ad ogni modifica. Un normale file di aliases è strutturato nel seguente modo, con l'indirizzo cui inviare l'e-mail a sinistra e l'effettivo destinatario a destra:
# Required aliases postmaster: root MAILER-DAEMON: postmaster # Common aliases abuse: postmaster spam: postmaster root: utente
Si noti come la posta di root e quindi anche quella di abuse, spam, MAILER-DAEMON e postmaster, venga tutta rediretta all'utente.
Per un grosso sistema, oppure in caso servano delle configurazioni più spinte, conviene appoggiarsi ad un database, ad esempio MySQL, su cui creare dei virtual user: si vedano ad esempio i consigli presenti nel tutorial ISP-style Email Service with Debian-Sarge and Postfix 2.1.
La prima cosa da fare è la creazione di un database dedicato per la gestione degli utenti di Postfix, cosa che si può fare col comando
mysqladmin -u root -p create virtualmail
Si deve poi creare un utente di MySQL per l'utilizzo, in sola lettura, dell'appena creato database:
mysql -u root -p grant select on virtualmail.* to virtualmail@localhost identified by 'passwordcrittata'; flush privileges;
A questo punto è possibile procedere con la creazione delle tabelle necessarie, ovvero domains (che contiene l'elenco dei domini gestiti da Postfix), forwardings (che contiene l'elenco degli alias degli indirizzi, praticamente la trasposizione del file /etc/aliases), infine users (con l'elenco degli utenti, con password). Si proceda come segue:
mysql -u root -p virtualmail CREATE TABLE domains ( domain varchar(50) NOT NULL, PRIMARY KEY (domain) ) TYPE=MyISAM; CREATE TABLE forwardings ( source varchar(80) NOT NULL, destination TEXT NOT NULL, PRIMARY KEY (source) ) TYPE=MyISAM; CREATE TABLE users ( email varchar(80) NOT NULL, password varchar(20) NOT NULL, PRIMARY KEY (email) ) TYPE=MyISAM;
show tables; desc domains; desc forwardings; desc users;
A questo punto, bisogna istruire Postfix affinché provveda ad utilizzare il database MySQL in aggiunta al file /etc/aliases e questa cosa si fa innanzitutto creando quattro file, con proprietario l'utente root e gruppo postfix e permessi in lettura e scrittura per root, ma sola lettura per postfix.
ls -l /etc/postfix/mysql* -rw-r----- 1 root postfix 148 Nov 5 19:41 /etc/postfix/mysql-virtual_domains.cf -rw-r----- 1 root postfix 141 Nov 5 19:42 /etc/postfix/mysql-virtual_email2email.cf -rw-r----- 1 root postfix 154 Nov 5 19:42 /etc/postfix/mysql-virtual_forwardings.cf -rw-r----- 1 root postfix 211 Nov 5 19:42 /etc/postfix/mysql-virtual_mailboxes.cf
Il file /etc/postfix/mysql-virtual_domains.cf istruisce Postfix su quali sono i domini che deve gestire:
user = virtualmail password = passwordcrittata dbname = virtualmail table = domains select_field = 'virtual' where_field = domain hosts = 127.0.0.1
Il file /etc/postfix/mysql-virtual_email2email.cf serve ad evitare dei problemi in caso di presenza di un indirizzo e-mail in grado di intercettare le e-mail con destinatario sbagliato, cosa che con l'utilizzo delle virtual maps di Postfix rischia di far giungere al suddetto indirizzo tutte le e-mail, comprese quelle con indirizzo corretto:
user = virtualmail password = passwordcrittata dbname = virtualmail table = users select_field = email where_field = email hosts = 127.0.0.1
Il file /etc/postfix/mysql-virtual_forwardings.cf è, come detto, l'analogo del file /etc/aliases:
user = virtualmail password = passwordcrittata dbname = virtualmail table = forwardings select_field = destination where_field = source hosts = 127.0.0.1
Infine, il file /etc/postfix/mysql-virtual_mailboxes.cf presiede alla gestione delle virtual mailbox per gli utenti:
user = virtualmail password = passwordcrittata dbname = virtualmail table = users select_field = CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1),'/') where_field = email hosts = 127.0.0.1
In previsione della definizione di varie virtual mailbox per corrispettivi utenti virtuali che non avranno definito un analogo utente locale sul sistema, ci creerà quindi un utente che sarà il proprietario di tutte le virtual mailbox:
groupadd -g 5000 virtualmail useradd -g virtualmail -u 5000 virtualmail -d /home/virtualmail -m
L'ultimo passo da compiere è infine la riconfigurazione opportuna del file /etc/postfix/main.cf in modo che sia in grado di utilizzare i file appena creati, per cui devono essere inserite le seguenti righe:
### mysql virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual_domains.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailboxes.cf virtual_mailbox_base = /home/virtualmail virtual_uid_maps = static:5000 virtual_gid_maps = static:5000
A questo punto si riavvia Postfix
/etc/init.d/postfix restart
e l'integrazione con MySQL (senza però ancora dati) è conclusa.
Antispam senza l'uso di filtri esterni
Esistono dei metodi che permettono un minimo di protezione dallo spam senza necessitare di filtri esterni quali spamassassin.
Basta inserire queste righe in /etc/postfix/main.cf
disable_vrfy_command = yes # disabilita il comando VRFY, che permetterebbe ad uno spammer di capire # in anticipo quali sono le caselle e-mail valide smtpd_helo_required = yes # richiede che il client si identifichi con un comando HELO o EHLO smtpd_client_restrictions = permit_mynetworks, reject_rbl_client relays.ordb.org, reject_rbl_client list.dsbl.org, reject_rbl_client sbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client bl.spamcop.net, permit # un po' di controlli su varie blacklist smtpd_sender_restrictions = reject_unknown_sender_domain # non accetta mail da un dominio inesistente
Il primo morto
Ecco il primo morto ;-)
Nov 14 19:51:50 vps postfix/smtpd[9751]: connect from 200-153-129-206.dsl.telesp.net.br[200.153.129.206] Nov 14 19:51:50 vps postfix/smtpd[9751]: NOQUEUE: reject: RCPT from 200-153-129-206.dsl.telesp.net.br[200.153.129.206]: 554 Service unavailable; Client host [200.153.129.206] blocked using list.dsbl.org; http://dsbl.org/listing?200.153.129.206; from=<deborahsp@calinvestmentfund.com> to=<faber- -AT- -faberlibertatis.org> proto=ESMTP helo=<thiago-bbc47a62> Nov 14 19:51:51 vps postfix/smtpd[9751]: lost connection after DATA from 200-153-129-206.dsl.telesp.net.br[200.153.129.206] Nov 14 19:51:51 vps postfix/smtpd[9751]: disconnect from 200-153-129-206.dsl.telesp.net.br[200.153.129.206]
Greylisting
Si veda Greylisting: Postfix con Postgrey
Integrazione antispam e antivirus in Postfix
... lavori in corso ...
Dovecot
Dovecot è un potente POP3/IMAP server, semplice da configurare.
... lavori in corso ...
Apache 2
Apache è il principale server HTTP, secondo le famose statistiche di Netcraft. Per questo server, poiché fornirà anche contenuto accedibile via browser, si utilizzerà la versione 2 di Apache, con le opportuni estensioni (per PHP4, soprattutto).
Installazione di Apache 2
L'installazione di Apache è banale, in quanto è sufficiente dare il seguente comando, che scaricherà anche le necessarie dipendenze:
apt-get install apache2-mpm-prefork apache2-utils
Da notare ch'è possibile decidere se avviare o meno Apache impostando in modo opportuno la variabile NO_START nel file /etc/default/apache2.
Configurazione di Apache 2
Poiché si hanno a disposizione solo due indirizzi IP, mentre invece i siti che dovranno essere attestati su Apache dovranno essere più di due, si devono utilizzare i VirtualHost. Gli esempi sotto riportati si riferiscono solo ad un IP, ma ovviamente vanno ripetuti anche per l'altro.
Per cominciare, bisogna configurare il file /etc/apache2/ports.conf affinché Apache ascolti all'indirizzo IP prescelto con le porte necessarie, l'80 per l'http e la 443 per l'https (http sicuro):
Listen 194.177.96.205:80 Listen 194.177.96.205:443
Si modificherà quindi il file /etc/apache2/apache2.conf in modo da istruire Apache sul fatto che si utilizzeranno per l'IP e le porte specificate i VirtualHost col riconoscimento tramite il nome utilizzato (l'indirizzo immesso nel browser, per intenderci):
NameVirtualHost 194.177.96.205:80 NameVirtualHost 194.177.96.205:443
Si può a questo punto riavviare Apache, ignorando eventuali errori sui VirtualHost mancanti, perché verranno configurati in seguito:
/etc/init.d/apache2 restart
Installazione di moduli aggiuntivi per Apache 2
Al momento attuale, Apache è in grado di fornire praticamente solo pagine HTML statiche, mentre invece l'obiettivo è di fornire pagine dinamiche scritte con vari linguaggi di programmazione web oriented.
Si installa quindi sia il modulo PHP4 che il modulo Perl:
apt-get install libapache2-mod-perl2 libapache2-mod-php4
Ovviamente il comando succitato scaricherà ed installerà anche le dipendenze necessarie.
Un minimo di hardening
E' meglio dare il minor numero di informazioni possibili ad un attaccante... ad esempio possiamo nasconderli la versione del server e dei moduli installati con le direttive
ServerSignature Off ServerTokens Prod
Squirrelmail
Mailman
Mailman è un noto software di gestione delle mailing list, con un supporto anche per i virtualhost, per quanto l'implementazione non sia banalissima.
Per installarlo
apt-get install mailman listadmin
In fasi di configurazione indicare per quali lingue serve il supporto: selezionare en ed it, selezionando quest'ultimo come linguaggio predefinito.
Inizialmente mailman non s'avvia, perché ha bisogno di una prima lista amministrativa, che si può generare invocando il comando:
newlist mailman
A questo punto basta seguire le istruzioni, indicando il nome del gestore della lista (ad esempio root@nomemacchina) e la password iniziale. Bisogna inserire in /etc/aliases le seguenti definizioni
## mailman mailing list mailman: "|/var/lib/mailman/mail/mailman post mailman" mailman-admin: "|/var/lib/mailman/mail/mailman admin mailman" mailman-bounces: "|/var/lib/mailman/mail/mailman bounces mailman" mailman-confirm: "|/var/lib/mailman/mail/mailman confirm mailman" mailman-join: "|/var/lib/mailman/mail/mailman join mailman" mailman-leave: "|/var/lib/mailman/mail/mailman leave mailman" mailman-owner: "|/var/lib/mailman/mail/mailman owner mailman" mailman-request: "|/var/lib/mailman/mail/mailman request mailman" mailman-subscribe: "|/var/lib/mailman/mail/mailman subscribe mailman" mailman-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe mailman"
e lanciare newaliases, in modo che postfix sappia indirizzare a mailman le mail a lui indirizzate. A questo punto si può avviare mailman
/etc/init.d/mailman start
e andare a vedere la mail arrivata.
Integrazione di mailman in Apache 2
Mailman utilizza una comoda interfaccia web, che però ha degli indirizzi spiacevolmente lunghi. Per renderli più umani, è possibile modificare la direttiva di Apache che punta a mailman.
ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/
Bisogna tuttavia modificare /etc/mailman/mm_cfg.py per correggere le seguenti variabili:
DEFAULT_URL_PATTERN = 'https://%s/mailman' PRIVATE_ARCHIVE_URL = '/mailman/private'
Si verifichi inoltre che effettivamente sia stata impostata la lingua preferita:
DEFAULT_SERVER_LANGUAGE = 'it'
Ci si ricordi di inserire in Apache anche le seguenti due direttive:
Alias /images/mailman/ /usr/share/images/mailman/ Alias /pipermail/ /var/lib/mailman/archives/public/
La prima serve al caricamento delle immagine predefinite di mailman, mentre la seconda punta agli archivi delle liste.
Tuttavia la modifica di cui sopra, seguita ovviamente da un
/etc/init.d/apache2 restart
non è sufficiente a far digerire a mailman la nuova sintassi dell'URL, perché la lista mailman creata inizialmente possiede nella sua configurazione dei puntamenti statici ai vecchi URL! Bisogna pertanto lanciare un comando proprietario di mailman:
/usr/lib/mailman/bin/withlist -l -r fix_url mailman
A questo punto gli URL sono corretti.
Esempio completo di configurazione per Virtual Host Apache 2 di Mailman
Per motivi legati all'utilizzo di Suexec, che si è verificato essere incompatibile con l'allestimento di mailman del server, è necessario slegare il pannello di Mailman dai Virtual Host normali, creandone uno specifico ad hoc, col suffisso lists.
Come esempio, si riporta il completo /etc/apache2/sites-available/lists.faberlibertatis.org:
<VirtualHost lists.faberlibertatis.org:80>
ServerAdmin webmaster@lists.faberlibertatis.org
ServerName lists.faberlibertatis.org
ServerAlias lists.*
DocumentRoot /var/www/faberlibertatis.org/lists
RewriteEngine on
RewriteCond %{SERVER_PORT} !443 [NC]
RewriteRule ^/(.*)$ https://lists.faberlibertatis.org/$1 [R=301,NC,L]
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/faberlibertatis.org/lists>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/
Alias /images/mailman/ /usr/share/images/mailman/
Alias /pipermail/ /var/lib/mailman/archives/public/
<Directory "/usr/lib/cgi-bin/mailman">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
Alias /cgi-bin/mailman/ /mailman/
ErrorLog /var/log/apache2/lists.faberlibertatis.org-error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/lists.faberlibertatis.org-access.log combined
ServerSignature Off
</VirtualHost>
Integrazione di Mailman con Postfix
... Lavori in corso ...
Modificare /etc/mailman/mm_cfg.py per rendere presente la seguente variabile:
MTA = 'Postfix'
A questo punto bisogna inizializzare gli alias di mailman:
cd /var/lib/mailman bin/genaliases
Bisogna quindi assegnare gli alias così generati all'utente list di gruppo daemon:
cd /var/lib/mailman chown list:daemon data/aliases*
Bisogna quindi modificare le direttive alias_maps e virtual_alias_maps di Postfix, nel file /etc/postfix/main.cf:
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
virtual_alias_maps = hash:/var/lib/mailman/data/virtual-mailman,
mysql:/etc/postfix/mysql-virtual_forwardings.cf,
mysql:/etc/postfix/mysql-virtual_email2email.cf
In relazione alla direttiva virtual_alias_maps, bisogna sincerarsi che non vi siano riferimenti diretti alle liste nel database MySQL, perché così facendo si lascia fare tutto all'integrazione di Mailman con Postfix. Ci si ricordi solo di dare il comando
postmap /var/lib/mailman/data/virtual-mailman
qualora si modificasse il file sopra indicato.
Da ricordarsi di ricaricare Postfix ad ogni aggiunta/rimozione di liste:
/etc/init.d/postfix reload
Predisposizione di mailman per i virtual domain di Postfix
... Lavori in corso ...
Questa funzionalità predispone all'utilizzo dei virtual domain di Postfix (ed ai virtual host di Apache).
I virtual domain vengono gestiti da mysql.
Inserire in /etc/mailman/mm_cfg.py la seguente variabile, che elenca i domini gestiti da mailman via Postfix.
POSTFIX_STYLE_VIRTUAL_DOMAINS=['lists.sevagram.org', 'lists.faberlibertatis.org']
In questo modo i dati andranno posizionati in /var/lib/mailman/data/virtual-mailman.
Configurazione del webserver
Questa parte tratta della configurazione più applicativa, nel senso di configurazione atta a definire e a rendere fruibili i siti, gli indirizzi di posta, ecc.
Si prenderà un dominio come esempio, ma poi ovviamente tutto quanto può essere replicato per altri domini.
Configurazione del sito in Apache2
Permessi e Directory per i Virtual Host
Directory
Si è deciso di posizionare i virtual host con questa struttura directory:
/var/www/virtualhost/subvirtualhost
Ad esempio, il sito principale di faberlibertatis.org risiede sotto
/var/www/faberlibertatis.org/www
mentre il vecchio sito, raggiungibile a http://old.faberlibertatis.org risiede in
/var/www/faberlibertatis.org/old
In origine l'idea era di utilizzare /home/www come spazio per i siti, ma l'utilizzo di suexec risulta essere pienamente fattibile solo posizionando le DocumentRoot dei VirtualHost in /var/www, causa compilazione statica del pacchetto Debian.
Permessi
E' stato creato un gruppo www-* per ogni utilizzatore del server, e un utente per ogni dominio gestito. Ad esempio, il dominio faberlibertatis.org, gestito da Manu, ha il seguente proprietario:
# ls -l /var/www/ | grep faberlibertatis.org drwxr-s--- 4 faberlibertatis www-manu 4096 Nov 9 02:08 faberlibertatis.org
Ai gruppi www-* verranno in seguito applicate delle quote.
Dati i permessi qui indicati, bisognerà assegnare l'utente con cui gira Apache 2, ovvero www-data ai vari gruppi:
# adduser www-data www-manu # groups www-data www-data: www-data www-manu
PHP Safe Mode
L'engine PHP è stato abilitato in modalità "safe", che consente agli script php di accedere solamente ai file il cui owner (UID) è uguale a quello dello script stesso. Questo evita che un utente smaliziato crei uno script che possa accedere a file di altri utenti web.
Non è molto difficile abilitare la "safe mode", ma è necessario conoscere approfonditamente quello che ciò comporta. Infatti, la "safe mode" non solo interdisce l'accesso a determinati file, ma modifica l'uso di alcune syscall. Ad esempio sarà possibile eseguire solo i comandi esterni residenti in una determinata directory.
Per abilitare la "safe mode" è necessario apportare le seguenti modifiche al file /etc/php4/apache2/php.ini
safe_mode = On ; abilita la modalità safe safe_mode_gid = Off ; se safe_mode_gid fosse abilitato i controllo sarebbero "rilassati". infatti si confronterebbero i GID anzichè gli UID safe_mode_include_dir = "/usr/share/phpmyadmin/" ; questo dice a php di fregarsene dei proprietari se gli script risiedono in una cartella indicata. safe_mode_exec_dir = ; specifica la directory in cui risiedono i comandi esterni che possono essere chiamati da script php. ; lasciando vuoto non sarà possibile chiamare nessun comando esterno (o di sistema) safe_mode_allowed_env_vars = PHP_ ; spefifica i prefissi delle variabili env che possono essere modificate o create da uno script che usi la famiglia di funzioni putenv() safe_mode_protected_env_vars = LD_LIBRARY_PATH ; specifica quali variabili env non possono essere toccate disable_functions = ; si può disabilitare l'uso di alcune funzioni inserendole qui disable_classes = ; si può disabilitare l'uso di alcune classi inserendole qui
a questo punto riavviamo apache
# /etc/init.d/apache2 restart
Uso di MediaWiki
MediaWiki, con il file LocalSetting.php, cerca di sovrascrivere il parametro php memory_limit a 20M.
PHP in "safe mode" inibisce l'uso di tale funzione, quindi se si pensa di utilizzare mediawiki in un proprio sito si può chiedere agli amministratori di portare memory_limit a 20M per la cartella in cui risiede MediaWiki.
Gli amministratori inseriranno quindi le seguenti righe nel file di configurazione del virtual host
<Directory /var/www/faberlibertatis.org/www/w>
# /var/www/faberlibertatis.org/www/w è la cartella dove risiede MediaWiki
php_value "memory_limit" "20M"
</Directory>
Abilitazione del sito all'HTTPS
Per consentire un po' di sicurezza, è opportuno attivare dei siti col supporto al protocollo HTTPS, che consente la crittazione della comunicazione tra client e server, quest'ultimo riconosciuto da un certificato.
Per un limite di Apache, non è possibile creare tanti certificati quanti sono i Virtual Host, perché in ogni caso verrà utilizzato il certificato caricato per primo.
Posizionandosi nella directory /etc/apache2/ssl è possibile lanciare il comando
apache2-ssl-certificate -days n
dove n è il numero di giorni per cui si vuol mantenere in vigore il certificato. Dopo un nutrito numero di domande cui è abbastanza semplice rispondere, verrà creato un file apache.pem che dovrà essere caricato dai vari Virtual Host con le seguenti direttive:
SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.pem SSLOptions +StdEnvVars +StrictRequire
Per convenienza, queste direttive possono essere poste in un file di configurazione di Apache che replica quello del protocollo HTTP, ma con l'estensione -ssl; ovvero a fronte del file /etc/apache2/sites-available/www.faberlibertatis.org abilitato all'esclusiva gestione del protocollo HTTP, vi sarà anche il file /etc/apache2/sites-available/www.faberlibertatis.org-ssl dedicato al protocollo HTTPS ed in cui sono incluse le direttive citate poc'anzi. Naturalmente nel file che presiede al caricamento del Virtual Host in HTTPS sarà necessario correggere la direttiva d'apertura:
<VirtualHost www.faberlibertatis.org:443> ... </VirtualHost>
Per concludere, si verifichi che la porta 443 sia tra quelle abilitate in ascolto per Apache 2, come dal seguente esempio di direttive incluse nel file /etc/apache2/ports.conf:
Listen 194.177.96.205:443
Si riavvi infine il server Apache 2 per caricare la definizione del Virtual Host in HTTPS:
/etc/init.d/apache2 restart
Si ricordi comunque della limitazione di Apache 2 nella gestione dei certificati con i Virtual Host, ovvero che tutti i domini in HTTPS avranno il certificato SSL con la descrizione riferentesi al primo certificato caricato, che a questo punto si consiglia di creare con il nome della macchina.
Attivazione di mailman
Mailman consente il supporto dei virtualhost, ma non facilmente.
... da scrivere ...
/usr/lib/mailman/bin/withlist -l -r fix_url nomelista -u dominio.tld
