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.).
Una buona "ricetta".
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 servizi.
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.
Il sistema.
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
Disk /dev/sda: 160.0 GB, 160000000000 bytes
255 heads, 63 sectors/track, 19452 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 122 979933+ fd Linux raid autodetect
/dev/sda2 123 1338 9767520 fd Linux raid autodetect
/dev/sda3 1339 1460 979965 fd Linux raid autodetect
/dev/sda4 1461 19452 144520740 5 Extended
/dev/sda5 1461 3284 14651248+ fd Linux raid autodetect
/dev/sda6 3285 19452 129869428+ fd Linux raid autodetectLa 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
Personalities : [raid1]
md4 : active raid1 sda6[0] sdb6[1]
129869312 blocks [2/2] [UU]
md3 : active raid1 sda5[0] sdb5[1]
14651136 blocks [2/2] [UU]
md2 : active raid1 sda3[0] sdb3[1]
979840 blocks [2/2] [UU]
md1 : active raid1 sda2[0] sdb2[1]
9767424 blocks [2/2] [UU]
md0 : active raid1 sda1[0] sdb1[1]
979840 blocks [2/2] [UU]
unused devices: <none>che alla fine danno luogo al filesystem Linux:
# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/md1 / ext3 defaults,errors=remount-ro 0 1
/dev/md0 /boot ext3 defaults 0 2
/dev/md3 /usr ext3 defaults 0 2
/dev/md4 /var ext3 defaults 0 2
/dev/md2 none swap sw 0 0Per 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
deb http://ftp.it.debian.org/debian/ etch main
deb-src http://ftp.it.debian.org/debian/ etch main
deb http://security.debian.org/ etch/updates main contrib
deb-src http://security.debian.org/ etch/updates main contrib
# Debian volatile
deb http://volatile.debian.org/debian-volatile etch/volatile main contribche 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
127.0.0.1 localhost
192.168.x.y server.dominio serverVerificare l'hostname della macchina ed eventualmente settarlo con il comando hostname oppure scrivendo nome e dominio nel file /etc/hostname:
# cat /etc/hostname
server.dominioA 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
HOMEHOST server.dominio
# instruct the monitoring daemon where to send mail alerts
MAILADDR email@dominiodove 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
apt-get update
apt-get -u dist-upgrade
apt-get cleanche 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
grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 16 sectors are
embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p
(hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd1)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 16 sectors are
embedded.
succeeded
Running "install /boot/grub/stage1 (hd1) (hd1)1+16 p
(hd1,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
grub> quitIn 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
nameserver 127.0.0.1In 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
zone "." {
type hint;
file "/etc/bind/db.root";
};e dove il file db.root contiene qualcosa come:
; <<>> DiG 9.3.4-P1.1 <<>> @e.root-servers.net . ns
; (1 server found)
;; global options: printcmd
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10584
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f
G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53
H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235
I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30
;; Query time: 243 msec
;; SERVER: 192.203.230.10#53(192.203.230.10)
;; WHEN: Mon Dec 1 06:52:02 2008
;; MSG SIZE rcvd: 500derivante dal lanciare il comando dig senza parametri. Per aggiornare questo file, costruiamo il seguente script:
#!/bin/sh #
# Update the nameserver cache information file once per month.
# This is run automatically by a cron entry.
#
# Original by Al Longyear
# Updated for BIND 8 by Nicolai Langfeldt
# Miscelanious error-conditions reported by David A. Ranch
# Ping test suggested by Martin Foster
# bind up-test suggested by Erik Bryer.
#
(
PATH=/sbin:/usr/sbin:/bin:/usr/bin:
export PATH
# NOTE: /etc/bind must be writable only by trusted users or this script
# will cause root compromise/denial of service opportunities.
cd /etc/bind 2>/dev/null || {
echo "Subject: Cannot cd to /etc/bind, error $?"
echo
echo "The subject says it all"
exit 1
}
dig @e.root-servers.net . ns > db.root.new 2> errors
case `cat db.root.new` in
*NOERROR*)
# It worked
:;;
*)
echo "Subject: The db.root file update has FAILED."
echo echo "The db.root update has failed"
echo "This is the dig output reported:"
echo cat db.root.new errors
exit 1
;;
esac
# echo "Subject: The db.root file has been updated"
echo
echo "The db.root file has been updated to contain the following information:"
echo
cat db.root.new
chown root:root db.root.new
chmod 444 db.root.new
rm -fv db.root.old errors
mv -v db.root db.root.old
mv -v db.root.new db.root
/etc/init.d/bind9 restart
echo
echo "The nameserver has been restarted to ensure that the update is complete."
echo "The previous db.root file is now called /etc/bind/db.root.old."
) 2>&1 | mail -s 'The db.root file has been updated' email@dominio
exit 0Basta 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
@daily /usr/sbin/ntpdate ntp1.ien.itPer 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
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 52 weeks worth of backlogs
rotate 52
MySQL.
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'.
fonte: Pluto
Trovato questo articolo interessante? Condividilo sulla tua rete di contatti in Twitter, sulla tua bacheca su Facebook, in Linkedin, Instagram o Pinterest. Diffondere contenuti che trovi rilevanti aiuta questo blog a crescere. Grazie!
0 commenti:
Posta un commento