|
|
<- Mono - Indice Generale - Copertina - Maven: accumulator of knowledge -> |
|
Sistemi Liberi
L'articolo...I servizi che è possibile attivare all'interno di un moderno server dipartimentale, così come la configurazione dello stesso sistema operativo, impongono al sistemista la realizzazione di un gran numero di operazioni in un ordine logico ben preciso. Il presente articolo aiuta a non dimenticare le "cose da fare" per alcuni servizi importanti all'interno di un server Linux. |
Il titolo di questo articolo è molto generico. Tuttavia, è opportuno fare alcune precisazioni. Lo scopo dell'articolo è quello di fornire indicazioni dettagliate che si devono seguire per mettere in piedi servizi importanti all'interno di un server Linux, ma facendo in modo di poter avere tutto "alla mano", senza dover cercare (e perdersi, direi) all'interno dell'imponente massa di documentazione disponibile per questi servizi.
Naturalmente, non c'è niente di nuovo sotto il sole. Tutto quello che leggerete in questo articolo lo si trova in Rete, disponibile liberamente, ma penso che un piccolo compendio che riassuma le più importanti operazioni da realizzare sia utile, anche se mi rendo conto che si tratta di un parere opinabile.
Ritengo che la scelta della distribuzione sia importante ma non essenziale. Comunque, dato che questa scelta può portare a fare delle considerazioni che differiscono da altre distribuzioni, noi ne sceglieremo una in particolare. Anche se io non ne ho provate moltissime, parto dell'idea che "quello che funziona non si cambia" e, visto che l'articolo lo scrivo io, quanto sarà detto farà riferimento esplicitamente a una Debian etch.
Sempre nell'ottica di motivare il più possibile le scelte, che sono comunque in gran misura personali e dipendenti dalla storia e dalla formazione del sistemista, posso dire che apprezzo enormemente la stabilità e robustezza dei server Debian. Inoltre, sono dell'opinione che il sistema di aggiornamenti dei pacchetti sia tra i migliori in circolazione. A differenza delle altre distribuzioni non ho mai avuto problemi nel processo di aggiornamento del software, neppure nel passaggio dalla sarge alla etch, infatti è bastato modificare i sorgenti dei pacchetti e apt si è occupato di aggiornare l'intero sistema. Per quanto riguarda il software di aggiornamento dei pacchetti Debian, noi faremo riferimento a aptitude anziché apt, come consigliato dallo stesso team Debian, e che dovrebbe consentire una gestione più efficiente di alcune dipendenze, oltre a racchiudere nello stesso frontend tutta una serie di pacchetti apt (apt-get, apt-cache, ecc.).
Quindi, il risultato di questo articolo sarà una "ricetta". Il concetto di ricetta è noto e comune ad altre categorie professionali. Pensiamo ad esempio ai cuochi oppure ai chimici. Entrambi usano dei protocolli chiamati nel gergo "ricette", che consistono sostanzialmente nell'elencare il tipo, il numero e l'ordine dei passaggi da seguire. La ricetta risparmia lo sforzo di dover ricordare ogni singolo passaggio, evitando quindi di perdere operazioni che potrebbero essere dimenticate, velocizzando enormemente l'intero processo di configurazione. Inoltre ci permette di standardizzare la sequenza di operazioni, utile nel caso l'operatore proponga ai suoi clienti lo stesso sistema.
Naturalmente, quanto detto non significa che le cose non debbano essere capite. Soprattutto perché non c'è modo di risolvere un problema, qualora si presenti, se non si comprende bene il sistema. Ma questo è uno sforzo che si fa le prime volte, dopodiché si può procedere molto più velocemente, senza dover focalizzare l'attenzione ogni volta sul singolo passaggio.
Quanto segue è il risultato di alcune note personali che ho costruito negli ultimi anni su queste problematiche, e che risultano sempre di enorme utilità. Spero che qualcuno di voi, alla fine della lettura, sarà della stessa opinione. Discuterò anche qualche opzione di configurazione che ho fatto fatica a reperire nella documentazione ufficiale, e che ho appreso su alcuni forum grazie all'aiuto di qualche collega.
Cominciamo.
I punti che discuteremo sono i seguenti:
installazione e configurazione minimale del server Debian;
MySQL 5;
Postfix + Clamav + Courier + Spamassassin + Postgrey, con virtualizzazione delle caselle di posta con un database MySQL;
Apache 2 + phpmyadmin + postfixadmin;
Hylafax;
Rsnapshot.
I sistemi che io metto in piedi sono in genere formati da due dischi identici in RAID1, senza LVM. Preferisco una installazione minimale iniziale partendo da una installazione da rete:
Masterizzare l'immagine ISO netinstall scaricata dal sito ufficiale Debian (http://www.debian.org/).
Installare il sistema, seguendo le indicazioni in RAID1, eventualmente con il supporto LVM. Il programma di installazione Debian consente molto intuitivamente di definire le partizioni dei singoli dischi che verranno "integrate" nei diversi volumi RAID. Ovviamente bisogna prima partizionare ciascun disco.
Il corretto partizionamento dei dischi è un punto soggetto a controversie, ma noi non ci soffermeremo a discuterlo per non allungare ulteriormente l'articolo. Per un disco da 160 GB (SATA) su un sistema con un 1 GB di RAM, in genere faccio il seguente partizionamento:
|
# fdisk /dev/sda |
La procedura di installazione si occupa per noi di assegnare il corretto id alla partizione; l'asterisco indica la partizione di boot. Io definisco 3 partizioni primarie (sda1 di 1 GB per la partizione di boot, sda2 di 10 GB per la partizione di root e sda3 di 1 GB per la swap, che è anch'essa in RAID) e una partizione estesa (sda4), che poi viene ridefinita in due partizioni logiche (sda5 di 15 GB per /usr e sda6 con il resto della capienza del disco per /var). La scelta di avere anche la swap in RAID1 permette, al prezzo di un rallentamento trascurabile, di avere un sistema completo se uno dei dischi si guasta. La partizione più grande è assegnata a /var dato che su un sistema Debian è qui che si verrà a trovare la maggior parte dei dati (posta, fax, ecc.). Lo stesso partizionamento deve essere fatto sull'altro disco (sdb).
Fatto il partizionamento, le partizioni sono raggruppate per formare i diversi volumi RAID (definiti sempre comodamente dalla procedura di installazione):
|
# cat /proc/mdstat
|
che alla fine danno luogo al filesystem Linux:
|
# cat /etc/fstab
|
Per gli utenti, oltre al root, è meglio definire un altro utente, diciamo admin, il quale è l'unico a cui si potrà accedere da remoto tramite ssh, per ragioni di sicurezza.
A questo punto è necessario modificare i sorgenti del package manager. Infatti, per qualche strana ragione, dopo l'installazione, il file dove sono definiti i sorgenti contiene una configurazione come se il sistema fosse caricato da CDROM. Quindi editiamo il file /etc/apt/sources.list e inseriamo, se non ci sono, le seguenti righe:
|
# cat /etc/apt/sources.list
|
che definiscono gli host http da dove il sistema di aggiornamento reperisce i pacchetti. Il server security è importante e contiene frequenti patch di sicurezza. Il server volatile, invece, contiene pacchetti necessari per alcuni programmi che hanno bisogno di frequenti modifiche, tipicamente usato per aggiornare clamav e la definizione dei virus. Tutti e tre i server sono indispensabili per il corretto aggiornamento del sistema.
La configurazione precedente è valida per un sistema che ha una installazione stable (la versione etch al momento di scrivere questo articolo) della distribuzione Debian. Per le versioni testing o unstable la configurazione sarà in genere differente. Al momento di un cambio nella versione stable, il file sources.list va modificato secondo le specifiche che si troveranno sul sito ufficiale.
Installare il sistema base. I pacchetti addizionali verranno installati in seguito. Questo consente di avere più controllo, a mia opinione, sul software effettivamente caricato sul server.
Aggiornare il file /etc/hosts con il nome corretto della macchina:
|
# cat /etc/hosts |
Verificare l'hostname della macchina ed eventualmente settarlo con il comando hostname oppure scrivendo nome e dominio nel file /etc/hostname:
|
# cat /etc/hostname |
A questo punto è necessario fare alcune modifiche nel file di configurazione di mdadm, il programma che si occupa della gestione del RAID dal punto di vista amministrativo. In particolare, editiamo il file /etc/mdadm/mdadm.conf e inseriamo o cambiamo le seguenti direttive:
|
# automatically tag new arrays as belonging to the local system
|
dove definiamo il nome del server e l'indirizzo di posta al quale verranno inviati eventuali messaggi. Se, ad esempio, il demone che gestisce il RAID verifica un guasto su uno dei dischi, invierà una comunicazione all'indirizzo di posta elettronica indicato in mdadm.conf.
Salviamo le modifiche e facciamo ripartire il demone RAID:
|
/etc/init.d/mdadm restart |
Per l'aggiornamento del sistema, creo un piccolo script update_system.sh che lancia in sequenza tutti i comandi necessari:
|
#!/bin/sh |
che lancio periodicamente, in genere una volta al mese. C'è un pacchetto Debian per fare la stessa cosa, ma io preferisco lanciare a mano questo script per avere il controllo su eventuali domande e messaggi di avvertimento generati durante il processo di aggiornamento. Dopo l'installazione del sistema, è opportuno lanciare questo script per la prima volta, in modo da aggiornare tutti i pacchetti del sistema all'ultima versione stabile.
È arrivato il momento di installare grub sul mbr di entrambi i dischi. La procedura prevede i seguenti passaggi:
|
# grub |
In questo modo, se uno dei dischi si guasta, il disco rimanente ha tutte le informazioni per poter far ripartire il sistema e per lavorare normalmente, swap inclusa. L'aggiornamento del mbr di entrambi i dischi è necessario ad ogni cambiamento del kernel.
Facciamo un reboot.
Installiamo il server ssh:
|
aptitude install openssh-server |
Modifichiamo il file /etc/ssh/sshd_config in modo da non permettere il login al root, tramite la direttiva:
|
PermitRootLogin no |
e facciamo un restart del servizio:
|
/etc/init.d/ssh restart |
Gli accessi ssh al server dovranno essere realizzati accedendo inizialmente con l'utente admin. Questo aumenta la sicurezza del sistema al costo di un doppio passaggio. Naturalmente, non si deve permettere all'utente admin l'esecuzione di comandi come root tramite sudo per non invalidare quanto detto.
Sui server che faccio io, installo anche il dns per fare in modo che sia la macchina a occuparsi dei compiti di risoluzione dei nomi:
|
aptitude install bind9 |
Facciamo capire al server che sarà lui stesso a occuparsi della risoluzione dei nomi, aggiungendo nel file /etc/resolv.conf:
|
search dominio |
In genere non installo il pacchetto resolvconf.
Adesso però bisogna tenere in mente che, a differenza di quando si sceglie di utilizzare il dns del provider, non abbiamo previsto un sistema per aggiornare l'elenco dei root dns, che in genere varierà nel tempo. Il file che contiene questo elenco è definito nel file /etc/bind/named.conf:
|
// prime the server with knowledge of the root servers
|
e dove il file db.root contiene qualcosa come:
|
; <<>> DiG 9.3.4-P1.1 <<>> @e.root-servers.net . ns
|
derivante dal lanciare il comando dig senza parametri. Per aggiornare questo file, costruiamo il seguente script:
|
#!/bin/sh #
|
Basta mettere questo script nella cartella /etc/cron.monthly perché venga eseguito una volta al mese. Se qualche cosa va storto, possiamo sempre recuperare il file di backup /etc/bind/db.root.old.
webmin è un programma utile per realizzare certi compiti di amministrazione. La etch non lo riporta più come pacchetto ufficiale, per cui bisogna scaricarlo e installarlo separatamente (c'è un apposito pacchetto .deb nel sito ufficiale del programma). webmin funziona come servizio a sé attraverso la porta 10000, nella configurazione di default. Per ragioni di sicurezza, imposto l'eventuale firewall o router a valle del server con la porta 10000 chiusa, in modo da impedire l'accesso dall'esterno. Il collegamento avviene attraverso vpn.
Installo apache, nella versione 2 e con alcune dipendenze, che poi sarà necessario per molti servizi che andremo a configurare più avanti:
|
aptitude install apache2 libnet-ssleay-perl openssl libauthen-pam-perl libio-pty-perl libmd5-perl |
Ci rimane qualche cosetta da fare. In primo luogo, accertarci che il sistema aggiorni l'ora periodicamente. A questo scopo, installiamo un client ntp:
|
aptitude install ntpdate |
e scheduliamo l'aggiornamento di data e ora all'avvio del server e una volta al giorno. Io in genere lo faccio attraverso il crontab del root, inserendo le righe:
|
@reboot /usr/sbin/ntpdate ntp1.ien.it
|
Per ultimo, cambio lo strip rotate, e cioè il numero massimo di periodi che verranno conservati per i file di log da logrotate. Io in genere utilizzo una periodicità settimanale e conservo 52 periodi, equivalenti a un anno:
|
# cat /etc/logrotate.conf
|
mysql è il database server che verrà utilizzato da tanti altri servizi, ad esempio dal server di posta postfix per la virtualizzazione delle caselle di posta. È un server affidabile e leggero. La configurazione prevede i seguenti passaggi:
aptitude install mysql-server-5.0
che installa anche tutta una serie di dipendenze associate.
Cambiare la password di root per mysql:
|
mysqladmin -u root password <new password> |
Per dare accesso da remoto oltre a localhost al server mysql, seguire la seguente procedura:
commentare la riga bind-address = 127.0.0.1 in /etc/mysql/my.cnf;
entrare nella console di mysql con mysql -u root -p;
inserire la query:
|
GRANT ALL ON *.* TO root@w.x.y.z IDENTIFIED BY 'password'; |
cambiando l'ip w.x.y.z e la password password;
/etc/init.d/mysql restart
provare da remoto a collegarsi con:
|
mysql -h w.x.y.z -u root -p |
Alcuni programmi hanno bisogno della compatibilità password con la versione 4 di mysql. Per settare la compatibilità per un utente mioutente password miapassword, inserire dalla console del programma:
|
UPDATE mysql.user SET PASSWORD = old_password( 'miapassword' ) WHERE User = 'mioutente'; |
postfix è un server di posta sviluppato tenendo d'occhio la sicurezza. Su una macchina Linux gli utenti di sistema, di default hanno una casella di posta. I diversi servizi associati alla posta elettronica (smtp, pop, imap, ...) controllano e inoltrano le email verso la casella di posta dell'utente. Questa è una configurazione sconsigliabile, benché molo facile da configurare (in pratica bisogna installare il software e poco più), dal momento che per abilitare la posta a un utente bisogna creare un utente di sistema, con ovvie ricadute negative dal punto di vista della sicurezza. Quindi, in questo articolo proporremo una configurazione "virtuale", nel senso che le caselle di posta saranno delle cosiddette caselle di posta virtuali, slegate dagli utenti del sistema. Le credenziali di autenticazione e altri parametri necessari saranno definiti in un database mysql.
Gli altri programmi associati a questo servizio sono:
courier, che fornisce i servizi pop e imap;
clamav, l'antivirus;
spamassassin e postgrey, per il controllo antispam.
Il sistema proposto avrà quindi due sistemi antispam:
inizialmente postgrey rifiuta tutta la posta che arriva per la prima volta al server (dove il criterio per discriminare se accettare la posta o meno è costituito dalla combinazione di host inviante, mittente e destinatario). Il server inviante aspetta un po' e, se è configurato correttamente, riprova ad inviare il messaggio dopo un certo tempo. Quando un messaggio con la combinazione di parametri sopra indicata arriva di nuovo al server, dopo essere stato rifiutato da postgrey, viene lasciato passare, dal momento che il programma considera che il sistema mittente "si comporta bene", secondo le RFC relative a questo tipo di servizi Internet. Questo semplice meccanismo stronca alla radice il 90% dello spam che ci arriverà, dal momento che molti spammer non hanno un vero server di posta e inviano i messaggi con un normale client, per cui i messaggi vengono ricevuti solo una volta;
i messaggi che passano il filtro di postgrey vengono passati a un sistema antispam vero e proprio, che controlla il contenuto e altri aspetti del messaggio, dando dei punteggi a un certo numero di parametri, come ad esempio se contiene codice html o certe ricorrenze di parole. Questo sottosistema, costituito fondamentalmente da spamassassin, valuta se lasciare passare o mettere in quarantena il messaggio. Il tutto può essere configurato in modo che l'amministratore del server riceva un messaggio per ognuna delle email fermate da spamassassin.
A questi due sottosistemi si aggiunge anche il controllo che postfix può realizzare sul messaggio in arrivo in base a un certo numero di restrizioni che possono essere impostate. Ad esempio, possiamo scegliere di accettare solo i messaggi che hanno un FQDN valido, oppure controllare se il mittente si trova in qualche blacklist di spammer. Questo controllo viene realizzato prima dell'inoltro del messaggio al sottosistema gestito da postgrey. Questo triplo meccanismo, nella mia esperienza, è enormemente efficiente nella gestione dello spam che arriverà sul nostro server.
L'interfacciamento tra postfix e il sistema antivirus/antispam avviene attraverso un software aggiuntivo, chiamato amavis-new.
Innanzitutto installiamo tutto il software necessario, incluse le librerie che permettono l'interfacciamento di postfix e courier a mysql:
|
aptitude install postgrey postfix courier-pop courier-imap courier-authlib courier-authlib-mysql postfix-mysql clamav clamav-daemon razor spamassassin amavisd-new |
Impostiamo alcuni parametri di configurazione di postfix, definiti nel file /etc/postfix/main.cf:
|
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
|
Direttive importanti sono alias_maps e alias_database, che contengono le impostazioni degli alias, usati anche da programmi come mailman (ulteriormente aggiungeremo le direttive per specificare la tabella di mysql dove verranno registrati gli alias virtuali), mynetworks che definisce le reti per le quali i client sono definiti locali (in pratica le reti dalle quali postfix accetterà posta). mailbox_size_limit = 0 indica che la casella di posta è senza limiti.
Abbiamo detto che tutti gli account saranno definiti in un database mysql. Quindi creiamo un database di nome postfix e un utente postfix che sarà l'unico a poter accedere a questo db:
|
CREATE DATABASE postfix;
|
dopodiché bisogna definire la struttura delle tabelle del db postfix:
|
CREATE TABLE `admin` (
|
Per la configurazione delle caselle di posta virtuali, usiamo le seguenti direttive in /etc/postfix/main.cf:
|
# VIRTUAL MAILBOXES
|
Importanti sono le direttive virtual_uid_maps e virtual_gid_maps, che indicano l'id dell'utente e del gruppo di sistema dell'utente postfix. Questi id si possono trovare in /etc/passwd e /etc/group-.
Con questa configurazione, il server è pronto per il supporto quote, che però non vedremo in questo articolo per non allungare eccessivamente la trattazione. Il file mysql_virtual_mailbox_limit_maps.cf contiene i riferimenti alla tabella dove vengono registrate eventuali impostazioni per le quote utenti.
Vediamo i file contenenti la configurazione per l'accesso alle diverse tabelle del db postfix:
mysql_virtual_alias_maps.cf
|
user = postfix |
mysql_virtual_domains_maps.cf
|
user = postfix |
mysql_virtual_mailbox_maps.cf
|
user = postfix |
mysql_virtual_mailbox_limit_maps.cf
|
user = postfix |
È il momento di applicare alcune restrizioni alla configurazione del server smtp. A questo scopo scriviamo, sempre nel file /etc/postfix/main.cf:
|
smtpd_recipient_restrictions = |
che in pratica consente il relay mail ai client appartenenti alle sottoreti definite in mynetworks e in cui gli host mittente e destinatario sono ben formati. L'ultima direttiva (check_policy_service) gira tutto quello che arriva al servizio di rete in ascolto sulla porta 60000, in pratica postgrey, come vedremo più avanti.
E' possibile specificare altre direttive in smtpd_recipient_restrictions che permettono il controllo del mittente sulle blacklist di spammer, ad esempio:
|
smtpd_recipient_restrictions = |
Una cosa conveniente da fare è girare l'utente root a una delle caselle di posta virtuali valide create (per i compiti amministrativi). A questo scopo si può modificare il file /etc/aliases in modo da avere qualcosa come:
|
root: email@dominio |
poi bisogna lanciare il programma newaliases o postalias /etc/aliases per aggiornare la tabella degli alias (file /etc/aliases.db).
Resta da creare la cartella dove sarà immagazzinata tutta la posta in arrivo per le diverse caselle, dando i permessi corretti, come specificato nella configurazione di postfix e courier:
|
mkdir /var/mail/virtual
|
Bisogna ricordarsi che, nel caso di domini virtuali, la username per il login sui servizi pop e imap deve essere specificata comprensiva del dominio.
La configurazione di courier (il server pop/imap) è definita, fondamentalmente, nei file /etc/courier/authdaemonrc:
|
authmodulelist="authmysql"
|
e /etc/courier/authmysqlrc:
|
# The server name, userid, and password used to log in.
|
Oltre alle direttive che specificano i parametri di connessione
al server mysql, sono molto importanti MYSQL_UID_FIELD
e MYSQL_GID_FIELD, che specificano l'utente postfix
e il gruppo di appartenenza tramite il quale si accederà ai
servizi di courier, in modo simile a quanto detto
relativamente al file main.cf di postfix.
Finito
tutto facciamo ripartire tutti i servizi:
|
/etc/init.d/courier-authdaemon restart
|
Vediamo adesso l'interfacciamento tra postfix e il sistema antivirus/antispam. La prima cosa è inserire la seguente direttiva nel file /etc/postfix/main.cf:
|
content_filter = amavis:[127.0.0.1]:10024 |
che come si vede, viene configurato come un servizio di rete in ascolto sulla porta 10024. Nel file /etc/postfix/master.cf, dobbiamo inserire:
|
amavis unix - - n - 3 smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes
|
quindi, amavis ascolta sulla porta 10024, ma poi gira tutto alla porta 10025, dove vengono applicate le direttive specificate in master.cf.
Vediamo adesso la configurazione di amavis. Su una Debian etch, la configurazione è divisa in file multipli, come specificato in /usr/share/doc/amavisd-new/README.Debian:
Read-only configuration: /usr/share/amavis/conf.d/
10-debian_scripts: Stuff you'd better not override
20-package: Packaging decisions, override at will
Read-write conffiles: /etc/amavis/conf.d/
01-debian: Rarely modified settings
05-domain_id: mydomain autodetection, local_domains config
05-node_id: myhostname autodetection
15-av_scanners: AV scanner interface configuration
15-content_filter_mode: Use this to re-enable spamassassin/av checks
20-debian_defaults: Commonly modified settings
50-user: Place your overrides here, if you want
If the package detects legacy config files, it renames them adding a ".disabled" extension, and the amavisd-new initscript will refuse to start the service until these files with a ".disabled" extension are removed or renamed. The legacy config files are /etc/amavis.conf and /etc/amavis/amavis.conf.
Come si vede, la configurazione di amavis è piuttosto complessa e articolata. Seguendo quanto consigliato nel file README.Debian, noi inseriremo le nostre direttive personalizzate in /etc/amavis/conf.d/50-user, che essendo l'ultimo file ad essere letto, sovrascrive tutta la configurazione definita precedentemente dagli altri file di configurazione. Le direttive più importanti in questo file sono:
|
# $MYHOME serves as a quick default for some other configuration settings.
|
Chiaramente, bisogna definire due caselle virtuali: antivirus@dominio e antispam@dominio, per poter ricevere le notifiche amministrative quando amavis identifica un virus o un messaggio di spam. Le tre direttive finali indicano la posizione della blacklist e whitelist (si rimanda alla documentazione ufficiale per la sintassi utilizzata in questi file). Ho preferito essere prolisso nell'illustrare questa configurazione, in modo da inserire i commenti esplicitativi presenti nello stesso file.
Il file /var/lib/amavis/notify_spam_sender.txt contiene il template del testo con cui il mittente verrà avvisato che il messaggio non è stato recapitato perché non ha superato il filtro antispam:
|
From: AutoSpamChecker <antispam@dominio>
|
dove si suppone che abuse@dominio sia una casella di posta valida.
Se facciamo un /etc/init.d/amavis restart, possiamo leggere in /var/log/syslog alcune righe relative alla configurazione di amavis che ci danno indicazione dei moduli caricati (decompressori, il modulo per spamassassin, ecc.):
|
Jan 12 17:16:46 marte amavis[32333]: Module Archive::Tar 1.30
|
e se i sottosistemi antivirus e antispam sono funzionanti:
|
Jan 12 17:16:46 marte amavis[32333]: Amavis::DB code loaded
|
razor è un sistema distribuito di blacklisting per spammers, e viene usato da spamassassin per realizzare una verifica sul mittente del messaggio, prima dell'analisi effettiva del contenuto. razor verrà implementato e configurato più avanti, come parte del sottosistema relativo a spamassassin.
Vediamo adesso la configurazione di clamav, l'antivirus. C'è un difetto nella configurazione di default quando si usa amavis, ed è che il file di configurazione imposta il proprietario del database come clamav, l'utente antivirus, anziché amavis, che è l'utente che effettivamente deve aver accesso ai file interni di clamav. Quindi, sostituiamo
|
DatabaseOwner clamav |
con
|
DatabaseOwner amavis |
nel file /etc/clamav/freshclam.conf. Poi cambiamo tutti i permessi dei file di lavoro interessati:
|
/etc/init.d/clamav-daemon stop
|
Vediamo adesso la configurazione di spamassassin e razor. La configurazione di spamassassin la si trova in /etc/spamassassin/local.cf:
|
# This is the right place to customize your installation of SpamAssassin.
|
Per completezza, riporto anche la configurazione di dcc e pyzor (altri due sistemi di verifica spammer distribuiti) che ho usato in passato. Per quanto riguarda razor (/etc/razor/razor-agent.conf):
|
# See razor-agent.conf (5)
|
C'è un altro file in /var/lib/amavis/.razor/razor-agent.conf, che però viene autogenerato dallo stesso software:
|
# |
A questo punto bisogna dire al sistema di far partire spamassassin come servizio all'avvio della macchina. Questa operazione la si fa mettendo ENABLED = 1 nel file /etc/default/spamassassin:
|
# /etc/default/spamassassin |
Poi facciamo partire il servizio:
|
/etc/init.d/spamassassin start |
L'ultimo punto è costituito dal sottosistema postgrey. Abbiamo già visto la direttiva da inserire nella configurazione di postfix al punto 5. La configurazione si trova nel file /etc/default/postgrey:
|
# postgrey startup options, created for Debian
|
Innanzitutto, installiamo il software necessario:
|
aptitude install apache2 php5 phpmyadmin postfixadmin |
phpmyadmin e postfixadmin sono due programmi web molto ben fatti e facili da utilizzare che ci possono dare una preziosa mano nella gestione dei dati associati alle caselle di posta virtuali. postfixadmin è stato sviluppato appositamente per questo scopo; invece phpmyadmin ha una utilità generica nella gestione di database mysql. Entrambi sono programmi php, e per questo abbiamo installato l'interprete per questo linguaggio.
Dobbiamo attivare i moduli di apache per il php e ssl, che ci serviranno nei punti successivi:
|
a2enmode php5 |
È possibile che ci si voglia collegare dall'esterno della rete aziendale per poter gestire le caselle di posta (o eventualmente qualsiasi database mysql), anche se non è raccomandabile, essendo sempre preferibile realizzare un collegamento via VPN. Ovviamente, in questo caso non possiamo realizzare una connessione HTTP usuale, dal momento che tutto il traffico dati passa in chiaro. Bisogna incapsulare la connessione attraverso il layer SSL del protocollo HTTP (HTTPS). Bisogna disporre di un certificato, che per i nostri scopi può essere autofirmato. Il certificato viene creato attraverso il seguente comando:
|
openssl req $@ -new -x509 -days 9999 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem |
e che viene salvato in /etc/apache2/ssl. Inoltre, bisogna specificare nella configurazione di apache la porta attraverso la quale verrà realizzata la connessione HTTPS (la porta canonica è la 443), aggiungendo:
|
Listen 443 |
nel file /etc/apache2/ports.conf.
Adesso è arrivato il momento di creare gli host virtuali. Per postfixadmin, io ne creo due, uno per la gestione della connessione HTTP (/etc/apache2/sites_available/postfixadmin):
|
<VirtualHost *:80>
|
e un altro per la connessione HTTPS (/etc/apache2/sites_available/postfixadmin_ssl):
|
<VirtualHost *:443>
|
come si può osservare, tutto il traffico che arriva tramite HTTP viene girato all'host virtuale attivo sulla porta 443, in modo da evitare che sia possibile l'accesso non protetto. Quest'ultimo attiva il layer SSL e logga tutto sui file specificati.
Per phpmyadmin abbiamo dei file simili, ma è necessario definire solo quello SSL, dal momento che sulla Debian l'installazione del programma prevede l'inclusione di un file di configurazione già pronto e l'attivazione e lettura da parte di apache. Per il reindirizzamento di tutto il traffico HTTPS basta aggiungere
|
Redirect permanent / https://phpmyadmin.dominio/ |
nel file /etc/apache2/conf.d/phpmyadmin.conf.
Attiviamo gli host virtuali e facciamo ripartire il servizio:
|
a2ensite phpmyadmin postfixadmin postfixadmin_ssl
|
hylafax è un potente programma per l'invio e ricezione fax. Lavora a basso livello ed è estremamente affidabile. La configurazione prevede la creazione di un utente faxmaster, operazione realizzata automaticamente durante il processo di installazione.
Per prima cosa installiamo il software:
|
aptitude install hylafax-server |
La procedura di installazione lancia un programma chiamato faxsetup, attraverso il quale viene realizzata la configurazione, compresa la tipologia di modem (che viene riconosciuta automaticamente), il numero di telefono, ecc. Successivamente si può lanciare il programma faxaddmodem per realizzare variazioni a questa configurazione, anche se io preferisco modificare manualmente i file di configurazione.
È opportuno configurare l'email dell'utente al quale verranno recapitati tutti i fax ricevuti e la tipologia di file; il fax sarà ricevuto per posta elettronica come allegato a un messaggio con il formato specificato. Queste due opzioni si trovano nel file /var/spool/hylafax/bin/faxrcvd:
|
FILETYPE=pdf |
L'opzione predefinita per il formato del file è TIF. Ovviamente, faxmaster@dominio deve essere una casella virtuale valida oppure un alias a una casella virtuale.
Adesso dobbiamo configurare le reti e/o gli utenti che avranno il permesso di utilizzare i servizi fax dal file /etc/hylafax/hosts.hfaxd:
|
localhost:21:: |
Questa configurazione permette l'utilizzo del servizio fax alla macchina locale, alla sottorete 192.168.10.0 e all'utente user1. Per l'inserimento e cancellazione degli utenti si utilizzano i programmi faxadduser e faxdeluser (con password crittografata). Questa è una configurazione di esempio; in realtà si potrà scegliere tra specificare gli utenti con password o permettere l'utilizzo a tutta la rete.
Facciamo ripartire il servizio e siamo a posto:
|
/etc/init.d/hylafax restart |
Per verificare se il tutto funziona si può usare il comando faxstat:
|
# faxstat
|
Per finire, possiamo schedulare i programmi faxcron e faxqclean, che rispettivamente inviano un resoconto periodico delle attività fax e puliscono la cache dei fax ricevuti/inviati:
|
@monthly /usr/sbin/faxcron | mail -s 'Hylafax statistiche' root && /usr/sbin/faxqclean |
dove la casella root è un alias alla casella reale dell'amministratore del sistema.
Una cosa molto funzionale consiste nell'integrazione tra hylafax e postfix per fare in modo di inviare i fax come email direttamente dal nostro client di posta elettronica. Per fare questo dobbiamo modificare la configurazione di postfix. Nel file main.cf aggiungiamo:
|
# Hylafax via mail
|
mentre in master.cf, bisogna aggiungere:
|
# Hylafax via mail
|
Infine, in /etc/postfix/transport, aggiungiamo la seguente riga:
|
fax.dominio fax:localhost |
(si possono aggiungere insieme più domini). Fatto questo, aggiorniamo il database trasport.db e rileggiamo la configurazione:
|
postmap transport |
Da questo momento abbiamo la possibilità di inviare fax via posta elettronica, inserendo come destinatario <numero di telefono>@fax.dominio. postfix girerà il messaggio a hylafax che lo invierà come un normale fax.
Finiamo questo articolo con un sistema per il backup. rsnapshot è uno script perl che realizza backup (di tipo snapshot) utilizzando rsync e gli hard-link, supportati dalla maggior parte dei filesystem linux. Come è noto, rsync permette di sincronizzare due filesystem in modo efficiente, ma c'è un problema: se modifico un file nel filesystem originale e non me ne accorgo prima della successiva sincronizzazione con rsync, la modifica sarà replicata nella mia copia di backup e mi sarà impossibile recuperare il file prima della modifica. Lo stesso discorso vale per la cancellazione dei file se sto usando rsync con l'opzione -delete.
rsnapshot utilizza questa logica ma permette di organizzare gli snapshot in più periodi temporali, in modo che sia possibile recuperare le copie del file non modificate su un backup precedente alla data in cui è stata realizzata la modifica o è stato cancellato il file. Gli hard-link sono usati dal momento che richiedono molto meno spazio su disco della semplice copia del file.
La base del funzionamento del sistema è la seguente: supponiamo di avere 3 backup relativi agli ultimi tre giorni, daily0, daily1 e daily2. rsnapshot inizia il suo lavoro cancellando daily2 (si suppone che un quarto backup sarebbe al di fuori dell'arco temporale coperto dal sistema secondo la configurazione, che poi analizzeremo) e rinominando daily1 come daily2; a questo punto abbiamo i seguenti snapshot: daily0 e daily2. Successivamente, rsnapshot realizza una copia di daily0 e la chiama daily1, ma non si tratta di una copia usuale, ma di una copia ricorsiva come hard-link (viene usata l'opzione -l del comando cp). In pratica, alla fine del processo, abbiamo due cartelle uguali (daily0 e daily1), ma daily1 occupa molto meno spazio di daily0. Una cancellazione di un file in daily0 non coinvolge la cancellazione del file in daily1, dal momento che il filesystem conserva una copia del file fintanto che tutti gli hard-link non sono stati cancellati. È il momento di rsync, che realizza una sincronizzazione di daily0 con il filesystem da backupare. Tutti i file modificati nel filesystem di partenza sono cancellati in daily0 e riscritti con le nuove modifiche, ma una copia della vecchia versione rimane in daily1, dal momento che rimane ancora un hard-link che punta alla versione non modificata. Il file sarà effettivamente modificato in tutti gli snapshot quando sarà passato l'intero arco temporale coperto dalla configurazione di rsnapshot.
Un punto di forza importante è che questo sistema permette il backup sia locale che remoto. Il backup remoto viene realizzato in modalità push (rispetto al sistema remoto), incapsulando il traffico dati in una connessione ssh, per cui è estremamente sicuro. Possiamo realizzare il backup giornaliero del nostro portatile e anche dei nostri server sparsi in giro in tutta tranquillità.
Questo sistema io lo uso da anni e non ho mai avuto problemi. È chiaro che non si tratta di un sistema per il backup sofisticato come quello di bacula, ad esempio, ma è estremamente flessibile e semplice e può essere indicato in diverse situazioni:
realizziamo in backup solo su disco, e non abbiamo bisogno di sistemi più sofisticati e più difficili da configurare in grado di supportare dispositivi come unità a nastro;
il nostro cliente richiede esplicitamente di poter realizzare il ripristino dei file, perché non vuole doverci chiamare ogni volta che ha combinato qualche pasticcio o non vuole imparare a usare programmi "per esperti" (mi viene in mente il bconsole di bacula). Basta condividere in sola lettura la root dove vengono salvati i diversi snapshot e troverà i file distribuiti in una gerarchia di cartelle identica a quella del suo server.
Il backup di sistemi Windows non è un problema: basta montare la cartella da backupare via samba sul server linux prima di lanciare rsnapshot.
Nel proseguo di questo paragrafo userò la seguente terminologia: con "sistema locale" farò riferimento al server di backup, ovvero il sistema che contiene gli snapshot; per "sistema remoto" si intenderà il sistema da backupare.
Iniziamo con la installazione del software. Sul sistema locale installiamo rsnapshot; il sistema di pacchetti apt installerà anche tutta una serie di dipendenze necessarie:
|
aptitude install rsnapshot |
Sul sistema remoto basta installare:
|
aptitude install sudo rsync |
C'è una questione importante: come abbiamo detto il backup remoto avviene attraverso una sessione ssh, ma il server ssh ci chiederà una password per consentire l'accesso. Per evitarlo, bisogna generare una chiave e configurare entrambi i sistemi in modo che le credenziali di accesso vengano garantite attraverso la chiave e non la password. Per cominciare, su tutti i sistemi remoti da backupare creiamo un utente rsnapshot senza password e appartenente a un gruppo con lo stesso nome.
Nel computer locale generiamo la chiave ssh, senza password, per l'accesso al sistema remoto:
|
cd /root/.ssh |
come si vede, la chiave viene generata nella home directory dell'utente root, che è l'utente che lancerà il processo di backup. Vengono creati due file: id_rsa con la chiave privata e id_rsa.pub con quella pubblica.
Copiamo la chiave id_rsa.pub in tutti i sistemi remoti soggetti a backup, salvandola all'interno della home dell'utente rsnapshot appena creato:
|
scp id_rsa.pub rsnapshot@server.dominio:/home/rsnapshot/.ssh |
Aggiungiamo la chiave al file authorized_keys, copiando il contenuto del file id_rsa.pub dopo la stringa from="server.backup". Il file authorized_keys diventa quindi:
|
from="server.backup" (contenuto del file 'id_rsa.pub') |
In questo modo è permesso il collegamento ssh solo da quell'ip, senza password e usando la chiave. È anche possibile aggiungere il comando che sarà possibile eseguire da remoto, se si vuole aumentare ancora la sicurezza.
Il programma rsync viene lanciato dall'utente rsnapshot che, quindi, deve disporre dei permessi di root per poter accedere e fare il backup di cartelle di sistema e di altri utenti. In breve, è necessario lanciare rsync tramite sudo, ma questo crea un problema, dal momento che non è possibile richiamare da remoto il comando sudo rsync. Per risolvere il problema, si crea uno wrapper in /usr/local/bin/rsync:
|
#!/bin/sh |
di seguito rinominiamo il file rsync originale come rsync_real:
|
mv /usr/bin/rsync /usr/bin/rsync_real |
In questo modo, la procedura di backup remoto chiamerà rsync che non è altro che uno wrapper al vero rsync (adesso rsync_real) che però, viene chiamato con sudo.
Abbiamo finito l'accesso ssh da remoto per il backup. Adesso vediamo la configurazione di rsnapshot. Le direttive importanti in /etc/rsnapshot.conf sono le seguenti:
|
########################### |
che fa un backup del server locale e di quello remoto per 14 giorni, 8 settimane e 6 mesi. All'interno della cartella contenente il backup di ciascun periodo temporale, troveremo delle sottocartelle contenenti il backup di ciascun server. I commenti del file di configurazione sono abbastanza chiarificatori.
L'ultimo punto è lo schedulamento dei 3 processi (giornaliero, settimanale e mensile). Si può inserire il seguente script in /etc/cron.d:
|
0 20 2-6,8-13,15-20,22-27,29-31 * * root /usr/bin/rsnapshot daily
|
Abbiamo finito. Spero che il taglio dato a questo articolo e le informazioni in esso contenute possano essere considerate di interesse. Sono rimaste in sospeso molte cose interessanti, tra tutte, la configurazione del TLS e l'autenticazione SMTP in postfix, ma anche l'integrazione con altri programmi, come mailman.
Sarebbe bello se queste note potessero essere integrate nel tempo con nuove informazioni, che coprissero la configurazione di servizi non considerati in questo articolo o le variazioni relative all'evoluzione del software. Quindi, lo lancio come proposta: un documento da estendere e integrare nel tempo da più persone, per quanto riguarda la configurazione di un server Linux, e che serva da compendio per tutta una serie di risorse sparpagliate in Rete.
Attendo tanti vostri contatti.
L'autoreFrancisco Yepes Barrera lavora da anni offrendo consulenza come sistemista e programmatore su piattaforme libere. Parte del suo lavoro si centra nella soluzione di problemi in ambito scientifico-computazionale usando Software Libero. |
|
|
<- Mono - Indice Generale - Copertina - Maven: accumulator of knowledge -> |
|